Messages in this thread |  | | Date | Tue, 02 Aug 2022 03:25:20 +0300 | From | Evgeniy Baskov <> | Subject | Re: [RFC PATCH 0/8] x86_64: Harden compressed kernel, part 1 |
| |
On 2022-08-01 19:48, Dave Hansen wrote: > On 8/1/22 09:38, Evgeniy Baskov wrote: >> This is the first half of changes aimed to increase security of early >> boot code of compressed kernel for x86_64 by enforcing memory >> protection >> on page table level. > > Could you share a little more background here? Hardening is good, but > you _can_ have too much of a good thing. > > Is this part of the boot cycle becoming a target for attackers in > trusted boot environments? Do emerging confidential computing > technologies like SEV and TDX cause increased reliance on compressed > kernel security? > > In other words, why is *THIS* important versus all the other patches > floating around out there?
Now compressed kernel code becomes larger, partially because of adding SEV and TDX, so it worth adding memory protection here.
First part implements partial memory protection for every way of booting the kernel, and second adds full W^X implementation specifically for the UEFI code path. First part also contains prerequisite changes for the second part like adding explicit memory allocation in extraction code and adjusting ld-script to produce ELF images suitable for mapping PE sections on top of them with appropriate access rights.
One of pros for this patch set is that is would reveal invalid memory accesses by removing implicit memory mapping and reducing access rights for mapped memory. So it makes further development of the compressed kernel code less error prone.
Furthermore, memory protection indeed makes it harder to attack kernel during boot cycle. And unlike TDX and SEV it does not not only aim to protect kernel from attacks outside of virtualized environments but it also makes attacking the kernel booting on bare metal harder. If some code injection vulnerability lives inside compressed kernel code this will likely make it harder to exploit.
Another thing is that it should not bring any noticeable overhead. Second part can actually reduce overhead slightly by removing the need to copy the kernel image around during boot process and extracting the kernel before exiting EFI boot services.
Second part also makes kernel more spec compliant PE image as a part of an implementation of memory protection in EFI environment. This will allow booting the kernel with stricter implementations of PE loaders, e.g. [1]. And stricter PE loader is really desired, since current EDK II implementation contains numerous problems [2].
[1] https://github.com/acidanthera/audk/tree/secure_pe [2] https://arxiv.org/pdf/2012.05471.pdf
Thanks, Evgeniy Baskov
|  |