From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Kees Cook <keescook@chromium.org>,
Ard Biesheuvel <ardb@kernel.org>,
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 17:32:45 -0500 [thread overview]
Message-ID: <87a66p3enm.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <69e00173-087e-6a22-7a02-0c1212f42065@intel.com> (Dave Hansen's message of "Fri, 23 Sep 2022 15:15:15 -0700")
Dave Hansen <dave.hansen@intel.com> writes:
> On 9/23/22 14:19, Kees Cook wrote:
>>> 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. ;)
>
> It's been like that for a long time, presumably because the defconfig
> should *boot* in as many cases as possible. It wouldn't be hard to
> change. It also wouldn't be hard to default to HIGHMEM4G (non-PAE) on
> targeted builds for CPUs that don't support it. Patch attached to do
> that, if anyone else has an opinion.
>
> We should probably just leave i386 alone, but it breaks my heart to see
> Kees in tears.
Is it at all possible to simply drop efi support for 32bit builds?
Last I looked (and it was quite a while ago) efi was only supported
same architecture. So we are talking about 32bit efi for 32bit kernels.
I think there were only a handful of systems that ever shipped 32bit
efi, because when 32bit efi came out 64bit processors had been shipping
for several years already.
We still probably need to deal with whatever is needed for the BIOS.
If there are enough interesting systems to care to keep the few systems
that shipped with 32bit efi support going it probably does make sense to
change how it is implemented because using the kernel's page tables has
been nasty and given kexec all kinds of challenges to support because
not only does efi happen strange mapping attributes but efi also winds
up living at a fixed virtual address, that can't be changed. So if you
care about anything like address space layout randomization efi provides
a well know fixed target that defeats all of your work there as well.
Can we do something to isolate 32bit efi so it is not a painpoint?
Given how long 8bit and 16bit systems have lasted I rather suspect 32bit
x86 will last in some embedded form for a very long time. PAE came in
about the first pentium's I think so most embedded i386 processors
should support it.
Eric
next prev parent reply other threads:[~2022-09-23 22:33 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
2022-09-23 22:15 ` Dave Hansen
2022-09-23 22:32 ` Eric W. Biederman [this message]
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=87a66p3enm.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=andy@infradead.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dvhart@infradead.org \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox