All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Evgeniy Baskov <baskov@ispras.ru>,
	Ard Biesheuvel <ardb@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Alexey Khoroshilov <khoroshilov@ispras.ru>,
	Peter Jones <pjones@redhat.com>,
	"Limonciello, Mario" <mario.limonciello@amd.com>,
	joeyli <jlee@suse.com>,
	lvc-project@linuxtesting.org,
	the arch/x86 maintainers <x86@kernel.org>,
	linux-efi@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH v5 00/27] x86_64: Improvements at compressed kernel stage
Date: Wed, 15 Mar 2023 10:04:57 +0100	[thread overview]
Message-ID: <20230315090457.6spo4f4v2l4qwdu2@sirius.home.kraxel.org> (raw)
In-Reply-To: <ea1b6e36-c434-49e9-bede-b4bd2b41868d@app.fastmail.com>

  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


  reply	other threads:[~2023-03-15  9:07 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-14 10:13 [PATCH v5 00/27] x86_64: Improvements at compressed kernel stage Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 01/27] x86/boot: Align vmlinuz sections on page size Evgeniy Baskov
2023-04-05 17:13   ` Borislav Petkov
2023-04-08 15:03     ` Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 02/27] x86/build: Remove RWX sections and align on 4KB Evgeniy Baskov
2023-04-05 17:40   ` Borislav Petkov
2023-04-06 11:42     ` Gerd Hoffmann
2023-04-08 15:05     ` Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 03/27] x86/boot: Set cr0 to known state in trampoline Evgeniy Baskov
2023-04-05 17:54   ` Borislav Petkov
2023-04-08 15:09     ` Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 04/27] x86/boot: Increase boot page table size Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 05/27] x86/boot: Support 4KB pages for identity mapping Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 06/27] x86/boot: Setup memory protection for bzImage code Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 07/27] x86/build: Check W^X of vmlinux during build Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 08/27] x86/boot: Map memory explicitly Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 09/27] x86/boot: Remove mapping from page fault handler Evgeniy Baskov
2023-03-14 20:33   ` Andy Lutomirski
2023-03-15 13:25     ` Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 10/27] efi/libstub: Move helper function to related file Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 11/27] x86/boot: Make console interface more abstract Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 12/27] x86/boot: Make kernel_add_identity_map() a pointer Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 13/27] x86/boot: Split trampoline and pt init code Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 14/27] x86/boot: Add EFI kernel extraction interface Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 15/27] efi/x86: Support extracting kernel from libstub Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 16/27] x86/boot: Reduce lower limit of physical KASLR Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 17/27] x86: decompressor: Remove the 'bugger off' message Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 18/27] tools/include: Add simplified version of pe.h Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 19/27] x86/build: Cleanup tools/build.c Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 20/27] efi: x86: Use private copy of struct setup_header Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 21/27] x86/build: Add SETUP_HEADER_OFFSET constant Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 22/27] x86/build: set type_of_loader for EFISTUB Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 23/27] efi/libstub: Don't set ramdisk_image/ramdisk_size Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 24/27] x86/build: Make generated PE more spec compliant Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 25/27] efi/libstub: Use memory attribute protocol Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 26/27] efi/libstub: make memory protection warnings include newlines Evgeniy Baskov
2023-03-14 10:13 ` [PATCH v5 27/27] efi/x86: don't try to set page attributes on 0-sized regions Evgeniy Baskov
2023-03-14 21:23 ` [PATCH v5 00/27] x86_64: Improvements at compressed kernel stage Andy Lutomirski
2023-03-14 23:20   ` Andy Lutomirski
2023-03-15  9:04     ` Gerd Hoffmann [this message]
2023-03-15 17:57     ` Peter Jones
2023-04-05 16:17       ` Borislav Petkov
2023-03-15 13:25   ` Evgeniy Baskov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230315090457.6spo4f4v2l4qwdu2@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=ardb@kernel.org \
    --cc=baskov@ispras.ru \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=jlee@suse.com \
    --cc=khoroshilov@ispras.ru \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=lvc-project@linuxtesting.org \
    --cc=mario.limonciello@amd.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pjones@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.