linux-kernel - Re: [RFC PATCH 0/8] x86_64: Harden compressed kernel, part 1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <893da11995f93a7ea8f7485d17bf356a@ispras.ru>
Date:   Tue, 02 Aug 2022 03:25:20 +0300
From:   Evgeniy Baskov <baskov@...ras.ru>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        Alexey Khoroshilov <khoroshilov@...ras.ru>
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