All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Elena Reshetova <elena.reshetova@intel.com>,
	David Laight <David.Laight@aculab.com>,
	Will Deacon <will@kernel.org>,
	clang-built-linux@googlegroups.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] stack: replace "o" output with "r" input constraint
Date: Wed, 5 May 2021 14:12:32 -0700	[thread overview]
Message-ID: <YJMKQFscszFcf5fE@archlinux-ax161> (raw)
In-Reply-To: <YIIcoz4fHjVjWHTI@archlinux-ax161>

On Thu, Apr 22, 2021 at 06:02:27PM -0700, Nathan Chancellor wrote:
> On Mon, Apr 19, 2021 at 04:17:41PM -0700, Kees Cook wrote:
> > From: Nick Desaulniers <ndesaulniers@google.com>
> > 
> > "o" isn't a common asm() constraint to use; it triggers an assertion in
> > assert-enabled builds of LLVM that it's not recognized when targeting
> > aarch64 (though it appears to fall back to "m"). I've fixed this in LLVM
> > 13 now, but there isn't really a good reason to be using "o" in particular
> > here. To avoid causing build issues for those using assert-enabled builds
> > of earlier LLVM versions, the constraint needs changing.
> > 
> > Instead, if the point is to retain the __builtin_alloca(), we can make ptr
> > appear to "escape" via being an input to an empty inline asm block. This
> > is preferable anyways, since otherwise this looks like a dead store.
> > 
> > While the use of "r" was considered in
> > https://lore.kernel.org/lkml/202104011447.2E7F543@keescook/
> > it was only tested as an output (which looks like a dead store, and
> > wasn't sufficient). Use "r" as an input constraint instead, which
> > behaves correctly across compilers and architectures:
> > https://godbolt.org/z/E9cd411ob
> > 
> > Link: https://reviews.llvm.org/D100412
> > Link: https://bugs.llvm.org/show_bug.cgi?id=49956
> > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> > Tested-by: Kees Cook <keescook@chromium.org>
> > Fixes: 39218ff4c625 ("stack: Optionally randomize kernel stack offset each syscall")

Kees, were you planning on taking this to Linus or someone else? It
would be nice to have this in for -rc1 (although I understand it might
be too late), if not, by -rc2.

Cheers,
Nathan

> > Signed-off-by: Kees Cook <keescook@chromium.org>
> 
> I built arm64 defconfig with and without
> CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT with LLVM 12 (which does not have
> Nick's LLVM fix) without any issues and did a quick boot test in QEMU,
> nothing exploded.
> 
> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> Tested-by: Nathan Chancellor <nathan@kernel.org>
> 
> > ---
> >  include/linux/randomize_kstack.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/randomize_kstack.h b/include/linux/randomize_kstack.h
> > index fd80fab663a9..bebc911161b6 100644
> > --- a/include/linux/randomize_kstack.h
> > +++ b/include/linux/randomize_kstack.h
> > @@ -38,7 +38,7 @@ void *__builtin_alloca(size_t size);
> >  		u32 offset = raw_cpu_read(kstack_offset);		\
> >  		u8 *ptr = __builtin_alloca(KSTACK_OFFSET_MAX(offset));	\
> >  		/* Keep allocation even after "ptr" loses scope. */	\
> > -		asm volatile("" : "=o"(*ptr) :: "memory");		\
> > +		asm volatile("" :: "r"(ptr) : "memory");		\
> >  	}								\
> >  } while (0)
> >  
> > -- 
> > 2.25.1
> > 

  reply	other threads:[~2021-05-05 21:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-19 23:17 [PATCH] stack: replace "o" output with "r" input constraint Kees Cook
2021-04-23  1:02 ` Nathan Chancellor
2021-05-05 21:12   ` Nathan Chancellor [this message]
2021-05-05 21:19     ` Kees Cook
2021-05-11  8:02 ` [tip: core/urgent] stack: Replace " tip-bot2 for Nick Desaulniers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YJMKQFscszFcf5fE@archlinux-ax161 \
    --to=nathan@kernel.org \
    --cc=David.Laight@aculab.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=elena.reshetova@intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.