On Sun, Jul 1, 2018 at 6:33 PM, Michael Ellerman <m...@ellerman.id.au> wrote: > Kees Cook <keesc...@chromium.org> writes: > >> On Fri, Jun 29, 2018 at 2:02 PM, Arnd Bergmann <a...@arndb.de> wrote: >>> On Fri, Jun 29, 2018 at 8:53 PM, Kees Cook <keesc...@chromium.org> wrote: >>>> In the quest to remove all stack VLA usage from the kernel[1], this >>>> switches to using a stack size large enough for the saved routine and >>>> adds a sanity check. >>>> >>>> [1] >>>> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com >>>> >>>> Signed-off-by: Kees Cook <keesc...@chromium.org> >>> >>> This seems particularly nice, not only avoids it the dynamic stack >>> allocation, it >>> also makes sure the new 0x500 handler doesn't overflow into the 0x600 >>> exception handler. >>> >>> It would help to explain how you arrived at that '256 byte' number in >>> the changelog though. >> >> Honestly, I just counted instructions, multiplied by 8 and rounded up >> to the next nearest power of 2, and the result felt right for giving >> some level of flexibility for code growth before tripping the WARN. :P >> >> I'm happy to adjust, of course. :) > > What if we write it: > > char saved_0x500[0x600 - 0x500]; > > Hopefully the compiler is smart enough not to generate a VLA for that :)
Sure, that's fine. I'll send an updated patch. -Kees -- Kees Cook Pixel Security