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.

It applies memory protection to the compressed kernel code executing
outside EFI environment and makes all identity mappings explicit
to reduce probability of hiding erroneous memory accesses.

Second half makes kernel more compliant PE image and enforces memory
protection for EFISTUB code, thus completing W^X support for compressed
kernel.

I'll send second half for review later.

Evgeniy Baskov (8):
  x86/boot: Align vmlinuz sections on page size
  x86/build: Remove RWX sections and align on 4KB
  x86/boot: Set cr0 to known state in trampoline
  x86/boot: Increase boot page table size
  x86/boot: Support 4KB pages for identity mapping
  x86/boot: Setup memory protection for bzImage code
  x86/boot: Map memory explicitly
  x86/boot: Remove mapping from page fault handler

 arch/x86/boot/compressed/acpi.c         |  21 ++-
 arch/x86/boot/compressed/efi.c          |  19 ++-
 arch/x86/boot/compressed/head_64.S      |   7 +-
 arch/x86/boot/compressed/ident_map_64.c | 128 ++++++++++------
 arch/x86/boot/compressed/kaslr.c        |   4 +
 arch/x86/boot/compressed/misc.c         |  52 ++++++-
 arch/x86/boot/compressed/misc.h         |  16 +-
 arch/x86/boot/compressed/pgtable.h      |  20 ---
 arch/x86/boot/compressed/pgtable_64.c   |   2 +-
 arch/x86/boot/compressed/sev.c          |   6 +-
 arch/x86/boot/compressed/vmlinux.lds.S  |   6 +
 arch/x86/include/asm/boot.h             |  26 ++--
 arch/x86/include/asm/init.h             |   1 +
 arch/x86/include/asm/shared/pgtable.h   |  29 ++++
 arch/x86/kernel/vmlinux.lds.S           |  15 +-
 arch/x86/mm/ident_map.c                 | 186 ++++++++++++++++++++----
 16 files changed, 403 insertions(+), 135 deletions(-)
 delete mode 100644 arch/x86/boot/compressed/pgtable.h
 create mode 100644 arch/x86/include/asm/shared/pgtable.h

-- 
2.35.1

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?

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

On 8/1/22 17:25, Evgeniy Baskov wrote:
> 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.
...

Is it fair to say that the problems here are on the potential,
theoretical side rather than driven by practical, known issues that our
users face?

On 2022-08-02 05:41, Dave Hansen wrote:
> On 8/1/22 17:25, Evgeniy Baskov wrote:
>> 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.
> ...
> 
> Is it fair to say that the problems here are on the potential,
> theoretical side rather than driven by practical, known issues that our
> users face?

Partially. We do have known issues because kernel PE image is not 
compliant
with the MS PE and COFF specification v8.3 referenced by the UEFI 
specification.
UEFI implementations with stricter PE loaders (e.g. mentioned above) 
fail to
boot Linux kernel.

As for hardening side, these improvements are indeed just nice-to-haves.
But we believe it is good to have them if they are available for free.

Thanks,
Evgeniy Baskov

On 8/2/22 16:45, Evgeniy Baskov wrote:
> Partially. We do have known issues because kernel PE image is not
> compliant with the MS PE and COFF specification v8.3 referenced by
> the UEFI specification. UEFI implementations with stricter PE loaders
> (e.g. mentioned above) fail to boot Linux kernel.

That shows me that it's _possible_ to build a more strict PE loader that
wouldn't load Linux.  But, in practice is anyone using a more strict PE
loader?  Does anyone actually want that in practice?  Or, again, is this
more strict PE loader just an academic demonstration?

The README starts:

	This branch demonstrates...

That doesn't seem like something that's _important_ to deal with.
Sounds like a proof-of-concept.

Don't get me wrong, I'm all for improving thing, even if the benefits
are far off.  But, let's not fool ourselves.

On 2022-08-03 17:05, Dave Hansen wrote:
> 
> That shows me that it's _possible_ to build a more strict PE loader 
> that
> wouldn't load Linux.  But, in practice is anyone using a more strict PE
> loader?  Does anyone actually want that in practice?  Or, again, is 
> this
> more strict PE loader just an academic demonstration?
> 
> The README starts:
> 
> 	This branch demonstrates...
> 
> That doesn't seem like something that's _important_ to deal with.
> Sounds like a proof-of-concept.
> 
> Don't get me wrong, I'm all for improving thing, even if the benefits
> are far off.  But, let's not fool ourselves.

We have commercial closed-source UEFI firmware implementation at ISP RAS
that follows the behavior of the secure_pe branch. That firmware is used
as a part of [1].

[1] https://www.ispras.ru/en/technologies/asperitas/

Thanks,
Evgeniy Baskov

On Thu, Aug 04, 2022 at 01:41:58PM +0300, Evgeniy Baskov wrote:
> On 2022-08-03 17:05, Dave Hansen wrote:
> > 
> > That shows me that it's _possible_ to build a more strict PE loader that
> > wouldn't load Linux.  But, in practice is anyone using a more strict PE
> > loader?  Does anyone actually want that in practice?  Or, again, is this
> > more strict PE loader just an academic demonstration?
> > 
> > The README starts:
> > 
> > 	This branch demonstrates...
> > 
> > That doesn't seem like something that's _important_ to deal with.
> > Sounds like a proof-of-concept.
> > 
> > Don't get me wrong, I'm all for improving thing, even if the benefits
> > are far off.  But, let's not fool ourselves.
> 
> We have commercial closed-source UEFI firmware implementation at ISP RAS
> that follows the behavior of the secure_pe branch. That firmware is used
> as a part of [1].
> 
> [1] https://www.ispras.ru/en/technologies/asperitas/

Are there any plans on getting those changes merged back upstream to the
main UEFI codebase so that others can test this type of functionality
out?

thanks,

greg k-h

On 2022-08-04 14:22, Greg KH wrote:
...
> Are there any plans on getting those changes merged back upstream to 
> the
> main UEFI codebase so that others can test this type of functionality
> out?
> 
> thanks,
> 
> greg k-h

The initial prototype of the changes were published as a part of the
tianocore/edk2-staging[1], and a more up-to-date open source version
was published as a part of the acidanthera/audk. This version is 
currently
being integrated with the EDK II build system, and its malfunctioning
is currently the main technical issue for integrating changes
into the main branch.

It is hard to estimate when the merge with the edk2 mainline happens,
but we are committed to doing this. The amount of changes needed
is quite large, and simply getting approval from all the maintainers
will take time even if they are all willing to get this in.
On the good side, several parties, Microsoft in particular,
were interested in upstreaming this code, so we have moderate
optimism for the future.

In case you are interested in the details, there is also academic
material available, describing the issues and the changes made,
which can help to shed some light on the implementation[3][4].

[1] 
https://github.com/tianocore/edk2-staging/tree/2021-gsoc-secure-loader
[2] https://github.com/acidanthera/audk/tree/secure_pe
[3] https://arxiv.org/pdf/2012.05471.pdf
[4] https://github.com/mhaeuser/ISPRASOpen-SecurePE

Thanks,
Evgeniy Baskov