From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.12231.1683711677070190865 for ; Wed, 10 May 2023 02:41:17 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=VmMzM++U; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 887C56484F for ; Wed, 10 May 2023 09:41:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D626FC4339C for ; Wed, 10 May 2023 09:41:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683711675; bh=lvWwO1s94CplfcZcaBFaHUeB12BJFJOkLD+uafBmNzM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=VmMzM++U+zShjS08iV8GOUg1IuilWSsPFq7I+oBudxQWx0PkzLzpj6WmE/Rjqe92r AbCOwROPz1LllJCXb1Tfc6HBvtGUet1JzmZ7C61bh2iofb3tKC1oz7TmSN9QyfviHw qKzuwIxjFfAU7EAETq2h1LSaBKCrVjeUqIQlJ4qQGKHuBWS0sZW8dqLyaL+5a2AHta sN5W1BjaDagxhrYoYMtGd/Rq71CwbXn5WU6xhyZn/IZQY7oWXSVqkjaGjq058vIch2 61CudROKQXyA/HmIOs3vLxJoI5zaumclWAP6m/ClBOa461VtHDvLSE00PEYsXWsgHY OB+hQCZ83e7Cw== Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-4f25d79f6bfso1721882e87.2 for ; Wed, 10 May 2023 02:41:15 -0700 (PDT) X-Gm-Message-State: AC+VfDw2Bqo5rlbh8ehX48XCBauS8n0q/E+tUd6EexLLu4xTZWFlAbQK qUELgluKVx7M6P3kXGk95pqf8C/h1SF3bURK7o8= X-Google-Smtp-Source: ACHHUZ5AhOs1Bvp+ONelh67KpBnNtzGkk4PvNO9WrY+GHzpyZJCnnDxTdhx2Dzqsg79AaBJ3daR936sWhJYOJq4lMYg= X-Received: by 2002:a19:550d:0:b0:4ef:d742:4dfe with SMTP id n13-20020a19550d000000b004efd7424dfemr1599102lfe.65.1683711673883; Wed, 10 May 2023 02:41:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Wed, 10 May 2023 11:41:02 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Side effects of enabling PML5 in EFI To: Pedro Falcato Cc: edk2-devel-groups-io , Andrew Fish , "Kinney, Michael D" , Ray Ni Content-Type: text/plain; charset="UTF-8" On Tue, 9 May 2023 at 19:24, Pedro Falcato wrote: > > Hi all, > > (+CC people vaguely related to the EFI spec, the PML5 implementation > and kernel EFI boot code) > > As a result of the latest 5-level paging patches, I've been looking > into how tiano supports PML5. > This raised a question: Doesn't enabling PML5 in-firmware break > compatibility with non-PML5-aware bootloaders and kernels? > > From an architectural point of view: > - PML5 is enabled in CR4.LA57, but may only be toggled when not in > IA32e mode (so, only in 32-bit) > - Trying to mindlessly write to CR4 will #GP, and loading a 4-level > page tables will crash with probable page faults or #GPs > > From an EFI spec point of view: > - Whereas other architectures (arm64 for instance) specify the MMU > state in detail, the x64 bits do not specify anything beyond "Paging > enabled" (see 2.3.4). Which pre-PML5, was obviously well defined. We actually have a related problem on ARM: the size of the virtual address space is not mandated by the spec, but it does require that all memory is mapped 1:1. This means that, if a system has any memory that is outside of the 48-bit physical range, it must enable 5 level paging to map it 1:1 in the 52-bit virtual range. Given that EDK2's page allocator allocates from top down from the end of the address space, we might end up with allocations for ACPI tables etc that cannot be mapped by kernels that do not implement support for 5 level paging. I imagine a similar issue might exist on x86 as well, and this suggests that using 5 level paging in the firmware is only sensible if it is guaranteed that the OS and loader can deal with it (IOW, running the firmware with 5 level pages and switching back to 4 in ExitBootServices() may result in other issues) > - When under boot services, this is likely not a problem as page > tables are owned by boot services. Unless they touch them as defined > in "2.3.4.3. Enabling Paging or Alternate Translations in an > Application", which may run into problems. > > From an OS kernel/bootloader point of view: > - A PML5 aware kernel/bootloader will likely correctly identify the > PML5 capability and enable LA57, load 5-level page tables. As such, > this scenario always works. > - A non-PML5-aware one may incorrectly overwrite LA57 (and #GP), or > just load a 4-level paging structure into CR3, and thus disastrously > crash. > > So, how is any of this supposed to work? > I don't think the firmware should ever use 5 level paging unless it is strictly needed for a particular use case. And even then, it should avoid allocating memory from the region that is only 1:1 accessible when 5 level paging is enabled.