From: Dave Hansen <dave.hansen@intel.com>
To: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>, 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 06:53:09 -0700 [thread overview]
Message-ID: <2b345b1c-73ce-4719-812f-ce638f665f77@intel.com> (raw)
In-Reply-To: <20231031102111.32142-1-jirislaby@kernel.org>
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.
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".
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.
next prev parent reply other threads:[~2023-10-31 13:53 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 [this message]
2023-10-31 14:04 ` Jiri Slaby
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=2b345b1c-73ce-4719-812f-ce638f665f77@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jirislaby@kernel.org \
--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.