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@xxxxxxxxxxxxxxx> wrote: > > > > From: Peter Zijlstra <peterz@xxxxxxxxxxxxx> > > > > 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.