From: Kees Cook <keescook@chromium.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
Peter Zijlstra <peterz@infradead.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-kernel@vger.kernel.org, Darren Hart <dvhart@infradead.org>,
Andy Shevchenko <andy@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, linux-efi@vger.kernel.org,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] x86/mm+efi: Avoid creating W+X mappings
Date: Fri, 23 Sep 2022 14:19:43 -0700 [thread overview]
Message-ID: <202209231417.F73F40060@keescook> (raw)
In-Reply-To: <CAMj1kXHckEg6rwBSEc6piu=-JZzyDh7j+pvGSFp1OBUQuofrEQ@mail.gmail.com>
On Fri, Sep 23, 2022 at 09:53:02PM +0200, Ard Biesheuvel wrote:
> On Fri, 23 Sept 2022 at 20:31, Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Sep 23, 2022 at 04:26:58PM +0200, Ard Biesheuvel wrote:
> > > I was basically making the point that we still support i386 without
> > > PAE (which is a prerequisite for supporting non-executable mappings),
> > > and if we are going to be pedantic about security on this
> > > architecture, we should probably make PAE mandatory as well.
> >
> > My expectation would be that if someone is running modern kernels on i386,
> > they're not using PAE. If they care about PAE, I'd expect them to have
> > long since moved to x86_64.
> >
>
> Not sure I follow. If they care about PAE, they turn it on. Or do you
> mean 'if they care about being able to address lots of physical
> memory'? Because the *other* reason you might care about PAE is
> because it gives you NX support.
Right, I meant if they care about NX (and the topic of this thread)
they want PAE, and if they want PAE, they likely moved to x86_64 long
long ago for new kernels.
> But currently, PAE is not even enabled in the i386_defconfig, and
> defaults to off. This means people that are unaware of this won't
> enable it, and will be running without NX support.
And they all make me cry. ;)
> > > If we are ok with the current state, enabling this permission check on
> > > i386 makes no sense.
> >
> > I'd agree. If it's a choice between "spend a lot of time making sure
> > this works correctly on i386" and "don't do this at all on i386", I
> > would pick the latter. If someone steps up to do the former, then by
> > all means take the patches.
> >
>
> OK, so it seems we're all in violent agreement here. And if there is
> ever a push for enabling security features on 32-bit, we can add this
> to the laundry list of things that need to be looked at.
Yup.
--
Kees Cook
next prev parent reply other threads:[~2022-09-23 21:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-29 10:18 [PATCH v2] x86/mm: Refuse W^X violations Peter Zijlstra
2022-08-29 19:08 ` Kees Cook
2022-09-01 18:17 ` [tip: x86/mm] " tip-bot2 for Peter Zijlstra
2022-09-21 20:07 ` [PATCH v2] " Guenter Roeck
2022-09-21 20:59 ` Dave Hansen
2022-09-21 22:59 ` Guenter Roeck
2022-09-22 3:09 ` Guenter Roeck
2022-09-22 7:46 ` Peter Zijlstra
2022-09-22 15:00 ` Dave Hansen
2022-09-22 16:38 ` Guenter Roeck
2022-09-22 16:29 ` Guenter Roeck
2022-09-22 19:31 ` [PATCH] x86/mm+efi: Avoid creating W+X mappings Dave Hansen
2022-09-22 22:08 ` Ard Biesheuvel
2022-09-23 6:59 ` Peter Zijlstra
2022-09-23 9:49 ` Ard Biesheuvel
2022-09-23 13:58 ` Guenter Roeck
2022-09-23 14:26 ` Ard Biesheuvel
2022-09-23 18:31 ` Kees Cook
2022-09-23 19:53 ` Ard Biesheuvel
2022-09-23 21:19 ` Kees Cook [this message]
2022-09-23 22:15 ` Dave Hansen
2022-09-23 22:32 ` Eric W. Biederman
2022-09-24 0:04 ` Kees Cook
2022-10-02 10:33 ` [PATCH v2] x86/mm: Refuse W^X violations Pavel Machek
2022-10-24 15:27 ` Steven Rostedt
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=202209231417.F73F40060@keescook \
--to=keescook@chromium.org \
--cc=andy@infradead.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dvhart@infradead.org \
--cc=hpa@zytor.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--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.