[19216] in Kerberos_V5_Development
Re: C99 Features
daemon@ATHENA.MIT.EDU (Nico Williams)
Fri Jun 19 15:12:59 2015
Date: Fri, 19 Jun 2015 14:12:48 -0500
From: Nico Williams <nico@cryptonector.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Message-ID: <20150619191248.GH6117@localhost>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1434601779.15953.12.camel@redhat.com>
Cc: Danilo Almeida <dalmeida@mit.edu>, "'krbdev@mit.edu'" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Thu, Jun 18, 2015 at 12:29:39AM -0400, Nathaniel McCallum wrote:
> Most of this is greatly diminished by the various stack protection
> techniques found in modern compilers. It is getting harder and harder
> to even trigger these kinds of errors.
Standard techniques for protecting against buffer overflows don't help
here. The problem is that the emitted code cannot know where the end of
the stack lies. What can the compiler do? It could:
- Write a zero to one word of each page of the array in sequence,
hoping that the guard page will never be missed and will cause stack
growth or SEGFAULT in all cases.
This requires knowing the page size for the stack, but assuming a
small page seems reasonable.
This can also be done in user code, but it does require knowing the
direction in which the stack grows.
(Presumably the performance impact of this probing should be minimal.)
- Call a system call to ensure the stack is large enough for the
requested allocation.
This requires adding that system call to the ABI.
Whatever the compiler does, the result has to be free of race
conditions.
Do compilers emit such code?
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
