This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [resend] Re: handling overflow in sbrk.


On Thu, May 29, 2008 at 17:12, Carlos O'Donell <carlos@systemhalted.org> wrote:
>> re: slow path: well, you're just about to do a syscall which changes
>> your page tables... *and* it's a correctness issue.  Yes probably
>> better to be handled in the kernel with a normal error return ... but
>> it's not.
>
> Think about a kernel fix:
> 1. No added instructions in the userspace fast path.
> 2. Possibly fixes other C libraries (uclibc?)
> 3. Overflow check exists in one location handled properly for S_G_U
> and S_G_D cases.
>
> In the end I think we need to fix the kernel instead of glibc.

That seems reasonable, except for the "minor" issue that I don't
actually think you can do this with the existing syscall on most
architectures.  (I.e., you'd need another syscall entry to do it.)
The problem is that much of the libc code in existence doesn't handle
brk errors.

Looking at 2.3.6 sources, a number of archiectures don't check for
errors at all AFAICT (including x86) or actually *do* check for an
error return but handle the result incorrectly AFAICT (including
x86_64).  It looks like some architectures get it right (e.g., alpha,
AFAICT), but they're the exception.

The situation in current libc sources seems similar.


BTW, "stack grows up" vs. "stack grows down" is not relevant here IMO.
 The issue is that when you get an error -- for whatever reason -- and
the break pointer also happens to overflow, the current brk + sbrk
error detection code for linux doesn't notice that there's an error.

(Note that the test doesn't need to change for which way the stack
grows, but *does* need to avoid hitting the memory occupied by the
stack before the sbrk attempt that causes the break pointer to
overflow.


I'll see about contributing this test to someplace relevant.
Unfortunately, I don't know that I have time to actually try to get
this fixed "for real" in linux (since it would require non-trivial
changes IMO to both the kernel and then, subsequently, libc).


chris


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]