Daily reports: Monday

Daily reports: Monday

[Luka Marčetić]

What I did today
     * fixed a lot of bugs in numeric.c, reduced a lot of stuff to 80 
chars width as per coding style
     * added sscanf support in numeric.c
     * fixed a bug in common/sequence.h
Future plans:
     * separate sscanf tests from strto tests in numeric.c
     * finish numeric.c by adding endptr checks for [wcs|str]to* 
functions, and endptr check for sscanf (started writing the latter)
     * update the license to cut-down BSD
     * learn make, start writing cluts.c (the framework), make it work 
with existing tests
     * choose a new task, i'm thinking 8, 11, or 0 perhaps. (please make 
your suggestions)

Re: Daily reports: Tuesday

[Luka Marčetić]

On 07/05/2011 02:41 AM, Luka Marčetić wrote:
> Future plans:
>     * separate sscanf tests from strto tests in numeric.c
>     * finish numeric.c by adding endptr checks for [wcs|str]to* 
> functions, and endptr check for sscanf (started writing the latter)
>     * update the license to cut-down BSD
>     * learn make, start writing cluts.c (the framework), make it work 
> with existing tests
>     * choose a new task, i'm thinking 8, 11, or 0 perhaps. (please 
> make your suggestions)
The first three are done: That is, numeric.c is finished, but its test 
data is questionable (especially tests adopted for sscanf), and will 
need a lookover - right now it prints out a huge amount of stuff. I made 
it flexible though, so adding new things, or correcting old ones is 
easy. I'll now start thinking about point nr.4 here, and then I need to 
decide what next.
-Luka

Re: Daily reports: Wednesday

[Luka Marčetić]

Hello.
I looked over the rest of the test data in numeric.c and changed quite a 
bit of other things in the process. It's now ready for usage, and I'd 
like to ask Rich to please comment on output of the musl-gcc-compiled 
binary (you may need to comment out wcsto[f|d|ld] if musl doesn't 
support them yet). Let me know if there are any objections to the tests. 
I'll try to make a nice make file today.

As for the future, I'm planing on making the cluts.c framework, and this 
is what I intend for it to do:

* find 'test collections' using dirent.h (haven't used it yet, but 
shouldn't be hard to learn I guess)
* fork off for each test collection and execl() each one
* simple statistics based on the status provided by wait()

That much I guarantee to be done tomorrow. When that's done I'm going to 
implement these additional features:

* advanced statistics(via what will be common/ipc.c): shared memory with 
two integers for each 'test collection' which will indicate:
     a) number of tests that have begun executing (incremented before 
each test starts by the child)
     b) number of successful tests
     The pointer to shared memory will be passed as an argument to the 
child (test collection). From a) the framework will be able to know 
which test number has crashed the collection. If the collection returns, 
the framework will be able to calculate the success rate by dividing b) 
with a).
* a few features which the user can invoke via some switches (using 
standard tokenizing functions - need to study them first):
     -v --verbose without which collections will not print anything 
themselves
     -t --test <test1>[,<test2>,...]  specific tests to execute
     -x --exclude <test1>[,<test2>,...] exceptionally excluded tests
     -h --help etc

Comments and suggestions are very welcome. Especially any advice about 
includes and .h files is welcome, I am new to structuring files in C.
Thanks.
-Luka

Re: Re: Daily reports: Wednesday

[Szabolcs Nagy]

* Luka Mar??eti?? <paxcoder@gmail.com> [2011-07-06 22:28:14 +0200]:
> As for the future, I'm planing on making the cluts.c framework, and
> this is what I intend for it to do:
> 
> * find 'test collections' using dirent.h (haven't used it yet, but
> shouldn't be hard to learn I guess)
> * fork off for each test collection and execl() each one
> * simple statistics based on the status provided by wait()
> 

my opinion:

don't overengineer the test system

(i have ideas about it, i think i'll
implement them soon, but i'll be
offline for a week)

as a first round it's enough to
make it work from a makefile/shell script
(ie. writing a testsuit tool in c with
flags etc is not that important)

a simple solution is:
test collections are .c files in directories
each directory makes one executable
(several test_foo.c with some exported test_foo
functions and one main, the main can be even
generated if test_* convention is used but at first
hand writing it is probably simpler)
there is a shell script/makefile in the root that
builds and runs the tests in all directory
and gives a report at the end about the number
of failures

simplicity is important so that it is
easy to contribute tests or fix the system
later when there are more tests

extra features can come later:
> * advanced statistics(via what will be common/ipc.c): shared memory
> with two integers for each 'test collection' which will indicate:
>     a) number of tests that have begun executing (incremented before
> each test starts by the child)
>     b) number of successful tests
>     The pointer to shared memory will be passed as an argument to
> the child (test collection). From a) the framework will be able to
> know which test number has crashed the collection. If the collection
> returns, the framework will be able to calculate the success rate by
> dividing b) with a).
> * a few features which the user can invoke via some switches (using
> standard tokenizing functions - need to study them first):
>     -v --verbose without which collections will not print anything
> themselves
>     -t --test <test1>[,<test2>,...]  specific tests to execute
>     -x --exclude <test1>[,<test2>,...] exceptionally excluded tests
>     -h --help etc
> 
at some point (but probably not right now) it would
be nice if slow tests can be marked with some
macro oslt, by the test writer and it should be easy
to avoid those

i'm not sure about -t and -x
if long and descriptive testnames are used then a
regex filter is probably easier to use than -t -x
(but we don't know this yet so it should be decided
when there are many tests ready)

> Comments and suggestions are very welcome. Especially any advice
> about includes and .h files is welcome, I am new to structuring
> files in C.
if you are new to it then i really recommend to do
the absolute simplest/minimal thing you can imagine here,
then it will be easy to fix later..

of course ymmv

Re: Daily reports: Thursday

[Luka Marčetić]

On 07/06/2011 10:28 PM, Luka Marčetić wrote:
> * find 'test collections' using dirent.h (haven't used it yet, but 
> shouldn't be hard to learn I guess)
> * fork off for each test collection and execl() each one
> * simple statistics based on the status provided by wait()
>
That's done, I'm thinking about taking another task, rather than 
improving on cluts.c. Tell me if you disagree
By the way, I've changed my account name on github, so the link is now:
https://github.com/lmarcetic/cluts
Thanks.
-Luka

Re: Re: Daily reports: Wednesday

[Luka Marčetić]

Thanks for your reply, didn't see it till now. Even so, it seems like I 
followed your advice (with the exception of string.c which doesn't 
return nr. of failures yet, as it was written to simply write out 
nasties to stderr). So far though, 'test collections' are files. That 
is, one collection=one file. What I'm doing now is i'm compiling all 
collections (ie all .c's) in the tests/ directory, and executing them 
from one place (cluts.c) ensuring they can crash. For an advanced 
version, regex is a nice idea. Filenames may eventually be replaced for 
what processes communicate to cluts - they can give their (full) names 
via IPC. Anyway, thanks again for your comments.
-Luka

Re: Daily reports: Friday

[Luka Marčetić]

On 07/07/2011 10:16 PM, Luka Marčetić wrote:
> That's done, I'm thinking about taking another task, rather than 
> improving on cluts.c. Tell me if you disagree
> By the way, I've changed my account name on github, so the link is now:
> https://github.com/lmarcetic/cluts
> Thanks.
> -Luka

Hello again.
I wanted to move on to task number 8, but I had some questions. I asked 
Rich via XMPP about them, but I guess he's still out. So in the meantime 
I started doing task number 6 (which is the next one in line, skipping 
some incomplete ones). I have the basic structure, and will be making a 
commit in an hour or so, however I'm not sure what method to employ to 
search for the specified type of functions. Hopefully I'll have an idea 
by tomorrow (you're welcome to contribute - specific keywords to grep 
for, for instance?).
So again, my plan is finishing 6 first (right now it's called strn.c), 
then moving on to 8.
-Luka

P.S. This may be a double-post. If it is, my apologies.

Re: Daily reports: Friday - cont

[Luka Marčetić]

On 07/09/2011 12:41 AM, Luka Marčetić wrote:
> I have the basic structure, and will be making a commit in an hour or so
I apologize for the delay, I thought I had a bug in my code (the new 
String.c to be precise), but it turns out gdb was playing tricks on me. 
I've learned that it doesn't (necessarily) regard "\0<char><char><char>" 
as NULL, and three <char>s, but sometimes as some other char (like '.' 
and '='). You probably know why (octal char representation), I didn't.
I understand it's still Friday in USA, so I'm filing under here. ;-)
-Luka

Re: Daily reports: Friday - cont

[Solar Designer]

Hi Luka,

I just want to let you know that I appreciate your frequent reports.

I intend to take a look at your latest code during the weekend.

On Sat, Jul 09, 2011 at 03:12:00AM +0200, Luka Mar??eti?? wrote:
> I apologize for the delay, I thought I had a bug in my code (the new 
> String.c to be precise), but it turns out gdb was playing tricks on me. 
> I've learned that it doesn't (necessarily) regard "\0<char><char><char>" 
> as NULL, and three <char>s, but sometimes as some other char (like '.' 
> and '='). You probably know why (octal char representation), I didn't.

This applies to C sources as well, and to some other languages.  My
approach to dealing with it is generally to split/concatenate the string
right after the escape sequence, like this:

const char *k = "\xff\xa3" "34" "\xff\xff\xff\xa3" "345";

(from some code I wrote yesterday).

I think this one was actually OK without the splits, but better safe
than sorry - and like you say with octals the problem is more real.

Alexander

Re: Daily reports: Friday

[Solar Designer]

Luka, Rich -

On Sat, Jul 09, 2011 at 12:41:02AM +0200, Luka Mar??eti?? wrote:
> I wanted to move on to task number 8, but I had some questions. I asked 
> Rich via XMPP about them, but I guess he's still out.

OK, let's wait for Rich's comments on this.  BTW, chances are that the
RLIMIT_NPROC check on setuid(2) and friends will be removed from future
kernels: http://www.openwall.com/lists/kernel-hardening/2011/07/06/8

I understand that Rich's proposed tests are about the libc wrapper
functions that are thread-aware rather than about syscalls, yet I felt
the above was relevant to the tests.

> So in the meantime 
> I started doing task number 6 (which is the next one in line, skipping 
> some incomplete ones). I have the basic structure, and will be making a 
> commit in an hour or so, however I'm not sure what method to employ to 
> search for the specified type of functions. Hopefully I'll have an idea 
> by tomorrow (you're welcome to contribute - specific keywords to grep 
> for, for instance?).

I'm afraid that you'll need to manually review function lists, but you
may also use tricks like grepping function prototypes for size_t inside
the argument list.

There's some overlap with 1 ("String operations testing"), though.
Maybe for string functions, this check should be one of those performed
as part of those tests, whereas 6 ("Functions which return strings in
caller-provided buffers") should focus on other functions - things such
as getcwd().  Or maybe not.  Just a thought.

> So again, my plan is finishing 6 first (right now it's called strn.c), 
> then moving on to 8.

Sounds fine to me.  Why not 7 ("Functions which manipulate temp copies
of an argument string"), though?  BTW, let's refer to these things not
only by number, which is error-prone and excludes most members of this
mailing list from participating in the discussion.  For others watching
this discussion and not knowing what the numbers are about:

http://openwall.info/wiki/musl/unit-tests

> P.S. This may be a double-post. If it is, my apologies.

I got only one copy of it.  I find the ever-changing Subjects with
preserved Re: on them weird, though.

Thanks,

Alexander

Re: Daily reports: Friday

[Luka Marčetić]

On 07/09/2011 01:53 PM, Solar Designer wrote:
> OK, let's wait for Rich's comments on this.  BTW, chances are that the
> RLIMIT_NPROC check on setuid(2) and friends will be removed from future
> kernels: http://www.openwall.com/lists/kernel-hardening/2011/07/06/8
>
> I understand that Rich's proposed tests are about the libc wrapper
> functions that are thread-aware rather than about syscalls, yet I felt
> the above was relevant to the tests.
Ok.
> use tricks like grepping function prototypes for size_t inside
> the argument list.

I meant more like specific phrases in the description of the function, 
though combining size_t with what char * might be useful too.

> There's some overlap with 1 ("String operations testing"), though.
> Maybe for string functions, this check should be one of those performed
> as part of those tests, whereas 6 ("Functions which return strings in
> caller-provided buffers") should focus on other functions - things such
> as getcwd().  Or maybe not.  Just a thought.

Now that you mentioned it, indeed string.c ("String operations testing") 
should perhaps fully address strn* functions. It makes sense. I'll 
probably put the strn* functions (and the mem* ones) there then, and try 
to find those getcwd()-like for the current task. Before I do the former 
though, I'll have to redesign string.c to be more flexible - something 
along the lines of what I've been doing with the new "test collections 
(or as much as C premits). Otherwise, it would take ages to write tests 
the way they were written so far (especially knowing string.c's scope, 
and the sheer number of functions it needs to test). Descriptiveness of 
errors may suffer a bit, but I think it's the best thing to do.

>> my plan is finishing 6 first (right now it's called strn.c),
>> then moving on to 8.
> Sounds fine to me.  Why not 7 ("Functions which manipulate temp copies
> of an argument string"), though?

I hoped to do 8 (Threaded setuid race conditions) because I wanted to 
make it a bit more interesting for me - simply as a change from what 
I've been doing in numeric.c - but also to learn setuid (I've never used 
it). Under the circumstances though, I am instead doing a similar thing 
in strn.c (6). If I finish that before Rich gets back to me, I may move 
on to nr. 7 (Functions which manipulate temp copies of an argument 
string), although I don't consider 6 or 7 to be demanding tasks (perhaps 
only timely, because there is plenty of stuff to test).

>> P.S. This may be a double-post. If it is, my apologies.
> I got only one copy of it.  I find the ever-changing Subjects with
> preserved Re: on them weird, though.

Oh, ok. I should've ommitted the "-cont" I agree. However, being Re:'s 
to each other, I hope they still fall under the same thread. As an 
orientation, I may use the latest commits eg "strn.c + comon/String.c" 
as part of the Subject, or I may drop differentiation completely and 
just have us rely on time stamps. In the end, there's always this to 
monitor specific commits: https://github.com/lmarcetic/cluts/commits/master

Luka.

Re: Daily reports: Friday

[Luka Marčetić]

Saturday report:
Haven't managed to write much code, I was not home for some time, but 
also I need to think through how to design the tests, since the 
functions differ by the number, not just the type of arguments, plus to 
test each one, additional stuff may be needed to be done first (in each 
of the 'cases', some string shuffling etc). That's assuming the 
collection will look anything like numeric.c. For referrence, here are 
the functions grep returned:http://paste.debian.net/122456/ (I've 
removed some string.h ones manually). I may just write the tests 
straight-forward. I expect that list could probably be cut in half or so 
(however, some functions may need to be added), and i'm not testing 
various inputs like before, just the behavior for a specific set of. 
I'll make some commits monday I guess. I'd wish Rich would get back to 
us, I could probably be able to properly finish that setuid task in a 
day so I can have more tests collections by mid-week.
Talk to you soon,
Luka.

Re: Daily reports: Friday (threaded setuid testing)

[Rich Felker]

On Sat, Jul 09, 2011 at 03:53:01PM +0400, Solar Designer wrote:
> Luka, Rich -
> 
> On Sat, Jul 09, 2011 at 12:41:02AM +0200, Luka Mar??eti?? wrote:
> > I wanted to move on to task number 8, but I had some questions. I asked 
> > Rich via XMPP about them, but I guess he's still out.
> 
> OK, let's wait for Rich's comments on this.  BTW, chances are that the
> RLIMIT_NPROC check on setuid(2) and friends will be removed from future
> kernels: http://www.openwall.com/lists/kernel-hardening/2011/07/06/8

I wonder if I should jump in that thread and mention that, even if the
application checks the return value of setuid, it can be wrong for
multi-threaded applications... Or at least I believe it can. I think
proving that it can be wrong with glibc would still be a really nice
task to get done in cluts, and it would establish the usefulness of
cluts to the community outside of just advancing musl towards 1.0.

Luka, to answer your questions from chat:

1. Yes, an otherwise-unused account (actually just uid number; it
doesn't need any files, homedir, etc.) is required for testing. This
should be configurable eventually, but hard-coding some oddball value
near the max uid would probably be sufficient for now.

2. An ordinary user can lower their RLIMIT_NPROCS, but you'll be doing
this before dropping root, not after.

3. Each thread does not need to call setuid (the library function);
rather setuid (the library function itself) jumps through hoops to
make every thread call the setuid syscall. The unfortunate situation
is that each thread's syscall can independently succeed or fail, and
glibc only reports the status of one of them (the last one, I believe,
which is also the thread that called the setuid library function).

4. Your goal (at least for catching the bug believed to exist in glibc
and which musl hopefully does not shared) is to cause some of the
setuid syscalls to fail, but the last one to succeed. This will
require very [un]lucky timing, so the test probably needs to run many
times.

- RLIMIT_NPROCS should be greater than the number of threads you'll be
  testing with.

- When setuid (the library function) is first called, the number of
  processes with the target uid should already be equal (or just
  under) RLIMIT_NPROCS due to having forked some children in advance
  and set their uid to the target uid.

- These children should attempt to terminate themselves after the
  parent (with all its threads) calls setuid, but before all threads
  get scheduled and have a chance to make the setuid syscall. This
  way, some threads may fail, but the last one should succeed.

- After setuid (library function) returns, you check its return value
  and have each thread call getuid to check that they all have the
  target uid or that the library function returned failure. If the
  library function returned success but some threads still have uid=0,
  this is a potentially-serious security bug.

Does this make sense? By the way, there's no exact science to when the
children should terminate. The best I can think of is to run the test
repeatedly with varying (extremely short) delays, probably just
spinning in userspace or making a single call to sched_yield. You
might also want to vary the number of threads, and note that it may be
easier or harder with the number very small (e.g. equal to the number
of cores).

> I understand that Rich's proposed tests are about the libc wrapper
> functions that are thread-aware rather than about syscalls, yet I felt
> the above was relevant to the tests.

If the syscalls were correct (process-global) it would be a non-issue,
and if they could not fail due to RLIMIT_NPROC, it would also be a
non-issue. But as the kernel currently works (or rather doesn't work),
the userspace has to put a lot of effort into changing uids safely...

Rich

Re: Daily cluts reports

[Luka Marčetić]

Another week, I think I'm going to continue these daily reports because 
they've been incentive for me.
I've finished what was previously known as strn.c, and now is buf.c, and 
committed it (task VI. Functions which return strings in caller-provided 
buffers). If I missed any functions, let me know. You'll notice probably 
right of the back that tests for two functions are commented out. Well 
that's because one is faulty in glibc, and the other I assume not 
implemented in musl (that's in order). Not sure what I'll do with them.
Tomorrow I'll be going out of town, so I don't expect to write much. The 
day after that, I plan on doing and finishing threaded setuid testing 
task, and then, if you agree, spend the rest of the week fixing alloc.c, 
and then rewriting string.c, and hopefully adding a lot or all of the 
functions that go in it not long after that.
Till tomorrow,
Luka.

Re: Daily reports: Friday

[Solar Designer]

Luka -

On Sat, Jul 09, 2011 at 05:30:42PM +0200, Luka Mar??eti?? wrote:
> Oh, ok. I should've ommitted the "-cont" I agree. However, being Re:'s 
> to each other, I hope they still fall under the same thread.

JFYI:

"Re:" has nothing to do with threading, which normally works based on
Message-Id/In-Reply-To/References headers (this is what blists uses, and
I think Gmane does as well).  So you may completely change the Subject,
but as long as you use your MUA's "reply" feature, you add to the same
thread.  Some mailing list archives do substring match on Subjects,
though - I think MARC does.  But adding "Re:" doesn't help them either.

> As an 
> orientation, I may use the latest commits eg "strn.c + comon/String.c" 
> as part of the Subject, or I may drop differentiation completely and 
> just have us rely on time stamps. In the end, there's always this to 
> monitor specific commits: https://github.com/lmarcetic/cluts/commits/master

Please continue to post daily reports.  Start the message Subjects with
"cluts: " and follow that with either the report's date (e.g., "07/13")
or specific info on changes made (e.g., "such-and-such tests").

And please continue to post weekly reports as well - on Mondays.  These
should summarize your accomplishments for last week and describe what
you intend to work on next.  I feel that the daily communication, while
very helpful, is no replacement for weekly summaries.

Thanks,

Alexander

cluts: strerror_r() test (was: Daily cluts reports)

[Solar Designer]

Luka, Rich -

On Tue, Jul 12, 2011 at 12:59:13AM +0200, Luka Mar??eti?? wrote:
> I've finished what was previously known as strn.c, and now is buf.c, and 
> committed it (task VI. Functions which return strings in caller-provided 
> buffers). If I missed any functions, let me know. You'll notice probably 
> right of the back that tests for two functions are commented out. Well 
> that's because one is faulty in glibc, and the other I assume not 
> implemented in musl (that's in order).

I've uncommented the test for strerror_r(), which you marked "glibc
fail", and it passed the test on glibc 2.3.6 for me.  What exactly was
wrong with it (or rather with glibc) in your testing?

Thanks,

Alexander

Re: cluts: strerror_r() test

[Luka Marčetić]

On 07/14/2011 11:57 AM, Solar Designer wrote:
> Luka, Rich -
>
> I've uncommented the test for strerror_r(), which you marked "glibc
> fail", and it passed the test on glibc 2.3.6 for me.  What exactly was
> wrong with it (or rather with glibc) in your testing?
>
> Thanks,
>
> Alexander

The test was uncommented yesterday morning, as I found it was my fault 
that it crashed, not glibc's. Actually, I think it was -O2 that helped 
me realize that, after I had uncommented the function. Here's the 
relevant diff:
https://github.com/lmarcetic/cluts/commit/803ebc888ebe6656287034739229baa93376d0fc#tests/buf.c
You can see that strerror_r was passed size-1, although size was not 
initialized (or rather, it was initialized by a test before that one). 
Strerror_r implementations are free to redirect a passed pointer to 
immutable memory if size(buflen) argument is sufficiently large. Of 
course, wanting to write to s[size-1] would SIGSEGV in that case. My 
assumption was that glibc redirected the pointer even though I gave it 
size-1, in which case it's incorrect behavior and it should simply copy 
to the provided buffer. Turns out that's not the case, and the fail was 
mine.
Luka.

Re: cluts: strerror_r() test

[Solar Designer]

Luka,

On Thu, Jul 14, 2011 at 12:41:35PM +0200, Luka Mar??eti?? wrote:
> The test was uncommented yesterday morning,

Oh, I am using a tree I pulled yesterday morning as well, apparently
before that change.

Thank you for explaining this.

Alexander

Re: cluts: strerror_r() test

[Rich Felker]

On Thu, Jul 14, 2011 at 12:41:35PM +0200, Luka Marčetić wrote:
> one). Strerror_r implementations are free to redirect a passed
> pointer to immutable memory if size(buflen) argument is sufficiently

I don't see how this can be. sterror_r (the correct standard function
not the GNU bastardization) has no way of returning a pointer to a
string. Due to the interface design, it must write into the provided
buffer. By the way, this is another reason _POSIX_C_SOURCE or
_XOPEN_SOURCE must be defined - glibc likes to give you nonstandard
GNU functions by default...

> large. Of course, wanting to write to s[size-1] would SIGSEGV in

Actually it would probably just corrupt malloc data structures and
lead to havoc much later in the program. To test you could use a trick
like the string function tests, but that's really overkill. Just
allocating a buffer that's large enough, pre-filling it with an
unusual value, and calling the function with a shorter length
parameter should work. Then you can check that none of the fill bytes
were clobbered past the allowed length.

I hope this makes sense...

Rich

Re: cluts: strerror_r() test

[Luka Marčetić]

On 07/14/2011 07:55 PM, Rich Felker wrote:
> On Thu, Jul 14, 2011 at 12:41:35PM +0200, Luka Marčetić wrote:
>> one). Strerror_r implementations are free to redirect a passed
>> pointer to immutable memory if size(buflen) argument is sufficiently
> I don't see how this can be. [...]

Neither does the standard, ##C lied to me ;-)

>> large. Of course, wanting to write to s[size-1] would SIGSEGV in
> Actually it would probably just corrupt malloc data structures and
> lead to havoc much later in the program. To test you could use a trick
> like the string function tests, but that's really overkill. Just
> allocating a buffer that's large enough, pre-filling it with an
> unusual value, and calling the function with a shorter length
> parameter should work. Then you can check that none of the fill bytes
> were clobbered past the allowed length.
>
> I hope this makes sense...

Unfortunately, no, I don't get any of it.

Re: Daily cluts reports

[Luka Marčetić]

I've committed the threaded setuid test (needs to run as root.. hmm i 
should've written the check). However, it's slow and it doesn't fail. 
I'd appreciate if someone looks it over. I'll probably be working on it 
tomorrow still, since I don't have a good feeling about it. Still not 
sure yet which task I'll move on to after that, probably 7 (testing 
functions that allocate string buffers iirc), or, I might start fixing 
alloc.c tomorrow. Suggestions and comments are as always welcome.
Thanks
-Luka

Re: Daily cluts reports - numeric, setuid, and mid-term evaluation

[Luka Marčetić]

Greetings.

The results of coding today:
     * Polished numeric tests - very much of the credit goes to Rich 
(thanks). Hopefully these tests are "production quality" now, though 
there's always room for new ones and suggestions are welcome.
     * Fixing setuid.c, which should do its job of testing setuid/getuid 
in a threaded environment now - those who are following are probably 
interested in the results: The test indeed reports failure on certain 
libc's, but before I can say with confidence that the test is correct, 
I'm going to need a second pair of eyes, so if you're willing to review 
it please do fetch the file. More about this in #musl.

Next up:
     * writing a new test collection, that test functions that allocate 
buffers (#7), or
     * rewriting (alloc.c), or
     * maybe even something else entirely

--Luka

P.S. I've just been informed that I've passed mid-term evaluations, so 
thank you to all that have put up with me so far. Especially, of course, 
to my mentor, Rich (most of all for your help and guidance), and the 
project leader Alexander (most of all for the incentive and 
involvement). Now begins work to pass the the second evaluation also ;-) 
and finish the set tasks.

Re: Daily cluts reports - numeric, setuid, and mid-term evaluation

[Rich Felker]

On Sat, Jul 16, 2011 at 12:47:56AM +0200, Luka Marčetić wrote:
>     * Fixing setuid.c, which should do its job of testing
> setuid/getuid in a threaded environment now - those who are
> following are probably interested in the results: The test indeed
> reports failure on certain libc's, but before I can say with
> confidence that the test is correct, I'm going to need a second pair
> of eyes, so if you're willing to review it please do fetch the file.
> More about this in #musl.

I'm glad you were able to get results! In the current form, the test
isn't checking exactly what it's supposed to, but it's very close.
What you're testing is for mismatch in the getuid() results for the
first- and last-created threads. There are a couple problems with this
but they're easily fixed:

Issue 1: The first- and last-created threads are not necessarily the
first and last threads to make the syscall. By checking that *all*
threads have the same result, rather than just the first and last, you
could find failures with a lot fewer tries.

Issue 2: While I believe it's "A Bad Thing" and non-conformant for
getuid() to ever return different results in different threads, the
*dangerous* case is when setuid() reported success but didn't actually
succeed in all threads. I would ignore the result (or only print a
warning, and continue searching for a more serious failure) when
setuid() returns -1. I sloppily made this change and no longer saw any
failures in musl, though it seems like it might be deadlocking
sometime... Haven't tested the change with glibc but I expect to still
see failures.

Rich

Re: Daily cluts reports - setuid reiteration

[Luka Marčetić]

Rich and I worked on the setuid test, and are still trying to get glibc 
to (really) err. Forgive overcomitting, but at least the file up there 
is up-to-date if you want to check it out. Tomorrow: Sunday. After that, 
setuid again probably, then alloc.c, then #7 (malloc'd buffers) and then 
I'll have to see what to do with strings.c, and how to proceed.
Luka.