This patch adds some missing definitions for PE header flags.  We don't
use all of them, but it's less confusing with the list matching the
spec, except where the spec is obviously wrong.

Signed-off-by: Peter Jones <pjones@redhat.com>

This adds support in our PE loader for NX support utilizing the
EFI_MEMORY_ATTRIBUTE protocol.  Specifically, it changes the loader such
that:

- binaries without the EFI_IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag set
  in the Optional Header are rejected as EFI_UNSUPPORTED
- binaries with non-discardable sections that have both the
  EFI_SCN_MEM_WRITE and EFI_SCN_MEM_EXECUTE flags set are rejected as
  EFI_UNSUPPORTED
- if the EFI_MEMORY_ATTRIBUTE protocol is installed, then:
  - sections without the EFI_SCN_MEM_READ flag set will be marked with
    EFI_MEMORY_RP
  - sections without the EFI_SCN_MEM_WRITE flag set will be marked with
    EFI_MEMORY_RO
  - sections without the EFI_SCN_MEM_EXECUTE flag set will be marked
    with EFI_MEMORY_XP

Signed-off-by: Peter Jones <pjones@redhat.com>

This adds a new MoK variable, MokPolicy (&MokPolicyRT) that's intended
as a bitmask of machine owner policy choices, and the bit
MOK_POLICY_REQUIRE_NX.  This bit specifies whether it is permissible to
load binaries which do not support NX mitigations, and it currently
defaults to allowing such binaries to be loaded.

The broader intention here is to migrate all of the MoK policy variables
that are really just on/off flags to this variable.

Signed-off-by: Peter Jones <pjones@redhat.com>

Currently, system firmware has no means to discover that an EFI
Application is compatible with the security feature variously known as
NX or w^x.

Since at least Revision 8.1, the PE spec supports setting a flag the
Optional Header's DllCharacteristics field to inform loaders that an
application supports being loaded with NX enabled.

In the case of UEFI, there are several things that should be enabled if
this flag is set:

- EFI_BOOT_SERVICES.AllocatePages() with MemoryType = EfiLoaderCode,
  EfiBootServicesCode, EfiRuntimeServicesCode, etc, currently must set
  memory as rwx.  This flag set implies that rw- is appropriate, and
  that the application knows how to use the EFI_MEMORY_ATTRIBUTE
  protocol to change that to r-x.
- EFI_BOOT_SERVICES.AllocatePool() - same as AllocatePages()
- EFI_BOOT_SERVICES.LoadImage()
  - currently must set the stack as rwx. This flag states that it is
    allowed to be rw-
  - currently a binary can probably have writable PLTs?  This flag
    allows the loader to not set them writable
- I have heard that some firmwares have the 0 page mapped rwx.
  Obviously this should not be done.

Signed-off-by: Peter Jones <pjones@redhat.com>