On Fri, 28 Apr 2023 at 14:23, Evgeniy Baskov <baskov@xxxxxxxxx> wrote: > > On 2023-04-24 19:57, Ard Biesheuvel wrote: > > This series is conceptually a combination of Evgeny's series [0] and > > mine [1], both of which attempt to make the early decompressor code > > more > > amenable to executing in the EFI environment with stricter handling of > > memory permissions. > > > > My series [1] implemented zboot for x86, by getting rid of the entire > > x86 decompressor, and replacing it with existing EFI code that does the > > same but in a generic way. The downside of this is that only EFI boot > > is > > supported, making it unviable for distros, which need to support BIOS > > boot and hybrid EFI boot modes that omit the EFI stub. > > > > Evgeny's series [0] adapted the entire decompressor code flow to allow > > it to execute in the EFI context as well as the bare metal context, and > > this involves changes to the 1:1 mapping code and the page fault > > handlers etc, none of which are really needed when doing EFI boot in > > the > > first place. > > > > So this series attempts to occupy the middle ground here: it makes > > minimal changes to the existing decompressor so some of it can be > > called > > from the EFI stub. Then, it reimplements the EFI boot flow to > > decompress > > the kernel and boot it directly, without relying on the trampoline > > code, > > page table code or page fault handling code. This allows us to get rid > > of quite a bit of unsavory EFI stub code, and replace it with two clear > > invocations of the EFI firmware APIs to clear NX restrictions from > > allocations that have been populated with executable code. > > > > The only code that is being reused is the decompression library itself, > > along with the minimal ELF parsing that is required to copy the ELF > > segments in place, and the relocation processing that fixes up absolute > > symbol references to refer to the correct virtual addresses. > > > > Note that some of Evgeny's changes to clean up the PE/COFF header > > generation will still be needed, but I've omitted those here for > > brevity. > > My series also implements W^X for both UEFI and non-UEFI boot paths, but > I > agree that we can just consider non-UEFI code legacy and it would be > better > to avoid touching it and encourage everyone to use UEFI code path on x86 > instead. If PE format will also get fixed with either my patches or some > others, I do like your approach more than mine, as it removes a lot of > old > cruft but does not break things (as far as I see). Seems like a perfect > compromise between [1] and my approach. > Thanks, I'm glad we agree. > I've briefly tested the patches and looked through them and they look > good > to me. Two things I've noticed: > * there's one TSC-related TODO; > * probably we want to clear .bss in efi32_stub_entry and > efi64_stub_entry > for UEFI handover protocol, since it's unfortunately still present > and > .bss will contain garbage. I'll look into that. > I'll probably do some more testing on the weekend and let you know if I > find something. > Yes, please. > Please tell me if/when you are going to merge these or similar, and I > will > clean up and rebase PE-related patches on top of these. > > I'd also like to send W^X patches for EFISTUB (omitting the non-UEFI > boot > path) as a follow up after the PE file header will get fixed. They will > be > considerably smaller with this approach and will not touch legacy code. >
