[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180102014915.GJ1627@brightrain.aerifal.cx>
Date: Mon, 1 Jan 2018 20:49:15 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Add comments to i386 assembly source
On Mon, Jan 01, 2018 at 02:57:02PM -0800, John Reiser wrote:
> There's a bug. clone() is a user-level function that can be used
> independently of the musl internal implementation of threads.
> Thus when clone() in musl/src/linux/clone.c calls
> return __syscall_ret(__clone(func, stack, flags, arg, ptid, tls, ctid));
> then the i386 implementation of __clone has no guarantee about
> the value in %gs, and it is a bug to assume that (%gs >> 3)
> fits in 8 bits.
The ABI is that at function call or any time a signal could be
received, %gs must always be a valid segment register value reflecting
the current thread's thread pointer. If this is violated, the program
has undefined behavior.
> The code in musl/src/thread/i386/clone.s wastes up to 12 bytes
> when aligning the new stack, by aligning before [pre-]allocating
> space for the one argument to the thread function.
I suspect the initial value happens to be aligned anyway in which case
reserving 16 bytes and aligning to 16 is the same as reserving 4 and
aligning to 16. If you think it's not, I don't mind changing if you
can do careful testing to make sure it doesn't introduce any bugs.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
