Messages in this thread | | | Date | Sun, 26 Mar 2023 22:38:39 +0300 | From | Alexey Dobriyan <> | Subject | Re: [PATCH 6/8] tools/nolibc: tests: add test for -fstack-protector |
| |
On Sun, Mar 26, 2023 at 08:45:04PM +0200, Willy Tarreau wrote: > On Sun, Mar 26, 2023 at 01:42:35PM -0500, Thomas Weißschuh wrote: > > > > Mar 26, 2023 13:30:21 Alexey Dobriyan <adobriyan@gmail.com>: > > > > > Willy Tarreau wrote: > > >> #if defined(__clang__) > > >> __attribute__((optnone)) > > >> #elif defined(__GNUC__) > > >> __attribute__((optimize("O0"))) > > >> #endif > > >> static int smash_stack(void) > > >> { > > >> char buf[100]; > > >> > > >> for (size_t i = 0; i < 200; i++) > > >> buf[i] = 'P'; > > >> > > >> return 1; > > >> } > > > > > > If you want to corrupt the stack, corrupt the stack! > > > > I do! > > > > > asm( > > > ".globl f\n" > > > "f:\n" > > > "movq $0, (%rsp)\n" > > > "ret\n" > > > ".type f,@function\n" > > > ".size f,.-f" > > > ); > > > > No problems with optimisation levels. > > > > Wouldn't this be architecture-specific? > > Yes it would.
Which is OK. Corrupting return address is very arch-specific.
> I'm not seeing any issue with your approach instead, let's > keep it as-is for now (also it does what the stack protector is supposed > to catch anyway).
There are no guarantess about stack layout and dead writes. The test doesn't corrupt stack reliably, just 99.99% reliably.
| |