From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
the arch/x86 maintainers <x86@kernel.org>,
"H.J. Lu" <hjl.tools@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [GIT PULL] x86/shstk change for v6.10
Date: Wed, 15 May 2024 10:07:33 +0200 [thread overview]
Message-ID: <ZkRtRcaqO+4jy3QW@gmail.com> (raw)
In-Reply-To: <CAHk-=wiAXOLja2AqBzPZE+k9DKX0wjBGKZT+m2DN_hariyA0Pw@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, 13 May 2024 at 01:13, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > Enable shadow stacks for x32.
> >
> > While we normally don't do such feature-enabling on 32-bit
> > kernels anymore, this change is small, straightforward & tested on
> > upstream glibc.
>
> Color me confused.
>
> "feature-enabling on 32-bit kernels"
>
> This is not for 32-bit kernels, as far as I can tell. This is just the
> x32 user mode for x86-64 kernels.
>
> Or am I missing something?
Brainfart: feature-enabling for 32-bit user-space ...
> I've pulled this, but does anybody actually use x32? I feel like it
> was a failed experiment. No?
Yeah, so H.J. Lu suggested that shadow-stacks are a natural extension of
our security facilities on OSs where x32 is already enabled:
https://lore.kernel.org/all/CAMe9rOo1ZONFgBkuN_Ni3REBRsedNwj3gNnXj1oxB0bQzuNipA@mail.gmail.com/
H.J: *which* are those OSs? I don't think any major Linux distro enables
x32 anymore - here's Ubuntu and Fedora for example:
kepler:~/tip> grep X32 /boot/config-6.5.0-35-generic
# CONFIG_X86_X32_ABI is not set
kepler:~/s/fedora> grep X32 lib/modules/6.9.0-64.fc41.x86_64/config
# CONFIG_X86_X32_ABI is not set
Another feedback was that the observed lack of x32 kernel regressions
upstream could be because 'it just works':
https://lore.kernel.org/all/CAMe9rOoEQ3jUUXy+Kai9Hg83b+79azmGfu8DBR=A3HSL05kj0A@mail.gmail.com/
... so at this point I think we should be permissive towards well-tested
patches, barring contrary evidence.
'Contrary evidence' would be for example some x32 regression that wasn't
fixed for a long time while nobody cared, at which point we'd remove x32
instead of fixing something that wasn't working for a long time. I'm not
aware of such a regression yet, BYMMV.
Thanks,
Ingo
next prev parent reply other threads:[~2024-05-15 8:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-13 8:13 [GIT PULL] x86/shstk change for v6.10 Ingo Molnar
2024-05-14 2:38 ` Linus Torvalds
2024-05-14 9:27 ` Borislav Petkov
2024-05-15 8:07 ` Ingo Molnar [this message]
2024-05-23 15:14 ` Nathan Chancellor
2024-05-14 2:51 ` pr-tracker-bot
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=ZkRtRcaqO+4jy3QW@gmail.com \
--to=mingo@kernel.org \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@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.