From: Jiri Slaby <jirislaby@kernel.org>
To: Dave Hansen <dave.hansen@intel.com>, bp@alien8.de
Cc: peterz@infradead.org, linux-kernel@vger.kernel.org,
Yu-cheng Yu <yu-cheng.yu@intel.com>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Kees Cook <keescook@chromium.org>,
Mike Rapoport <rppt@kernel.org>,
Pengfei Xu <pengfei.xu@intel.com>,
John Allen <john.allen@amd.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org
Subject: Re: [PATCH] x86: Let AS_WRUSS depend on X86_64
Date: Tue, 31 Oct 2023 15:04:21 +0100 [thread overview]
Message-ID: <786d3451-e3ac-4868-8d8b-28f106e13407@kernel.org> (raw)
In-Reply-To: <2b345b1c-73ce-4719-812f-ce638f665f77@intel.com>
On 31. 10. 23, 14:53, Dave Hansen wrote:
> On 10/31/23 03:21, Jiri Slaby (SUSE) wrote:
> ...
>> Provided the wruss instruction is 64-bit only (and used in pure 64-bit
>> X86_USER_SHADOW_STACK), it has little sense to have AS_WRUSS=y set on
>> 32-bit.
>>
>> Therefore, make the whole test dependent on X86_64 to ensure it's set
>> only on 64-bit.
> ...
>> config AS_WRUSS
>> def_bool $(as-instr,wrussq %rax$(comma)(%rbx))
>> + depends on X86_64
>> help
>> Supported by binutils >= 2.31 and LLVM integrated assembler
>
> What's the downside to just leaving this alone?
>
> This patch just seems wrong logically. Suppose some deranged person
> wanted 32-bit shadow stack support. They'd have to go hunt this down
> via trial and error instead of just enabling X86_USER_SHADOW_STACK.
All wrussq, rax, rbx can never be right on 32-bit anyway...
> Granted, that would take one crazy person five minutes to figure out why
> their .config is broken, but it still seems wrong. It's especially
> wrong without a comment because it logically reads something along the
> lines of "WRUSS is only available on x86_64 configs".
Which is right, or what am I missing?
> A better way to do this would be:
>
> config HAS_SHADOW_STACKS
> depends on X86_64
>
> config AS_WRUSS
> ...
> # Avoid setting AS_WRUSS on configs that don't need it:
> depends on HAS_SHADOW_STACKS
>
> config X86_USER_SHADOW_STACK
> bool "X86 userspace shadow stack"
> depends on AS_WRUSS
> depends on HAS_SHADOW_STACKS
>
> But that honestly doesn't seem worth it because (circling back to the
> first thing I wrote...) I don't really know what the benefit is to doing
> this in the first place.
Again, to avoid nonsense in 32bit configs produced by oldconfig (as I
noted in the commit log).
thanks,
--
js
suse labs
prev parent reply other threads:[~2023-10-31 14:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-31 10:21 [PATCH] x86: Let AS_WRUSS depend on X86_64 Jiri Slaby (SUSE)
2023-10-31 11:25 ` Borislav Petkov
2023-10-31 12:20 ` Masahiro Yamada
2023-10-31 13:34 ` Borislav Petkov
2023-10-31 13:59 ` Jiri Slaby
2023-10-31 14:05 ` Borislav Petkov
2023-10-31 14:10 ` Jiri Slaby
2023-10-31 13:53 ` Dave Hansen
2023-10-31 14:04 ` Jiri Slaby [this message]
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=786d3451-e3ac-4868-8d8b-28f106e13407@kernel.org \
--to=jirislaby@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=john.allen@amd.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pengfei.xu@intel.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rppt@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yu-cheng.yu@intel.com \
/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.