Dave Hansen <dave.hansen@xxxxxxxxx> 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
