Messages in this thread | | | Date | Fri, 23 Sep 2022 08:59:53 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH] x86/mm+efi: Avoid creating W+X mappings |
| |
On Fri, Sep 23, 2022 at 12:08:57AM +0200, Ard Biesheuvel wrote: > On Thu, 22 Sept 2022 at 21:32, Dave Hansen <dave.hansen@linux.intel.com> wrote: > > > > From: Peter Zijlstra <peterz@infradead.org> > > > > I'm planning on sticking this in x86/mm so that it goes upstream > > along with the W+X detection code. > > > > -- > > > > A recent x86/mm change warns and refuses to create W+X mappings. > > > > The 32-bit EFI code tries to create such a mapping and trips over > > the new W+X refusal. > > > > Make the EFI_RUNTIME_SERVICES_CODE mapping read-only to fix it. > > > > This is not safe. EFI_RUNTIME_SERVICES_CODE covers both .text and > .data sections of the EFI runtime PE/COFF executables in memory, so > you are essentially making .data and .bss read-only. (Whether those > executables actually modify their .data and .bss at runtime is a > different matter, but the point is that it used to be possible) > > More recent firmwares may provide a 'memory attributes table' > separately which describes the individual sections, but older 32-bit > firmwares are not even built with 4k section alignment, so code and > data may share a single page. Note that we haven't wired up this > memory attributes table on i386 at the moment, and I seriously doubt > that 32-bit firmware in the field exposes it. > > Can we just turn off this feature for 32-bit?
Goodie; some seriously security minded people who did that EFI turd :/ Let's just heap it on the pile of 32bit sucks and should not be considered a security target anymore and indeed kill this feature.
| |