On Don, 2008-04-24 at 18:52 +0200, Michael Blizek wrote: > On 17:49 Thu 24 Apr , Bernd Petrovitsch wrote: > > On Don, 2008-04-24 at 17:08 +0200, Michael Blizek wrote: > > > It is not just cleaning the stack up. You have to make sure that no other > > > thread in the userspace accesses it. This means you have to unmap it first. > > > > Uuugh, that looks like a quite weird software design if one thread > > (which has his own stack) actually accesses data on the stack of another > > thread. > > Is there a compelling reason not to do that in a (more) sane way? > > This is a security risk. Somebody who does not have root permissions might do > this deliberately in order to inject code into the kernel - and gain full > access to the system. ACK. I didn't think that far. > > > Even > > > if it is not, you risk breaking some weird user-space programs which abuse > > > unused stack space (e.g. functions returning pointers to local variables...). > > > > That code is broken anyways as it violates the C standard (and gcc warns > > nowadays BTW). So IMHO no need to care about it. > > You are right. But some projects generate hundreds of warning when you compile > them. This patch means breaking them all at once when you are doing the next > kernel upgrade... Yes, but in that point I'm more of "that code is already broken and must be fixed but everyone ignores it since it runs neverthelss" faction. Perhaps gcc needs a patch to delete/poison 200 bytes of soon-to-be-unused stack space (or better the whole current local variable space on the stack frame) before a function returns. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
