Re: [PATCH v5 00/27] x86_64: Improvements at compressed kernel stage

[Gerd Hoffmann]

  Hi,

> And *this* seems to be the actual issue:
> 
> https://github.com/rhboot/shim/pull/459/commits/825d99361b4aaa16144392dc6cea43e24c8472ae
> 
> I assume that MS required this change as a condition for signing, but what do I know?

Your guess is correct.  UEFI world is moving to being stricter, for
example set page permissions according to the allocation type (RW for
data, RX for code).

Microsoft raised the bar for PE binaries when it comes to secure boot
signing as part of that effort.  Being a valid PE binary according to
the PE spec is not good enough, some additional constrains like sections
not overlapping and sections with different load flags not sharing pages
(so setting strict page permissions is actually possible) are required
now.  Stuff which is standard since years elsewhere.

>  Anyway, the rules appear to be that the PE sections must not be both W and X at the same size.

That too.

> But I still think we should keep the demand-faulting code as a
> fallback, even if it's hardcoded as RW, and just log the fault mode
> and address.  We certainly shouldn't be *executing* code that wasn't
> identity mapped.  Unless that code is boot services and we're creating
> the boot services mappings!

Agree.

> For that matter, how confident are we that there aren't crappy boot
> services implementations out there that require that we fix up page
> faults? After all, it's not like EFI implementations, especially early
> ones, are any good.

I don't expect much problems here.  Early EFI implementations don't
bother setting page permissions and just identity-map everything using
rwx huge pages, or run with paging turned off (hello ia32).

But playing safe (and keep demand-faulting just in case) is a good idea
nevertheless.

take care,
  Gerd