Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 23 Jun 2020 13:42:30 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Kees Cook' <>, Arvind Sankar <>
CC: Thomas Gleixner <>, Elena Reshetova
	<>, "" <>, "Andy
 Lutomirski" <>, Peter Zijlstra <>,
	"Catalin Marinas" <>, Will Deacon <>,
	"Mark Rutland" <>, Alexander Potapenko
	<>, Alexander Popov <>, Ard Biesheuvel
	<>, Jann Horn <>,
	"" <>,
	<>, ""
	<>, ""
Subject: RE: [PATCH v4 3/5] stack: Optionally randomize kernel stack offset
 each syscall

From: Kees Cook
> Sent: 23 June 2020 01:56
> On Mon, Jun 22, 2020 at 08:05:10PM -0400, Arvind Sankar wrote:
> > But I still don't see anything _stopping_ the compiler from optimizing
> > this better in the future. The "=m" is not a barrier: it just informs
> > the compiler that the asm produces an output value in *ptr (and no other
> > outputs). If nothing can consume that output, it doesn't stop the
> > compiler from freeing the allocation immediately after the asm instead
> > of at the end of the function.
> Ah, yeah, I get what you mean.
> > I'm talking about something like
> > 	asm volatile("" : : "r" (ptr) : "memory");
> > which tells the compiler that the asm may change memory arbitrarily.
> Yeah, I will adjust it.
> > Here, we don't use it really as a barrier, but to tell the compiler that
> > the asm may have stashed the value of ptr somewhere in memory, so it's
> > not free to reuse the space that it pointed to until the function
> > returns (unless it can prove that nothing accesses memory, not just that
> > nothing accesses ptr).

Do you need another asm volatile("" : : "r" (ptr) : "memory");
(or similar) at the bottom of the function - that the compiler thinks
might access the memory whose address it thought got saved earlier?

I wonder if it would be easier to allocate the stack space
in the asm wrapper? At least as an architecture option.


Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.