[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZCCSsFGqTFWknGBL@1wt.eu>
Date: Sun, 26 Mar 2023 20:45:04 +0200
From: Willy Tarreau <w@....eu>
To: Thomas Weißschuh <thomas@...ch.de>
Cc: Alexey Dobriyan <adobriyan@...il.com>,
Thomas Weißschuh <linux@...ssschuh.net>,
"Paul E. McKenney" <paulmck@...nel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/8] tools/nolibc: tests: add test for -fstack-protector
On Sun, Mar 26, 2023 at 01:42:35PM -0500, Thomas Weißschuh wrote:
>
> Mar 26, 2023 13:30:21 Alexey Dobriyan <adobriyan@...il.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. 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).
Willy
Powered by blists - more mailing lists