Re: [edk2-devel] [PATCH v3 00/20] NetworkPkg: CVE-2023-45236 and CVE-2023-45237

[Ard Biesheuvel]

On Fri, 24 May 2024 at 11:12, gaoliming via groups.io
 wrote:
>
> Ard:
>   Here is Doug PR https://github.com/tianocore/edk2/pull/5582 that includes 
> 20 commits. You can check them.
>

This looks fine to me in principle.

Reviewed-by: Ard Biesheuvel 

However, IIUC, the impact of this series is that all out-of-tree
platforms that lack the right implementation of the EFI_RNG_PROTOCOL
(i.e., using a GUID that appears in the allowlist) will lose the
ability to do network boot. If that is a tolerable result, I am fine
with that too, but I think it needs to be made very clear in the
stable tag release notes.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119253): https://edk2.groups.io/g/devel/message/119253
Mute This Topic: https://groups.io/mt/106278600/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 00/20] NetworkPkg: CVE-2023-45236 and CVE-2023-45237

[Ard Biesheuvel]

On Fri, 24 May 2024 at 09:01, gaoliming via groups.io
 wrote:
>
> Ard and Gerd:
>   Doug updated this patch set based on your suggestion. Could you give
> reviewed-by or acked-by for the changes in OvmfPkg and ArmVirtPkg if you
> have no other comments?
>

I see ~60 patches from Doug, seemingly 3 copies of the v3 series. I am
going to assume they are identical.

The changes I contributed should appear at the beginning of the
series, not the end, so that bisect does not get broken.

Perhaps Doug could send a v4 (only once!) that has everything in the
correct order, and I will look at it.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119249): https://edk2.groups.io/g/devel/message/119249
Mute This Topic: https://groups.io/mt/106277453/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 02/18] OvmfPkg: Save MTRR by lockbox in CpuS3DataDxe

[Ard Biesheuvel]

On Fri, 10 May 2024 at 12:08, Dun Tan  wrote:
>
> Save MTRR by lockbox in CpuS3DataDxe. In S3 boot,
> The MTRR setting will be restored in S3Resume.c
> in following patches. Then S3Resume.c will wakeup
> all APs to load the MTRR setting. This can avoid
> waking up APs in CpuS3.c.
>
> Signed-off-by: Dun Tan 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Gerd Hoffmann 
> Cc: Ray Ni 
> Cc: Jiaxin Wu 

Reviewed-by: Ard Biesheuvel 


> ---
>  OvmfPkg/CpuS3DataDxe/CpuS3Data.c  | 11 +++
>  OvmfPkg/CpuS3DataDxe/CpuS3DataDxe.inf |  2 ++
>  2 files changed, 13 insertions(+)
>
> diff --git a/OvmfPkg/CpuS3DataDxe/CpuS3Data.c 
> b/OvmfPkg/CpuS3DataDxe/CpuS3Data.c
> index 289048b75d..d1aba32842 100644
> --- a/OvmfPkg/CpuS3DataDxe/CpuS3Data.c
> +++ b/OvmfPkg/CpuS3DataDxe/CpuS3Data.c
> @@ -26,6 +26,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -130,6 +131,16 @@ CpuS3DataOnEndOfDxe (
>DEBUG ((DEBUG_VERBOSE, "%a\n", __func__));
>MtrrGetAllMtrrs (>MtrrTable);
>
> +  //
> +  // Save MTRR in lockbox
> +  //
> +  Status = SaveLockBox (
> + ,
> + >MtrrTable,
> + sizeof (MTRR_SETTINGS)
> + );
> +  ASSERT_EFI_ERROR (Status);
> +
>//
>// Close event, so it will not be invoked again.
>//
> diff --git a/OvmfPkg/CpuS3DataDxe/CpuS3DataDxe.inf 
> b/OvmfPkg/CpuS3DataDxe/CpuS3DataDxe.inf
> index 228d5ae1b2..f5032a9222 100644
> --- a/OvmfPkg/CpuS3DataDxe/CpuS3DataDxe.inf
> +++ b/OvmfPkg/CpuS3DataDxe/CpuS3DataDxe.inf
> @@ -46,9 +46,11 @@
>MtrrLib
>UefiBootServicesTableLib
>UefiDriverEntryPoint
> +  LockBoxLib
>
>  [Guids]
>gEfiEndOfDxeEventGroupGuid ## CONSUMES   ## Event
> +  gEdkiiS3MtrrSettingGuid
>
>  [Protocols]
>gEfiMpServiceProtocolGuid  ## CONSUMES
> --
> 2.31.1.windows.1
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119077): https://edk2.groups.io/g/devel/message/119077
Mute This Topic: https://groups.io/mt/106018122/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] 回复: [edk2-devel] [PATCH v2 03/13] OvmfPkg:PlatformCI: Support virtio-rng-pci

[Ard Biesheuvel]

On Fri, 17 May 2024 at 05:27, Doug Flick via groups.io
 wrote:
>
> On ARM, we can actually do better than this: I have taken Doug's v2 and 
> applied some changes on top to make it work with ArmVirtQemu.
>
> https://github.com/ardbiesheuvel/edk2/tree/doug-v2
>
> Ard, would you be comfortable with this patch series if I take the commits 
> you're suggesting? I'm being asked to see what it would take to get these 
> commits in for this release.

I won't object to that, but I'd like Gerd's take as well, given that a
similar concern appears to apply to OVMF/x86 IIUC.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118991): https://edk2.groups.io/g/devel/message/118991
Mute This Topic: https://groups.io/mt/106013302/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 0/2] Add a new FdtNorFalshQemuLib and enable it in

[Ard Biesheuvel]

Hello Chao Li,

You sent two series in quick succession. Is there any difference
between the two?


On Fri, 17 May 2024 at 09:17, Chao Li  wrote:
>
> Patch1: Added a new library called FdtNorFlashQemuLib in OvmfPkg/Library
> which is non-hardcode dependency.
> Patch2: Enable the new library in ArmVirtQemu.dsc and
> ArmVirtQemuKernel.dsc.
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4770
>
> I have verified on both of the two platforms:
> Prepare:
> install libvirt, virt-manager, qemu-systemaarch64.
>
> Step 1:
> Built the two platforms with ArmVirtQemu.dsc and
> ArmVirtQemuKernel.dsc, and then using the command create the pflash
> files:
> Build the two platforms firmware using ArmVirtQemu.dsc and
> ArmVirtQemuKernel.dsc, and then create the pflash files using following
> command:
> cat QEMU_EFI.fd  /dev/zero | head -c 64m > ./QEMU_EFI-pflash.raw
> cat QEMU_VARS.fd  /dev/zero | head -c 64m > ./vars-template-pflash.raw
> qemu-img convert -f raw -O qcow2 -o cluster_size=4096 -S 4096 
> QEMU_EFI-pflash.raw  QEMU_EFI-pflash.qcow2
> qemu-img convert -f raw -O qcow2 -o cluster_size=4096 -S 4096 
> vars-template-pflash.raw vars-template-pflash.qcow2
>
> Download a AARCH64 QCOW2 image.
> Copy them into /usr/share/edk2/aarch64/.
>
> Step 2:
> Verification the pflash working:
> ArmVirtQemu:
> Run the QEMU ARM virt machine using the following command:
> qemu-system-aarch64 \
> -blockdev 
> '{"driver":"file","filename":"/usr/share/edk2/aarch64/QEMU_EFI-pflash.qcow2","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}'
>  \
> -blockdev 
> '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"qcow2","file":"libvirt-pflash0-storage"}'
>  \
> -blockdev 
> '{"driver":"file","filename":"/usr/share/edk2/aarch64/vars-template-pflash.qcow2","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}'
>  \
> -blockdev 
> '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"qcow2","file":"libvirt-pflash1-storage"}'
>  \
> -machine 
> virt,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format,acpi=on \
> -cpu cortex-a57 \
> -m size=2097152k \
> -serial stdio \
> -net none \
> -device ramfb \
> -device nec-usb-xhci \
> -device usb-mouse \
> -device usb-kbd
>
> ArmVirtQemuKernel:
> Run the QEMU kernel ARM virt machine using the following command:
> qemu-system-aarch64 \
> -blockdev 
> '{"driver":"file","filename":"/usr/share/edk2/aarch64/vars-template-pflash.raw","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}'
>  \
> -blockdev 
> '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}'
>  \
> -machine 
> virt,usb=off,dump-guest-core=off,gic-version=3,pflash1=libvirt-pflash1-format 
> \
> -cpu cortex-a57 \
> -m 4096 \
> -smp 1,sockets=1,cores=1,threads=1 \
> -no-user-config \
> -nodefaults \
> -device virtio-gpu-pci \
> -kernel /usr/share/edk2/aarch64/QEMU_EFI-pflash.raw \
> -serial stdio \
>     -device nec-usb-xhci \
> -device usb-mouse \
> -device usb-kbd  \
> -hda /usr/share/edk2/aarch64/openEuler-22.03-LTS-SP3-aarch64.qcow2 \
> -monitor tcp::,server,nowait
>
> Step 3:
> After the virt-machines starts, enter "F2" to enter the setup UI, try to
> change the boot order or some ther variables stored in the flash, then
> enter "F10" to save the changes and reboot it.
> After restarting, enter "F2" to enter the setup UI and check whether the
> changes before the restart operation have been saved.
>
>
> Using the above three steps, both platforms will works fine.
>
> I have not created the PR in github yet, I will create it once the edk2
> merge window reopens.
>
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Cc: Sami Mujawar 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
>
> Chao Li (2):
>   OvmfPkg: Add no hardcode version of FtdNorFlashQemuLib
>   ArmVirtPkg: Enable the non-hardcode version FtdNorFlashQemuLib
>
>  ArmVirtPkg/ArmVirtQemu.dsc|  21 ++-
>  ArmVirtPkg/ArmVirtQemuKernel.dsc  |  20 ++-
>  ArmVirtPkg/VarStore.fdf.inc   |   5 +-
>  .../FdtNorFlashQemuLib/FdtNorFlashQemuLib.c   | 165 ++
>  .../FdtNorFlashQemuLib/FdtNorFlashQemuLib.inf |  46 +
>  5 files changed, 249 insertions(+), 8 deletions(-)
>  create mode 100644 OvmfPkg/Library/FdtNorFlashQemuLib/FdtNorFlashQemuLib.c
>  create mode 100644 OvmfPkg/Library/FdtNorFlashQemuLib/FdtNorFlashQemuLib.inf
>
> --
> 2.27.0
>
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118990): https://edk2.groups.io/g/devel/message/118990
Mute This Topic: https://groups.io/mt/106149594/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] 回复: [edk2-devel] [PATCH v2 03/13] OvmfPkg:PlatformCI: Support virtio-rng-pci

[Ard Biesheuvel]

(cc some ARM folks)

On Mon, 13 May 2024 at 11:23, Gerd Hoffmann  wrote:
>
> On Sat, May 11, 2024 at 10:40:23AM GMT, Ard Biesheuvel wrote:
> > As I pointed out before, on the ARM side there are a few intersecting
> > issues with these changes. (On x86, this is mostly avoided due to the
> > fact that RDRAND is universally supported)
>
> Well, it's not that easy on x86 either.
>
> Current state of affairs is that the time based LibRng is used, all
> OvmfPkg / ArmVirtPkg have this:
>
>   RngLib|MdeModulePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf
>
> So, this is what will be used if something uses LibRng.
>
> On x64 RngDxe will just use call LibRng too.  So adding RngDxe will
> effectively make BaseRngLibTimerLib available via EFI_RNG_PROTOCOL.
>
> In case '-device virtio-rng-pci' is present we now have *two* drivers
> providing EFI_RNG_PROTOCOL.  What will happen in this case?  What we
> surely not want is RngDxe being used in case we have a virtio-rng
> device ...
>

On ARM, we can actually do better than this: I have taken Doug's v2
and applied some changes on top to make it work with ArmVirtQemu.

https://github.com/ardbiesheuvel/edk2/tree/doug-v2

The ARM version of RngLib can be backed by either RNDR or TRNG, and
exposes gEfiRngAlgorithmArmRndr, gEfiRngAlgorithmRaw, or both. If
neither are supported, RngDxe will not be dispatched.

Given that RNDR is implemented by the hardware, and TRNG by the
hypervisor, and neither depend on the UEFI driver model (like
virtio-rng), which is backed by the VMM, I think that in this case,
there is no issue with dispatching both, even if that results in two
implementations of the EFI_RNG_PROTOCOL, and no guarantees regarding
which one you get when you locate the protocol. (Confidential VMs may
want to avoid virtio-rng as it is provided by the host but let's
disregard that for the time being)

The upshot is that existing ARM deployments that do not use the 'max'
CPU in TCG mode, or are on a fairly old version of KVM will lose
network support unless they enable the virtio-rng-pci device. This is
a situation I can live with, but it does require the changes I am
proposing on the branch above.

On x86, we should avoid BaseRngLibTimerLib as well - it is a bit ugly
to expose two EFI_RNG_PROTOCOL instances, but we could at least ensure
that it doesn't matter which one you grab. I intend to look more
deeply into this in the future, and maybe compare notes with Pierre,
as this has been a rather complicated delivery IIRC. Perhaps it would
be better for RngDxe to consume a raw entropy source and implement the
DRBG directly rather than expose the raw protocol (which I think
should not have been introduced in the first place)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118872): https://edk2.groups.io/g/devel/message/118872
Mute This Topic: https://groups.io/mt/106013302/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 08/13] NetworkPkg:: SECURITY PATCH CVE-2023-45237

[Ard Biesheuvel]

Could we please include

gEfiRngAlgorithmArmRndr

in the list of accepted RNG protocols?

The ARM architecture reference mandates the use of a DRBG that
complies with NIST SP800-90A Rev 1 to produce the random output
emitted by RNDR/RNDRRS, and so it matches the requirement imposed by
this change.



On Thu, 9 May 2024 at 07:57, Doug Flick via groups.io
 wrote:
>
> From: Doug Flick 
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4542
>
> Bug Overview:
> PixieFail Bug #9
> CVE-2023-45237
> CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
> CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
>
> Use of a Weak PseudoRandom Number Generator
>
> Change Overview:
>
> Updates all Instances of NET_RANDOM (NetRandomInitSeed ()) to either
>
> >
> > EFI_STATUS
> > EFIAPI
> > PseudoRandomU32 (
> >  OUT UINT32  *Output
> >  );
> >
>
> or (depending on the use case)
>
> >
> > EFI_STATUS
> > EFIAPI
> > PseudoRandom (
> >  OUT  VOID   *Output,
> >  IN   UINTN  OutputLength
> >  );
> >
>
> This is because the use of
>
> Example:
>
> The following code snippet PseudoRandomU32 () function is used:
>
> >
> > UINT32 Random;
> >
> > Status = PseudoRandomU32 ();
> > if (EFI_ERROR (Status)) {
> >   DEBUG ((DEBUG_ERROR, "%a failed to generate random number: %r\n",
> __func__, Status));
> >   return Status;
> > }
> >
>
> This also introduces a new PCD to enable/disable the use of the
> secure implementation of algorithms for PseudoRandom () and
> instead depend on the default implementation. This may be required for
> some platforms where the UEFI Spec defined algorithms are not available.
>
> >
> > PcdEnforceSecureRngAlgorithms
> >
>
> If the platform does not have any one of the UEFI defined
> secure RNG algorithms then the driver will assert.
>
> Cc: Saloni Kasbekar 
> Cc: Zachary Clark-williams 
>
> Signed-off-by: Doug Flick [MSFT] 
> ---
>  NetworkPkg/NetworkPkg.dec  |   7 ++
>  NetworkPkg/Library/DxeNetLib/DxeNetLib.inf |  13 +-
>  NetworkPkg/TcpDxe/TcpDxe.inf   |   3 +
>  NetworkPkg/IScsiDxe/IScsiMisc.h|   6 +-
>  NetworkPkg/Include/Library/NetLib.h|  40 --
>  NetworkPkg/Ip6Dxe/Ip6Nd.h  |   8 +-
>  NetworkPkg/Dhcp4Dxe/Dhcp4Driver.c  |  10 +-
>  NetworkPkg/Dhcp6Dxe/Dhcp6Driver.c  |  11 +-
>  NetworkPkg/DnsDxe/DnsDhcp.c|  10 +-
>  NetworkPkg/DnsDxe/DnsImpl.c|  11 +-
>  NetworkPkg/HttpBootDxe/HttpBootDhcp6.c |  10 +-
>  NetworkPkg/IScsiDxe/IScsiCHAP.c|  19 ++-
>  NetworkPkg/IScsiDxe/IScsiMisc.c|  14 +--
>  NetworkPkg/Ip4Dxe/Ip4Driver.c  |  10 +-
>  NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c  |   9 +-
>  NetworkPkg/Ip6Dxe/Ip6Driver.c  |  17 ++-
>  NetworkPkg/Ip6Dxe/Ip6If.c  |  12 +-
>  NetworkPkg/Ip6Dxe/Ip6Mld.c |  12 +-
>  NetworkPkg/Ip6Dxe/Ip6Nd.c  |  33 -
>  NetworkPkg/Library/DxeNetLib/DxeNetLib.c   | 129 +---
>  NetworkPkg/TcpDxe/TcpDriver.c  |  15 ++-
>  NetworkPkg/Udp4Dxe/Udp4Driver.c|  10 +-
>  NetworkPkg/Udp6Dxe/Udp6Driver.c|  11 +-
>  NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c   |   9 +-
>  NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c   |  11 +-
>  NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c  |  12 +-
>  NetworkPkg/SecurityFixes.yaml  |  39 ++
>  27 files changed, 408 insertions(+), 83 deletions(-)
>
> diff --git a/NetworkPkg/NetworkPkg.dec b/NetworkPkg/NetworkPkg.dec
> index e06f35e7747c..7c4289b77b21 100644
> --- a/NetworkPkg/NetworkPkg.dec
> +++ b/NetworkPkg/NetworkPkg.dec
> @@ -5,6 +5,7 @@
>  #
>  # Copyright (c) 2009 - 2021, Intel Corporation. All rights reserved.
>  # (C) Copyright 2015-2020 Hewlett Packard Enterprise Development LP
> +# Copyright (c) Microsoft Corporation
>  #
>  # SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -130,6 +131,12 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
># @Prompt Indicates whether SnpDxe creates event for ExitBootServices() 
> call.
>
> gEfiNetworkPkgTokenSpaceGuid.PcdSnpCreateExitBootServicesEvent|TRUE|BOOLEAN|0x100C
>
> +  ## Enforces the use of Secure UEFI spec defined RNG algorithms for all 
> network connections.
> +  # TRUE  - Enforce the use of Secure UEFI spec defined RNG algorithms.
> +  # FALSE - Do not enforce and depend on the default implementation of RNG 
> algorithm from the provider.
> +  # @Prompt Enforce the use of Secure UEFI spec defined RNG algorithms.
> +  
> gEfiNetworkPkgTokenSpaceGuid.PcdEnforceSecureRngAlgorithms|TRUE|BOOLEAN|0x100D
> +
>  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
>## IPv6 DHCP Unique Identifier (DUID) Type configuration (From RFCs 3315 
> and 6355).
># 01 = DUID Based on Link-layer Address Plus Time [DUID-LLT]
> diff --git a/NetworkPkg/Library/DxeNetLib/DxeNetLib.inf 
> b/NetworkPkg/Library/DxeNetLib/DxeNetLib.inf
> index 8145d256ec10..236ccd362efe 100644
> --- 

Re: [edk2-devel] 回复: [edk2-devel] [PATCH v2 03/13] OvmfPkg:PlatformCI: Support virtio-rng-pci

[Ard Biesheuvel]

As I pointed out before, on the ARM side there are a few intersecting
issues with these changes. (On x86, this is mostly avoided due to the
fact that RDRAND is universally supported)

- the RNDR instructions are not widely available yet, and support has
not yet been added to ArmVirtQemu IIRC
- the hypervisor TRNG service is only available when executing QEMU
under KVM (true virtualization), or when running a firmware stack
inside QEMU that implements it - QEMU itself does not expose this to
guests when QEMU is acting as the hypervisor (TCG)
- the virtio-rng device needs to be activated explicitly on the command line

On the one hand, this means there are various ways to get entropy on
/most/ systems, but it also means that the default use case of running
QEMU on a non-ARM host (implying lack of KVM) without virtio-rng-pci
will not have any EFI_RNG_PROTOCOL available. We might change this
with RNDR but this will still leave some use cases behind (where a
specific CPU is selected rather than 'max')

If the result of this series is that systems with a EFI_RNG_PROTOCOL
implementation cannot boot at all, this is a problem. If it means they
cannot boot from the network, I'd be less worried. And while adding
-device virtio-rng-pci to the CI command lines was long overdue, doing
so doesn't fix other deployments of QEMU with the bundled firmware, so
something has to be done.

So we can at least clarify what the consequences are of attempting to
run OVMF/ArmVirtQemu on a system that does not implement
EFI_RNG_PROTOCOL at all? And then, make an informed decision on how to
mitigate any resulting breakage?




On Fri, 10 May 2024 at 19:13, Doug Flick via groups.io
 wrote:
>
> At a high level, this isn't my project and I would look towards the 
> maintainers to provide guidance about the direction they want to go.
>
> However,
>
> In my opinion, this is a debate on Security vs Compatibility. I'm biased more 
> towards security, and I've tried to make it easy for a platform to understand 
> what is happening with PcdEnforceSecureRngAlgorithms . If we default to 
> default the platform never has the chance to understand what Rng Algorithms 
> they provide and if that is a problem for them. Default is obviously the most 
> compatible but it's also the one that may or may not be backed by something 
> insecure. Which is why I would prefer if a platform acknowledges that they 
> know it's backed by something secure or if not its an active decision.
>
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118831): https://edk2.groups.io/g/devel/message/118831
Mute This Topic: https://groups.io/mt/106013302/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 07/13] SecurityPkg: RngDxe: Remove incorrect limitation on GetRng

[Ard Biesheuvel]

On Thu, 9 May 2024 at 07:56, Doug Flick via groups.io
 wrote:
>
> Removed from gEfiRngAlgorithmRaw an incorrect assumption that
> Raw cannot return less than 256 bits. The DRNG Algorithms
> should always use a 256 bit seed as per nist standards
> however a caller is free to request less than 256 bits.
> >
> > //
> >// When a DRBG is used on the output of a entropy source,
> >// its security level must be at least 256 bits according to UEFI Spec.
> >//
> >if (RNGValueLength < 32) {
> >  return EFI_INVALID_PARAMETER;
> >}
> >
>
> AARCH64 platforms do not have this limitation and this brings both
> implementations into alignment with each other and the spec.
>
> Cc: Jiewen Yao 
>
> Signed-off-by: Doug Flick [MSFT] 

Reviewed-by: Ard Biesheuvel 

As I commented in the other thread, it is not the job of the raw
EFI_RNG_PROTOCOL to ensure that its callers never do anything silly.
Refusing requests for less than 32 bytes is pointless and arbitrary,
as only avoids one very particular potential mistake.


> ---
>  SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c | 8 
>  1 file changed, 8 deletions(-)
>
> diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c 
> b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
> index 7e06e16e4be5..5723ed695747 100644
> --- a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
> +++ b/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c
> @@ -116,14 +116,6 @@ RngGetRNG (
>// The "raw" algorithm is intended to provide entropy directly
>//
>if (CompareGuid (RNGAlgorithm, )) {
> -//
> -// When a DRBG is used on the output of a entropy source,
> -// its security level must be at least 256 bits according to UEFI Spec.
> -//
> -if (RNGValueLength < 32) {
> -  return EFI_INVALID_PARAMETER;
> -}
> -
>  Status = GenerateEntropy (RNGValueLength, RNGValue);
>  return Status;
>}
> --
> 2.34.1
>
>
>
> 
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#118722): https://edk2.groups.io/g/devel/message/118722
> Mute This Topic: https://groups.io/mt/105996584/1131722
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [a...@kernel.org]
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118830): https://edk2.groups.io/g/devel/message/118830
Mute This Topic: https://groups.io/mt/105996584/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 03/13] OvmfPkg:PlatformCI: Support virtio-rng-pci

[Ard Biesheuvel]

Apologies, I meant this as a reply to the ArmVirtPkg change, not the OVMF one.

On Thu, 9 May 2024 at 10:45, Ard Biesheuvel  wrote:
>
> So this patch is necessary as otherwise, QEMU fails to boot due to a
> missing source of randomness in the network drivers, right?
>
> Does this imply that all QEMU deployments that rely on the bundled
> firmware images (e.g., for micro-VMs and container use cases) will now
> fail to boot if the pre-existing QEMU launch script happens to omit
> the virtio-rng device?
>
> If so, we absolutely need a fallback here - RngDxe based on TRNG (for
> KVM use cases) as well as RNDR (for TCG with CPU max). This may still
> break some deployments, but the vast majority should be covered.
>
> RNDR raises another interesting problem, by the way - the ARM arch
> spec requires RNDR to be backed by an appropriate DRBG that complies
> with the NIST spec but it does not specify which one. IOW, it is
> backed by a DRBG not by a raw entropy source, but specifying which
> DRBG (by GUID) is not generally feasible, as the guest VM firmware
> cannot interrogate the host about which DRBG is behind RNDR.
>
> TL;DR there are a couple of loose ends here, and so rushing it through
> doesn't seem wise imho. I'd rather leave ARM behind with these CVE
> fixes than break many different use cases in different ways.
>
>
>
> On Thu, 9 May 2024 at 07:56, Doug Flick  wrote:
> >
> > This patch adds "virtio-rng-pci" to the PlatformBuildLib.py
> > This adds Rng services to the guest VM
> >
> > Cc: Ard Biesheuvel 
> > Cc: Jiewen Yao 
> > Cc: Gerd Hoffmann 
> >
> > Signed-off-by: Doug Flick [MSFT] 
> > ---
> >  OvmfPkg/PlatformCI/PlatformBuildLib.py | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py 
> > b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> > index 00d454954bff..3fe80f5c1caa 100644
> > --- a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> > +++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> > @@ -208,6 +208,8 @@ class PlatformBuilder( UefiBuilder, 
> > BuildSettingsManager):
> >  args += " -net none"   
> >  # turn off network
> >  args += " -smp 4"
> >  args += f" -drive 
> > file=fat:rw:{VirtualDrive},format=raw,media=disk" # Mount disk with 
> > startup.nsh
> > +# Provides Rng services to the Guest VM
> > +args += " -device virtio-rng-pci"
> >
> >  if (self.env.GetValue("QEMU_HEADLESS").upper() == "TRUE"):
> >  args += " -display none"  # no graphics
> > --
> > 2.34.1
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118754): https://edk2.groups.io/g/devel/message/118754
Mute This Topic: https://groups.io/mt/105996580/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 03/13] OvmfPkg:PlatformCI: Support virtio-rng-pci

[Ard Biesheuvel]

So this patch is necessary as otherwise, QEMU fails to boot due to a
missing source of randomness in the network drivers, right?

Does this imply that all QEMU deployments that rely on the bundled
firmware images (e.g., for micro-VMs and container use cases) will now
fail to boot if the pre-existing QEMU launch script happens to omit
the virtio-rng device?

If so, we absolutely need a fallback here - RngDxe based on TRNG (for
KVM use cases) as well as RNDR (for TCG with CPU max). This may still
break some deployments, but the vast majority should be covered.

RNDR raises another interesting problem, by the way - the ARM arch
spec requires RNDR to be backed by an appropriate DRBG that complies
with the NIST spec but it does not specify which one. IOW, it is
backed by a DRBG not by a raw entropy source, but specifying which
DRBG (by GUID) is not generally feasible, as the guest VM firmware
cannot interrogate the host about which DRBG is behind RNDR.

TL;DR there are a couple of loose ends here, and so rushing it through
doesn't seem wise imho. I'd rather leave ARM behind with these CVE
fixes than break many different use cases in different ways.



On Thu, 9 May 2024 at 07:56, Doug Flick  wrote:
>
> This patch adds "virtio-rng-pci" to the PlatformBuildLib.py
> This adds Rng services to the guest VM
>
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Gerd Hoffmann 
>
> Signed-off-by: Doug Flick [MSFT] 
> ---
>  OvmfPkg/PlatformCI/PlatformBuildLib.py | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py 
> b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> index 00d454954bff..3fe80f5c1caa 100644
> --- a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> +++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> @@ -208,6 +208,8 @@ class PlatformBuilder( UefiBuilder, BuildSettingsManager):
>  args += " -net none"
> # turn off network
>  args += " -smp 4"
>  args += f" -drive file=fat:rw:{VirtualDrive},format=raw,media=disk" 
> # Mount disk with startup.nsh
> +# Provides Rng services to the Guest VM
> +args += " -device virtio-rng-pci"
>
>  if (self.env.GetValue("QEMU_HEADLESS").upper() == "TRUE"):
>  args += " -display none"  # no graphics
> --
> 2.34.1
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118753): https://edk2.groups.io/g/devel/message/118753
Mute This Topic: https://groups.io/mt/105996580/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 00/14] Add SmmRelocationLib

[Ard Biesheuvel]

Thanks Liming.

On Thu, 9 May 2024 at 09:36, gaoliming via groups.io
 wrote:
>
> Ard:
>   Gerd is the reviewer of OvmfPkg. He gave Acked-by before soft feature 
> freeze. So, this patch set can be merged for this stable tag 202405.
>
>   And, this patch set has been merged.
>
> Thanks
> Liming
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Ard Biesheuvel
> > 发送时间: 2024年5月9日 0:44
> > 收件人: Wu, Jiaxin ; Liming Gao (Byosoft address)
> > 
> > 抄送: Yao, Jiewen ; Ni, Ray ;
> > devel@edk2.groups.io; Zeng, Star ; Gerd Hoffmann
> > ; Kumar, Rahul R ; Dong, Guo
> > ; Rhodes, Sean ; Lu, James
> > ; Guo, Gua ; Abdul Lateef Attar
> > ; Abner Chang ; Tom
> > Lendacky 
> > 主题: Re: [edk2-devel] [PATCH v4 00/14] Add SmmRelocationLib
> >
> > Happy to merge this.
> >
> > Liming, please let me know if this meets the soft freeze requirements?
> >
> > Thanks,
> >
> >
> > On Tue, 7 May 2024 at 07:18, Wu, Jiaxin  wrote:
> > >
> > > Thanks Jiewen.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > From: Yao, Jiewen 
> > > Sent: Tuesday, May 7, 2024 12:59 PM
> > > To: Wu, Jiaxin ; Ni, Ray ;
> > devel@edk2.groups.io; Ard Biesheuvel 
> > > Cc: Zeng, Star ; Gerd Hoffmann ;
> > Kumar, Rahul R ; Dong, Guo ;
> > Rhodes, Sean ; Lu, James ; Guo,
> > Gua ; Abdul Lateef Attar ;
> > Abner Chang ; Tom Lendacky
> > 
> > > Subject: RE: [PATCH v4 00/14] Add SmmRelocationLib
> > >
> > >
> > >
> > > Acked-by: Jiewen Yao 
> > >
> > >
> > >
> > > From: Wu, Jiaxin 
> > > Sent: Tuesday, May 7, 2024 11:39 AM
> > > To: Ni, Ray ; devel@edk2.groups.io; Ard Biesheuvel
> > ; Yao, Jiewen 
> > > Cc: Zeng, Star ; Gerd Hoffmann ;
> > Kumar, Rahul R ; Dong, Guo ;
> > Rhodes, Sean ; Lu, James ; Guo,
> > Gua ; Abdul Lateef Attar ;
> > Abner Chang ; Tom Lendacky
> > 
> > > Subject: RE: [PATCH v4 00/14] Add SmmRelocationLib
> > >
> > >
> > >
> > > Hi Jiewen and Ard,
> > >
> > >
> > >
> > > @Yao, Jiewen, @Ard Biesheuvel, do you agree we merge the change related to
> > OVMF package since you are the OVMF maintainers. Please help check /review.
> > >
> > >
> > >
> > > The patches have been acked/tested by the Gerd.
> > >
> > >
> > >
> > >   [PATCH v4 08/14] OvmfPkg/SmmRelocationLib: Add library instance for
> > OVMF
> > >   [PATCH v4 09/14] OvmfPkg/PlatformInitLib: Create
> > gEfiSmmSmramMemoryGuid
> > >   [PATCH v4 10/14]  OvmfPkg: Refine SmmAccess implementation
> > >   [PATCH v4 11/14] OvmfPkg/SmmCpuFeaturesLib: Check Smbase Relocation
> > is done or not
> > >   [PATCH v4 12/14] OvmfPkg/PlatformPei: Relocate SmBases in PEI phase
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Jiaxin
> > >
> > >
> > >
> > > From: Wu, Jiaxin
> > > Sent: Tuesday, April 30, 2024 6:14 PM
> > > To: Ni, Ray ; devel@edk2.groups.io
> > > Cc: Zeng, Star ; Gerd Hoffmann ;
> > Kumar, Rahul R ; Dong, Guo ;
> > Rhodes, Sean ; Lu, James ; Guo,
> > Gua ; Ard Biesheuvel ; Yao,
> > Jiewen ; Abdul Lateef Attar
> > ; Abner Chang ; Tom
> > Lendacky 
> > > Subject: RE: [PATCH v4 00/14] Add SmmRelocationLib
> > >
> > >
> > >
> > > Thanks Ray, I missed to add some already reviewed-by tag in v4. All V4 
> > > patches
> > are tested & acted by Gerd:
> > >
> > > Tested-by: Gerd Hoffmann 
> > >
> > > Acked-by: Gerd Hoffmann 
> > >
> > >
> > >
> > > For each one: listed as below, *so need Ray “reviewed-by” tag on the 
> > > patch:
> > 05/06/14, need Gerd “reviewed-by” tag on the patch:  08/09/10/11/12*
> > >
> > >
> > >
> > >   [PATCH v4 01/14] UefiCpuPkg: Add SmmRelocationLib class
> > >
> > > Reviewed-by: Ray Ni   --> no change compared to V3
> > >
> > >
> > >   [PATCH v4 02/14] UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib
> > library instance
> > >
> > > Reviewed-by: Ray Ni  --> no change compared to V3
> > >
> > >
> > >   [PATCH v4 03/14] UefiCpuPkg/SmmRelocationLib: Rename global variables
> > >
> > > Reviewed-by: Ray Ni  --> no change compared to V3
> > >
> > 

Re: [edk2-devel] [PATCH v1 07/14] NetworkPkg:: SECURITY PATCH CVE-2023-45237

[Ard Biesheuvel]

I've always found that logic rather bizarre - there is no way the
implementation of the raw protocol can ensure that the caller uses it
correctly, and so enforcing a minimum read size is pointless and
arbitrary. And as you note, it has no basis in the UEFI spec either.

So this should just be removed imo.


On Wed, 8 May 2024 at 22:40, Doug Flick via groups.io
 wrote:
>
> Ard,
>
> I went ahead an added your suggestion to use gEfiRngAlgorithmRaw. This 
> however led me to discover a difference in behavior in x86 based platforms 
> and Arm based platforms and I'm usure which is the correct behavior.
>
> On x86 based platforms, if the RngValueLength being requested is less than 32 
> (256bits). Then it returns EFI_INVALID_PARAMETER (despite the function header 
> not indicating that's possible) 
> https://github.com/tianocore/edk2/blob/b82c9631da39ca5a1f0702185a46fea60446dd0a/SecurityPkg/RandomNumberGenerator/RngDxe/Rand/RngDxe.c#L123
>
> and it assumes that "When a Deterministic Random Bit Generator (DRBG) is used 
> on the output of a (raw) entropy source, its security level must be at least 
> 256 bits." means it shouldn't support requests smaller than 32 bytes. 
> https://uefi.org/specs/UEFI/2.10/37_Secure_Technologies.html#random-number-generator-protocol
>
> On Arm based Platforms it doesn't make this assumption and behaves according 
> to the specification. 
> https://github.com/tianocore/edk2/blob/b82c9631da39ca5a1f0702185a46fea60446dd0a/SecurityPkg/RandomNumberGenerator/RngDxe/ArmRngDxe.c#L106C35-L106C54
>
> Right now my thought is that x86 machines are making an incorrect assumption 
> where the seed to a DRNG needs to be at least 256 bits by nist 
> recommendations but a caller should be free to request values smaller than 32 
> bytes.
>
> Would you assume the same before I make a change to the x86 code to remove 
> that check?
>
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118704): https://edk2.groups.io/g/devel/message/118704
Mute This Topic: https://groups.io/mt/105983246/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 07/14] NetworkPkg:: SECURITY PATCH CVE-2023-45237

[Ard Biesheuvel]

On Wed, 8 May 2024 at 18:47, Doug Flick via groups.io
 wrote:
>
> I don't disagree.
>
> The intent is not to be limited by NIST specified standards but rather the 
> only UEFI Spec defined algorithms are NIST Standards.
>
> https://uefi.org/specs/UEFI/2.10/37_Secure_Technologies.html#efi-rng-algorithm-definitions
>
> I'm not sure what's the best way to clarify this distinction
>

The issue here is that virtio-rng only exposes the 'raw' RNG protocol,
which is what the underlying hardware claims to implement.

This has a special status in the spec, as it can be used as an entropy
source for the NIST algorithms, the security strength of which is
cannot exceed the security strength represented by the size of the
seed consumed from the raw input.

So in that sense, it might be appropriate to treat the raw protocol in
the same way as the NIST ones, and permit them, call them 'secure'
etc. Only when taking the default (ergo unspecified) algorithm should
we conclude that the algorithm may be less strong than what the spec
requires.

What would help is if RngDxe could wrap an implementation of the raw
RNG protocol produced by another driver, and produce the NIST DRBGs
based on that - perhaps I should look into that.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118699): https://edk2.groups.io/g/devel/message/118699
Mute This Topic: https://groups.io/mt/105983246/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 00/14] Add SmmRelocationLib

[Ard Biesheuvel]

Happy to merge this.

Liming, please let me know if this meets the soft freeze requirements?

Thanks,


On Tue, 7 May 2024 at 07:18, Wu, Jiaxin  wrote:
>
> Thanks Jiewen.
>
>
>
>
>
>
>
> From: Yao, Jiewen 
> Sent: Tuesday, May 7, 2024 12:59 PM
> To: Wu, Jiaxin ; Ni, Ray ; 
> devel@edk2.groups.io; Ard Biesheuvel 
> Cc: Zeng, Star ; Gerd Hoffmann ; 
> Kumar, Rahul R ; Dong, Guo ; 
> Rhodes, Sean ; Lu, James ; Guo, 
> Gua ; Abdul Lateef Attar ; 
> Abner Chang ; Tom Lendacky 
> Subject: RE: [PATCH v4 00/14] Add SmmRelocationLib
>
>
>
> Acked-by: Jiewen Yao 
>
>
>
> From: Wu, Jiaxin 
> Sent: Tuesday, May 7, 2024 11:39 AM
> To: Ni, Ray ; devel@edk2.groups.io; Ard Biesheuvel 
> ; Yao, Jiewen 
> Cc: Zeng, Star ; Gerd Hoffmann ; 
> Kumar, Rahul R ; Dong, Guo ; 
> Rhodes, Sean ; Lu, James ; Guo, 
> Gua ; Abdul Lateef Attar ; 
> Abner Chang ; Tom Lendacky 
> Subject: RE: [PATCH v4 00/14] Add SmmRelocationLib
>
>
>
> Hi Jiewen and Ard,
>
>
>
> @Yao, Jiewen, @Ard Biesheuvel, do you agree we merge the change related to 
> OVMF package since you are the OVMF maintainers. Please help check /review.
>
>
>
> The patches have been acked/tested by the Gerd.
>
>
>
>   [PATCH v4 08/14] OvmfPkg/SmmRelocationLib: Add library instance for OVMF
>   [PATCH v4 09/14] OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuid
>   [PATCH v4 10/14]  OvmfPkg: Refine SmmAccess implementation
>   [PATCH v4 11/14] OvmfPkg/SmmCpuFeaturesLib: Check Smbase Relocation is done 
> or not
>   [PATCH v4 12/14] OvmfPkg/PlatformPei: Relocate SmBases in PEI phase
>
>
>
> Thanks,
>
> Jiaxin
>
>
>
> From: Wu, Jiaxin
> Sent: Tuesday, April 30, 2024 6:14 PM
> To: Ni, Ray ; devel@edk2.groups.io
> Cc: Zeng, Star ; Gerd Hoffmann ; 
> Kumar, Rahul R ; Dong, Guo ; 
> Rhodes, Sean ; Lu, James ; Guo, 
> Gua ; Ard Biesheuvel ; Yao, 
> Jiewen ; Abdul Lateef Attar 
> ; Abner Chang ; Tom Lendacky 
> 
> Subject: RE: [PATCH v4 00/14] Add SmmRelocationLib
>
>
>
> Thanks Ray, I missed to add some already reviewed-by tag in v4. All V4 
> patches are tested & acted by Gerd:
>
> Tested-by: Gerd Hoffmann 
>
> Acked-by: Gerd Hoffmann 
>
>
>
> For each one: listed as below, *so need Ray “reviewed-by” tag on the patch: 
> 05/06/14, need Gerd “reviewed-by” tag on the patch:  08/09/10/11/12*
>
>
>
>   [PATCH v4 01/14] UefiCpuPkg: Add SmmRelocationLib class
>
> Reviewed-by: Ray Ni   --> no change compared to V3
>
>
>   [PATCH v4 02/14] UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib library 
> instance
>
> Reviewed-by: Ray Ni  --> no change compared to V3
>
>
>   [PATCH v4 03/14] UefiCpuPkg/SmmRelocationLib: Rename global variables
>
> Reviewed-by: Ray Ni  --> no change compared to V3
>
>
>  [PATCH v4 04/14]  UefiCpuPkg/SmmRelocationLib: Avoid unnecessary memory 
> allocation
>
> Reviewed-by: Ray Ni  --> no change compared to V3
>
>
>   [PATCH v4 05/14] UefiCpuPkg/SmmRelocationLib: Remove unnecessary global 
> variable
>   [PATCH v4 06/14] UefiCpuPkg/SmmRelocationLib: Remove unnecessary CpuIndex
>
> * Change Based on Ray’s comment on V3: split the removal of CpuIndex 
> parameter in a new patch, so add the 06 patch in V4.*
>
>
>   [PATCH v4 07/14] UefiCpuPkg/SmmRelocationLib: Add library instance for AMD
>
> Reviewed-by: Abdul Lateef Attar  --> no change 
> compared to V3
>
>
>   [PATCH v4 08/14] OvmfPkg/SmmRelocationLib: Add library instance for OVMF
>   [PATCH v4 09/14] OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuid
>   [PATCH v4 10/14]  OvmfPkg: Refine SmmAccess implementation
>   [PATCH v4 11/14] OvmfPkg/SmmCpuFeaturesLib: Check Smbase Relocation is done 
> or not
>   [PATCH v4 12/14] OvmfPkg/PlatformPei: Relocate SmBases in PEI phase
>
> *Change Based on Gerd’s  comment on V3: 1. Creating the 
> EFI_SMM_SMRAM_MEMORY_GUID HOB should be moved to its own function.  2) refine 
> the comment in SmmAccess 3) refine the commit log.*
>
>
>   [PATCH v4 13/14] UefiPayloadPkg/UefiPayloadPkg.dsc: Include SmmRelocationLib
>
> Reviewed-by: Gua Guo 
>
> Reviewed-by: Guo Dong 
>
>
>   [PATCH v4 14/14] UefiCpuPkg/PiSmmCpuDxeSmm: Remove SmBases relocation logic
>
> *Change Based on Ray’s comment on V3: move the "TileSize" check just below 
> the original TileSize calculation logic*
>
>
>
> Thanks,
>
> Jiaxin
>
>
>
> From: Ni, Ray 
> Sent: Tuesday, April 30, 2024 2:01 PM
> To: Wu, Jiaxin ; devel@edk2.groups.io
> Cc: Zeng, Star ; Gerd Hoffmann ; 
> Kumar, Rahul R ; Dong, Guo ; 
> Rhodes, Sean ; Lu, James ; Guo, 
> Gua ; Ard Biesheuvel ; Yao, 
> Jiewe

Re: [edk2-devel] [PATCH v1 07/14] NetworkPkg:: SECURITY PATCH CVE-2023-45237

[Ard Biesheuvel]

On Wed, 8 May 2024 at 17:29, Doug Flick via groups.io
 wrote:
>
> From: Doug Flick 
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4542
>
> Bug Overview:
> PixieFail Bug #9
> CVE-2023-45237
> CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
> CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
>
> Use of a Weak PseudoRandom Number Generator
>
> Change Overview:
>
> Updates all Instances of NET_RANDOM (NetRandomInitSeed ()) to either
>
> >
> > EFI_STATUS
> > EFIAPI
> > PseudoRandomU32 (
> >  OUT UINT32  *Output
> >  );
> >
>
> or (depending on the use case)
>
> >
> > EFI_STATUS
> > EFIAPI
> > PseudoRandom (
> >  OUT  VOID   *Output,
> >  IN   UINTN  OutputLength
> >  );
> >
>
> This is because the use of
>
> Example:
>
> The following code snippet PseudoRandomU32 () function is used:
>
> >
> > UINT32 Random;
> >
> > Status = PseudoRandomU32 ();
> > if (EFI_ERROR (Status)) {
> >   DEBUG ((DEBUG_ERROR, "%a failed to generate random number: %r\n",
> __func__, Status));
> >   return Status;
> > }
> >
>
> This also introduces a new PCD to enable/disable the use of the
> NIST SP-800-90 approved algorithms for PseudoRandom () and
> instead depend on the default implementation. This may be required for
> some platforms where the UEFI Spec defined algorithms are not available.
>
> >
> > PcdEnforceSecureRngAlgorithms
> >
>
> If the platform does not have the NIST SP-800-90 approved algorithms
> then the driver will assert.
>
> Cc: Saloni Kasbekar 
> Cc: Zachary Clark-williams 
>
> Signed-off-by: Doug Flick [MSFT] 
> ---
>  NetworkPkg/NetworkPkg.dec  |   7 ++
>  NetworkPkg/Library/DxeNetLib/DxeNetLib.inf |  12 +-
>  NetworkPkg/TcpDxe/TcpDxe.inf   |   3 +
>  NetworkPkg/IScsiDxe/IScsiMisc.h|   6 +-
>  NetworkPkg/Include/Library/NetLib.h|  40 --
>  NetworkPkg/Ip6Dxe/Ip6Nd.h  |   8 +-
>  NetworkPkg/Dhcp4Dxe/Dhcp4Driver.c  |  10 +-
>  NetworkPkg/Dhcp6Dxe/Dhcp6Driver.c  |  11 +-
>  NetworkPkg/DnsDxe/DnsDhcp.c|  10 +-
>  NetworkPkg/DnsDxe/DnsImpl.c|  11 +-
>  NetworkPkg/HttpBootDxe/HttpBootDhcp6.c |  10 +-
>  NetworkPkg/IScsiDxe/IScsiCHAP.c|  19 ++-
>  NetworkPkg/IScsiDxe/IScsiMisc.c|  14 +--
>  NetworkPkg/Ip4Dxe/Ip4Driver.c  |  10 +-
>  NetworkPkg/Ip6Dxe/Ip6ConfigImpl.c  |   9 +-
>  NetworkPkg/Ip6Dxe/Ip6Driver.c  |  17 ++-
>  NetworkPkg/Ip6Dxe/Ip6If.c  |  12 +-
>  NetworkPkg/Ip6Dxe/Ip6Mld.c |  12 +-
>  NetworkPkg/Ip6Dxe/Ip6Nd.c  |  33 -
>  NetworkPkg/Library/DxeNetLib/DxeNetLib.c   | 129 +---
>  NetworkPkg/TcpDxe/TcpDriver.c  |  15 ++-
>  NetworkPkg/Udp4Dxe/Udp4Driver.c|  10 +-
>  NetworkPkg/Udp6Dxe/Udp6Driver.c|  11 +-
>  NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c   |   9 +-
>  NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c   |  11 +-
>  NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c  |  12 +-
>  NetworkPkg/SecurityFixes.yaml  |  39 ++
>  27 files changed, 407 insertions(+), 83 deletions(-)
>
> diff --git a/NetworkPkg/NetworkPkg.dec b/NetworkPkg/NetworkPkg.dec
> index e06f35e7747c..7c4289b77b21 100644
> --- a/NetworkPkg/NetworkPkg.dec
> +++ b/NetworkPkg/NetworkPkg.dec
> @@ -5,6 +5,7 @@
>  #
>  # Copyright (c) 2009 - 2021, Intel Corporation. All rights reserved.
>  # (C) Copyright 2015-2020 Hewlett Packard Enterprise Development LP
> +# Copyright (c) Microsoft Corporation
>  #
>  # SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -130,6 +131,12 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
># @Prompt Indicates whether SnpDxe creates event for ExitBootServices() 
> call.
>
> gEfiNetworkPkgTokenSpaceGuid.PcdSnpCreateExitBootServicesEvent|TRUE|BOOLEAN|0x100C
>
> +  ## Enforces the use of Secure UEFI spec defined RNG algorithms for all 
> network connections.
> +  # TRUE  - Enforce the use of Secure UEFI spec defined RNG algorithms.
> +  # FALSE - Do not enforce and depend on the default implementation of RNG 
> algorithm from the provider.
> +  # @Prompt Enforce the use of Secure UEFI spec defined RNG algorithms.
> +  
> gEfiNetworkPkgTokenSpaceGuid.PcdEnforceSecureRngAlgorithms|TRUE|BOOLEAN|0x100D
> +

This conflates 'secure' with 'specified by NIST', which I don't think
is entirely accurate.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118691): https://edk2.groups.io/g/devel/message/118691
Mute This Topic: https://groups.io/mt/105983246/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] pr for stable tag

[Ard Biesheuvel]

Yes

On Wed, 8 May 2024 at 17:36, gaoliming via groups.io
 wrote:
>
> Ard:
>   So, this patch needs to catch this stable tag. Right?
>
> Thanks
> Liming
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Ard Biesheuvel
> > 发送时间: 2024年5月8日 20:41
> > 收件人: Liming Gao (Byosoft address) ; Michael
> > Kinney ; Leif Lindholm
> > ; edk2-devel-groups-io 
> > 抄送: Peter Batard 
> > 主题: [edk2-devel] pr for stable tag
> >
> > Please set the push label on
> >
> > https://github.com/tianocore/edk2/pull/5642
> >
> > discussed here:
> >
> > https://openfw.io/edk2-devel/20240508085148.1725-1-p...@akeo.ie/
> >
> >
> >
> >
>
>
>
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118690): https://edk2.groups.io/g/devel/message/118690
Mute This Topic: https://groups.io/mt/105984326/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] pr for stable tag

[Ard Biesheuvel]

Please set the push label on

https://github.com/tianocore/edk2/pull/5642

discussed here:

https://openfw.io/edk2-devel/20240508085148.1725-1-p...@akeo.ie/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118671): https://edk2.groups.io/g/devel/message/118671
Mute This Topic: https://groups.io/mt/105979790/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] MdePkg/BaseLib: Fix undefined symbol when compiling with Visual Studio

[Ard Biesheuvel]

On Wed, 8 May 2024 at 11:21, Pete Batard  wrote:
>
> Hi Ard,
>
> Thanks for the quick review.
>
> Note that as opposed to the previous one you referenced, that patches
> both the .S and the .asm, my submission only patches the .asm, so it's
> probably better to use Adam Liu's for integration (who was the first to
> propose a fix anyway).
>

Yeah, we'll end up merging the other patch, most likely. But thanks
for reminding us of this issue - it does need fixing.

> As to your other question, see inline:
>
> On 2024.05.08 10:08, Ard Biesheuvel wrote:
> > On Wed, 8 May 2024 at 11:07, Ard Biesheuvel  wrote:
> >>
> >> On Wed, 8 May 2024 at 10:52, Pete Batard  wrote:
> >>>
> >>> Commit 80bbea192aa44ab664ba8be29ac06c83f246e99c introduced a regression
> >>> resulting in 'error A2023: undefined symbol: InternalAssertJumpBuffer'
> >>> when compling MdePkg for AARCH64 with Visual Studio.
> >>> Fix this by adding the relevant EXTERN reference.
> >>>
> >>> Signed-off-by: Pete Batard 
> >>> Cc: Leif Lindholm 
> >>> Cc: Ard Biesheuvel 
> >>
> >> Reviewed-by: Ard Biesheuvel 
> >>
> >> Note that the same issue has been raised two months ago, and a similar
> >> fix proposed
> >>
> >> https://openfw.io/edk2-devel/20240320025130.599086-1-adam@tw.synaptics.com/
> >>
> >> so IMHO this qualifies for inclusion in the stable tag.
> >>
> >
> > BTW the existence of this issue appears to imply that the VS RELEASE
> > build does not #define MDEPKG_NDEBUG. Is that an oversight?
>
> In my testing with VS2022 (with '-b RELEASE'), adding:
>
> #ifdef MDEPKG_NDEBUG
> #error MDEPKG_NDEBUG is defined
> #endif
>
> to SetJump.c does produce the expected:
>
> d:\edk2\MdePkg\Library\BaseLib\SetJump.c(12): fatal error C1189: #error:
>   MDEPKG_NDEBUG is defined
>
> So as far as I can tell, MDEPKG_NDEBUG is properly defined.
>

The reference to InternalAssertJumpBuffer was intended to only be
emitted if MDEPKG_NDEBUG is not defined, but this appears to be broken
too.

MDEPKG_NDEBUG is added to the CC flags only, never to the PP flags -
given that a #define is fundamentally a PP flag, it would be better if
all -D flags were carried in a separate variable that gets added to
both, but this is future refactoring that I won't get around to
myself, most probably.

Leif, any thoughts?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118670): https://edk2.groups.io/g/devel/message/118670
Mute This Topic: https://groups.io/mt/105977470/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] MdePkg/BaseLib: Fix undefined symbol when compiling with Visual Studio

[Ard Biesheuvel]

On Wed, 8 May 2024 at 11:07, Ard Biesheuvel  wrote:
>
> On Wed, 8 May 2024 at 10:52, Pete Batard  wrote:
> >
> > Commit 80bbea192aa44ab664ba8be29ac06c83f246e99c introduced a regression
> > resulting in 'error A2023: undefined symbol: InternalAssertJumpBuffer'
> > when compling MdePkg for AARCH64 with Visual Studio.
> > Fix this by adding the relevant EXTERN reference.
> >
> > Signed-off-by: Pete Batard 
> > Cc: Leif Lindholm 
> > Cc: Ard Biesheuvel 
>
> Reviewed-by: Ard Biesheuvel 
>
> Note that the same issue has been raised two months ago, and a similar
> fix proposed
>
> https://openfw.io/edk2-devel/20240320025130.599086-1-adam@tw.synaptics.com/
>
> so IMHO this qualifies for inclusion in the stable tag.
>

BTW the existence of this issue appears to imply that the VS RELEASE
build does not #define MDEPKG_NDEBUG. Is that an oversight?

>
> > ---
> >  MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm 
> > b/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm
> > index 6ec8f35f2c9f..fa161e25f517 100644
> > --- a/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm
> > +++ b/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm
> > @@ -7,6 +7,7 @@
> >
> >EXPORT SetJump
> >EXPORT InternalLongJump
> > +  EXTERN InternalAssertJumpBuffer
> >AREA BaseLib_LowLevel, CODE, READONLY
> >
> >  #define GPR_LAYOUT  \
> > --
> > 2.45.0.windows.1
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118668): https://edk2.groups.io/g/devel/message/118668
Mute This Topic: https://groups.io/mt/105977470/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] MdePkg/BaseLib: Fix undefined symbol when compiling with Visual Studio

[Ard Biesheuvel]

On Wed, 8 May 2024 at 10:52, Pete Batard  wrote:
>
> Commit 80bbea192aa44ab664ba8be29ac06c83f246e99c introduced a regression
> resulting in 'error A2023: undefined symbol: InternalAssertJumpBuffer'
> when compling MdePkg for AARCH64 with Visual Studio.
> Fix this by adding the relevant EXTERN reference.
>
> Signed-off-by: Pete Batard 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 

Reviewed-by: Ard Biesheuvel 

Note that the same issue has been raised two months ago, and a similar
fix proposed

https://openfw.io/edk2-devel/20240320025130.599086-1-adam@tw.synaptics.com/

so IMHO this qualifies for inclusion in the stable tag.


> ---
>  MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm 
> b/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm
> index 6ec8f35f2c9f..fa161e25f517 100644
> --- a/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm
> +++ b/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.asm
> @@ -7,6 +7,7 @@
>
>EXPORT SetJump
>EXPORT InternalLongJump
> +  EXTERN InternalAssertJumpBuffer
>AREA BaseLib_LowLevel, CODE, READONLY
>
>  #define GPR_LAYOUT  \
> --
> 2.45.0.windows.1
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118667): https://edk2.groups.io/g/devel/message/118667
Mute This Topic: https://groups.io/mt/105977470/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Assistance Needed: ArmVirtPkg

[Ard Biesheuvel]

There are no code changes, the only difference is adding the --pcd
PcdMonitorConduitHvc=TRUE option to the build.sh command line, and
running QEMU with -device virtio-rng-pci (which we should be doing in
any case, IMO)

The DEPEX might fix this, and this is actually the appropriate thing
to do if the driver cannot even be dispatched without the RNG protocol
available. However, I'm not convinced this is the right approach - I
think dispatching the driver but failing in the Supported() call on a
missing RNG protocol would be less disruptive, and give more
opportunity for a meaningful warning/error message to the actual user.

But I must admit I have only taken a very cursory look at the
underlying CVE and your proposed mitigation.



On Wed, 8 May 2024 at 00:28, Doug Flick via groups.io
 wrote:
>
> Thanks Ard for the explanation! Would you be able to tell me the exact 
> changes you made to get to this point and if that would be an acceptable 
> change to make to get these CVE patches on the mailing list? I'm happy adding 
> the depex but fundamentally I think the goal is get these patches into this 
> release. My attempts to rollback some of my changes and use VirtioRngDxe have 
> been unsuccessful so far.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118649): https://edk2.groups.io/g/devel/message/118649
Mute This Topic: https://groups.io/mt/105949609/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Assistance Needed: ArmVirtPkg

[Ard Biesheuvel]

On Tue, 7 May 2024 at 00:22, Doug Flick  wrote:
>
> All,
>
> In order to patch Tianocore Bugzilla issues and CVEs:
>  4541 – Bug 08 - edk2/NetworkPkg: Predictable TCP ISNs (tianocore.org)
> and
> 4542 – Bug 09 - edk2/NetworkPkg: Use of a Weak PseudoRandom Number Generator 
> (tianocore.org)
>
> I've added as a dependency Hash2CryptoDxe and RngDxe lib to NetworkPkg. I've 
> been able to add the relevant libraries to the DSCs of OvmfPkg and 
> EmulatorPkg however I'm seeing odd behavior with ArmVirtPkg.
>
> Would someone more knowledgeable with ArmVirtPkg take a look this PR.
>
> PixieFail #8 and #9 TCBZ4541 and TCBZ4542 by Flickdm · Pull Request #5582 · 
> tianocore/edk2 (github.com)
>
> The issue was introduced in the commit "ArmVirtPkg: : Add RngDxe to 
> ArmVirtPkg"
>
> Right now PlatformCI_ArmVirtPkg_Ubuntu_GCC5_PR is crashing

You need to configure the TrngLib to use either secure monitor calls
or hypervisor calls, and this might be different depending on the
context:

- ordinary VMs running under proper virtualization will execute at EL1
under a hypervisor that implements the TRNG service, so it can only
use HVC (and SMC will trap, as you've experienced)

- QEMU itself does not implement the TRNG service (to my knowledge) so
running a VM under TCG emulation of EL1 will not have access to the
TRNG

- other emulation modes of QEMU may run the firmware in a different
way, where SMC is actually appropriate, and this could be either EL1
or EL2.

This makes it slightly awkward to decide whether or not to dispatch
RngDxe, and this is why nobody has gotten around to it (and I forgot
about this tbh)


TL;DR

building with --pcd PcdMonitorConduitHvc=TRUE will avoid the crash but
may not result in a usable RngDxe


It also seems to me that those network drivers will now need to DEPEX
on the RNG protocol, as they may get dispatched too early otherwise:

Failed to generate random data using secure algorithm 0: Unsupported
Failed to generate random data using secure algorithm 1: Unsupported
Failed to generate random data using secure algorithm 2: Unsupported

ASSERT_EFI_ERROR (Status = Unsupported)
ASSERT [Udp4Dxe] DxeNetLib.c(973): !(((INTN)(RETURN_STATUS)(Status)) < 0)
QEMU: Terminated

This is with -device virtio-rng-pci and the VirtioRngDxe driver (which
is already included in OVMF and ArmVirtQemu) but the driver dispatches
before the driver model can instantiate the protocol.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118646): https://edk2.groups.io/g/devel/message/118646
Mute This Topic: https://groups.io/mt/105949609/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Ard Biesheuvel]

On Mon, 6 May 2024 at 17:57, Kinney, Michael D
 wrote:
>
> Hi Ard,
>
> Thais is an attribute of Mergify.  I do not see a way to change that
> behavior.
>
> I do not know if using the GitHub merge capability or other merge services
> provides different behavior here or not.
>
> This specific request is not related to the change to GitHub PRs
> for code review.  There is no intention to change the requirement
> for a maintainer to set the 'push' label and no intention to change
> away from Mergify at this time.
>
> Perhaps we can open your request as an independent request that we
> can find an owner to evaluate options and provide recommendations.
>

Yep that works for me - it is not an urgent issue anyway, just
something I realized while going through the thread.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118603): https://edk2.groups.io/g/devel/message/118603
Mute This Topic: https://groups.io/mt/105873467/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Ard Biesheuvel]

On Mon, 6 May 2024 at 17:11, Kinney, Michael D
 wrote:
>
> That information is in GitHub in the PR conversation.
>
> If you follow the link from the commit to the PR, the PR conversation shows
> who set the 'push' label.
>

But that is GitHub proprietary metadata, no? Is it not possible to set
the committer field in Git itself to something meaningful?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118601): https://edk2.groups.io/g/devel/message/118601
Mute This Topic: https://groups.io/mt/105873467/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 20/26] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib

[Ard Biesheuvel]

On Mon, 6 May 2024 at 12:02, Chao Li  wrote:
>
> Hi Gerd,
>
>
> Thanks,
> Chao
> On 2024/3/19 16:03, Gerd Hoffmann wrote:
>
>   Hi,
>
> I can't tell the implementation scheme of the current lib and existing
> lib implementation scheme which one is better, Could you give we some
> advice?
>
> I'd suggest to merge your code as OvmfPkg/Library/FdtNorFlashQemuLib as
> it is not really loongarch-specific.
>
> If you want try switch aarch64 to use the same code that'll be great,
> but sorting that out later is also fine with me.
>
> If you think this design is looks better, then I'm prepare to commit this
> change under the OvmfPkg/Library as a public library. And I will enable it
> in aarch64 after merging this change, because I think it may be tweaked and
> validated in aarch64 for many platforms. Do you think that is good?
>
> The VirtNorFlashDxe is optimized for qemu-emulated pflash.  It tries to
> avoid switching between read and write mode much, because that operation
> has a significant overhead in virtualization.  So it's really only used
> by ArmVirtPkg and not lots of other arm platforms.
>
> I'm moving the ARM version of the library to OvmfPkg and adding the set PCD 
> method, I have verified successfully on ArmVirtQemu.dsc(both -bios and 
> pflash), but I found that the ArmVirtQemuKernel.dsc also depends this 
> library, so what's the difference between the two platforms?
>
> When I try to verify on ArmVirtQemuKernel.dsc that it works based on -bios 
> option,  I use the command line "qemu-system-aarch64 -M virt -cpu cortex-a57 
> -bios LA_Virt_FW/AARCH64/QEMU_EFI.fd -net none -serial stdio -hdb 
> /home/lichao/Software/Qemu/SctPkg/share.imag -device ramfb -device 
> nec-usb-xhci -device usb-mouse -device usb-kbd", and it tells me "Could not 
> open option rom 'vgabios-ramfb.bin': No such file or directory", I tried 
> removing the option "-device ramfb", it looks like can't work.
>
> How does ArmVirtQemuKernel.dsc work?
>

It uses the -kernel QEMU command line argument, not the -bios one.

This uses the Linux/arm64 kernel boot protocol (and runs the firmware
entirely from RAM) rather than booting from NOR flash.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118595): https://edk2.groups.io/g/devel/message/118595
Mute This Topic: https://groups.io/mt/104859896/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-rfc] [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Ard Biesheuvel]

This reminds me: would it be possible to keep track of who merged a
PR? (i.e., the person that set the 'push' label)

Currently, commits just appear on the branch with the original author
and the committer field set to something non-descript, e.g.,

commit 275d0a39c42ad73a6e4929822f56f5d8c16ede96 (HEAD -> master,
origin/master, origin/HEAD)
Author: Gerd Hoffmann 
AuthorDate: Fri Mar 1 08:44:00 2024 +0100
Commit: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
CommitDate: Fri Mar 1 18:47:27 2024 +

which means we cannot tell from the git history which maintainer merged this.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118593): https://edk2.groups.io/g/devel/message/118593
Mute This Topic: https://groups.io/mt/105873467/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 0/3] OvmfPkg: Don't make APIC MMIO accesses with encryption bit set

[Ard Biesheuvel]

On Thu, 2 May 2024 at 11:06, Gerd Hoffmann  wrote:
>
> On Wed, May 01, 2024 at 02:03:37PM GMT, Michael Roth wrote:
> > For the most part, OVMF will clear the encryption bit for MMIO regions,
> > but there is currently one known exception during SEC when the APIC
> > base address is accessed via MMIO with the encryption bit set for
> > SEV-ES/SEV-SNP guests. In the case of SEV-SNP, this requires special
> > handling on the hypervisor side which may not be available in the
> > future[1], so make the necessary changes in the SEC-configured page
> > table to clear the encryption bit for 4K region containing the APIC
> > base address.
> >
> > Since CpuPageTableLib is used to handle the splitting, some additional
> > care must be taken to clear the C-bit in all non-leaf PTEs since the
> > library expects that to be the case. Add handling for that when setting
> > up the SEC page table.
> >
> > While here, drop special handling for the APIC base address in the
> > SEV-ES/SNP #VC handler.
>
> Series:
> Reviewed-by: Gerd Hoffmann 
>

Thanks, I've picked these up now.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118507): https://edk2.groups.io/g/devel/message/118507
Mute This Topic: https://groups.io/mt/105849106/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Ard Biesheuvel]

On Wed, 1 May 2024 at 19:44, Michael D Kinney
 wrote:
>
> Hello,
>
> I would like to propose that TianoCore move all code review from email
> based code reviews to GitHub Pull Requests based code reviews.
>
> The proposed date to switch would be immediately after the next stable
> tag which is currently scheduled for May 24, 2024.
>

+1

Some kind of off-github reflector similar to rebecca's public inbox
[0] would be appreciated to at least be able to keep track of
different versions of a series exactly as they were submitted. One of
the things that annoys me about doing GitHub reviews is dealing with
PRs where the underlying branches gets updated through a force-push
and there is no way to find out what changed, and whether the existing
review comments are still in sync.

Would it be possible to require a separate PR for each revision of a
series, lock the underlying branch, and archive it for future
reference (if desired?)


[0] https://openfw.io/edk2-devel/


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118503): https://edk2.groups.io/g/devel/message/118503
Mute This Topic: https://groups.io/mt/105847510/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 0/8] Adjust the QemuFwCfgLibMmio and add PEI stage

[Ard Biesheuvel]

On Tue, 30 Apr 2024 at 09:47, Chao Li  wrote:
>
> Patch1: Added three PCDs for QemuFwCfgLibMmio
> Patch2: Sparate QemuFwCfgLibMmio.c into two files and default as DXE
> stage library.
> Patch3: Added QemuFwCfgMmiLib PEI version
> Patch4: Rename QemuFwCfgLibMmio.inf to QemuFwCfgMmioDxeLib.inf and
> enable it in AARCH64 and RISCV64.
>
> V1 -> V2:
> 1. Use HOBs instead of PCD.
> 2. The old patch2 is divided into two parts, one is code splitting, and
> the other is functional changes.
> 3. add two patches to keep the safe when change the platform DSC file.
>
> V2 -> V3:
> 1. Merge three HOBs into a single HOB.
> 2. Remove the dynamic global variables in PEI.
>
> V3 -> V4:
> 1. Adjust the HOB content, this version saves all of structual contents
> in HOB.
> 2. Remove the Loongson copyright in separation patch, and add it in the
> funciton change patch.
> 3. Restored some variables as static in DXE version.
> 4. Added the HOB GUID in OvmfPkg.dec.
>
> V4 -> V5
> 1. Adjust the PEI version some logic error, it will built the HOB after
> the QEMU check passes.
> 2. Adjust some code style.
> 3. Remove the architecture comment in PEI INF.
> 4. Reoder the PEI INF in alphabetical order.
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
>
> PR: https://github.com/tianocore/edk2/pull/5568
>
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Gerd Hoffmann 
> Cc: Leif Lindholm 
> Cc: Sami Mujawar 
> Cc: Sunil V L 
> Cc: Andrei Warkentin 
>
> Chao Li (8):
>   OvmfPkg: Add a GUID for QemuFwCfgLib
>   OvmfPkg: Separate QemuFwCfgLibMmio.c into two files
>   OvmfPkg: Add the way of HOBs in QemuFwCfgLibMmio
>   OvmfPkg: Add the QemuFwCfgMmioLib PEI stage version
>   OvmfPkg: Copy the same new INF as QemuFwCfgLibMmio.inf
>   ArmVirtPkg: Enable QemuFwCfgMmioDxeLib.inf
>   OvmfPkg/RiscVVirt: Enable QemuFwCfgMmioDxeLib.inf
>   OvmfPkg: Remove QemuFwCfgLibMmio.inf
>

Thanks - I've queued these up now


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118435): https://edk2.groups.io/g/devel/message/118435
Mute This Topic: https://groups.io/mt/105816958/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 4/8] OvmfPkg: Add the QemuFwCfgMmioLib PEI stage version

[Ard Biesheuvel]

On Fri, 26 Apr 2024 at 10:29, Chao Li  wrote:
>
> Added the PEI stage library for QemuFwCfgMmioLib, which uses the FDT to
> find the fw_cfg and parse it.
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
>
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Gerd Hoffmann 
> Co-authored-by: Xianglai Li 
> Signed-off-by: Chao Li 
> ---
>  .../Library/QemuFwCfgLib/QemuFwCfgMmioPei.c   | 235 ++
>  .../QemuFwCfgLib/QemuFwCfgMmioPeiLib.inf  |  52 
>  2 files changed, 287 insertions(+)
>  create mode 100644 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgMmioPei.c
>  create mode 100644 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgMmioPeiLib.inf
>
> diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgMmioPei.c 
> b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgMmioPei.c
> new file mode 100644
> index 00..055148de8e
> --- /dev/null
> +++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgMmioPei.c
> @@ -0,0 +1,235 @@
> +/** @file
> +
> +  Stateful and implicitly initialized fw_cfg library implementation.
> +
> +  Copyright (C) 2013 - 2014, Red Hat, Inc.
> +  Copyright (c) 2011 - 2013, Intel Corporation. All rights reserved.
> +  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
> +  Copyright (c) 2024 Loongson Technology Corporation Limited. All rights 
> reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "QemuFwCfgLibMmioInternal.h"
> +
> +/**
> +  To get firmware configure selector address.
> +
> +  @param VOID
> +
> +  @retval  firmware configure selector address
> +**/
> +UINTN
> +EFIAPI
> +QemuGetFwCfgSelectorAddress (
> +  VOID
> +  )
> +{
> +  QEMU_FW_CFG_RESOURCE  *FwCfgResource;
> +
> +  FwCfgResource = QemuGetFwCfgResourceHob ();
> +  ASSERT (FwCfgResource != NULL);
> +
> +  return FwCfgResource->FwCfgSelectorAddress;
> +}
> +
> +/**
> +  To get firmware configure Data address.
> +
> +  @param VOID
> +
> +  @retval  firmware configure data address
> +**/
> +UINTN
> +EFIAPI
> +QemuGetFwCfgDataAddress (
> +  VOID
> +  )
> +{
> +  QEMU_FW_CFG_RESOURCE  *FwCfgResource;
> +
> +  FwCfgResource = QemuGetFwCfgResourceHob ();
> +  ASSERT (FwCfgResource != NULL);
> +
> +  return FwCfgResource->FwCfgDataAddress;
> +}
> +
> +/**
> +  To get firmware DMA address.
> +
> +  @param VOID
> +
> +  @retval  firmware DMA address
> +**/
> +UINTN
> +EFIAPI
> +QemuGetFwCfgDmaAddress (
> +  VOID
> +  )
> +{
> +  QEMU_FW_CFG_RESOURCE  *FwCfgResource;
> +
> +  FwCfgResource = QemuGetFwCfgResourceHob ();
> +  ASSERT (FwCfgResource != NULL);
> +
> +  return FwCfgResource->FwCfgDmaAddress;
> +}
> +
> +RETURN_STATUS
> +EFIAPI
> +QemuFwCfgInitialize (
> +  VOID
> +  )
> +{
> +  VOID  *DeviceTreeBase;
> +  INT32 Node;
> +  INT32 Prev;
> +  CONST CHAR8   *Type;
> +  INT32 Len;
> +  CONST UINT64  *Reg;
> +  UINT64FwCfgSelectorAddress;
> +  UINT64FwCfgSelectorSize;
> +  UINT64FwCfgDataAddress;
> +  UINT64FwCfgDataSize;
> +  UINT64FwCfgDmaAddress;
> +  UINT64FwCfgDmaSize;
> +  QEMU_FW_CFG_RESOURCE  *FwCfgResource;
> +  VOID  *Buffer;
> +
> +  //
> +  // Check whether the Qemu firmware configure resources HOB has been 
> created,
> +  // if so use the resources in the HOB.
> +  //
> +  FwCfgResource = QemuGetFwCfgResourceHob ();
> +  if (FwCfgResource != NULL) {
> +return RETURN_SUCCESS;
> +  }
> +
> +  DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress);
> +  ASSERT (DeviceTreeBase != NULL);
> +  //
> +  // Make sure we have a valid device tree blob
> +  //
> +  ASSERT (fdt_check_header (DeviceTreeBase) == 0);
> +
> +  //
> +  // Create resouce memory
> +  //
> +  Buffer = AllocatePages(EFI_SIZE_TO_PAGES (sizeof (QEMU_FW_CFG_RESOURCE)));
> +  ASSERT (Buffer != NULL);
> +  ZeroMem (Buffer, sizeof (QEMU_FW_CFG_RESOURCE));
> +
> +  FwCfgResource = (QEMU_FW_CFG_RESOURCE *)Buffer;
> +

You will need to respin after all, so please incorporate the fixes I
proposed on v4

> +  for (Prev = 0; ; Prev = Node) {
> +Node = fdt_next_node (DeviceTreeBase, Prev, NULL);
> +if (Node < 0) {
> +  break;
> +}
> +
> +//
> +// Check for memory node
> +//
> +Type = fdt_getprop (DeviceTreeBase, Node, "compatible", );
> + 

Re: [edk2-devel] [PATCH v4 0/8] Adjust the QemuFwCfgLibMmio and add PEI stage

[Ard Biesheuvel]

On Mon, 29 Apr 2024 at 09:09, Chao Li  wrote:
>
> Hi Ard,
>
> OK, I will make adjustments according to your suggestions and submit the V5 
> today.
>

No, please do not make any adjustments. I will take the v4 and apply
these changes directly.

Please do not send another revision unless there are other review comments.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118378): https://edk2.groups.io/g/devel/message/118378
Mute This Topic: https://groups.io/mt/105746786/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 0/8] Adjust the QemuFwCfgLibMmio and add PEI stage

[Ard Biesheuvel]

On Mon, 29 Apr 2024 at 03:17, Chao Li  wrote:
>
> Hi Ard and Gerd and other maintainers,
>
> Could you review this version and give your suggestions?
>

This looks ok to me now, modulo a few minor tweaks (see below) that I
will apply when merging.

I also changed the type signatures to

extern
VOID
(EFIAPI *InternalQemuFwCfgReadBytes) (
  IN UINTN  Size,
  IN VOID   *Buffer  OPTIONAL
  );

Note that the EFIAPI applies to the function itself, not the pointer
so it needs to be inside the ()



--- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgMmioPei.c
+++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgMmioPei.c
@@ -104,7 +104,6 @@ QemuFwCfgInitialize (
   UINT64FwCfgDmaAddress;
   UINT64FwCfgDmaSize;
   QEMU_FW_CFG_RESOURCE  *FwCfgResource;
-  VOID  *Buffer;

   //
   // Check whether the Qemu firmware configure resources HOB has been created,
@@ -125,11 +124,8 @@ QemuFwCfgInitialize (
   //
   // Create resouce memory
   //
-  Buffer = AllocatePages(EFI_SIZE_TO_PAGES (sizeof (QEMU_FW_CFG_RESOURCE)));
-  ASSERT (Buffer != NULL);
-  ZeroMem (Buffer, sizeof (QEMU_FW_CFG_RESOURCE));
-
-  FwCfgResource = (QEMU_FW_CFG_RESOURCE *)Buffer;
+  FwCfgResource = AllocateZeroPool (sizeof (QEMU_FW_CFG_RESOURCE));
+  ASSERT (FwCfgResource != NULL);

   for (Prev = 0; ; Prev = Node) {
 Node = fdt_next_node (DeviceTreeBase, Prev, NULL);
@@ -141,7 +137,7 @@ QemuFwCfgInitialize (
 // Check for memory node
 //
 Type = fdt_getprop (DeviceTreeBase, Node, "compatible", );
-if ((Type) &&
+if ((Type != NULL) &&
 (AsciiStrnCmp (Type, "qemu,fw-cfg-mmio", Len) == 0))
 {
   //


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118376): https://edk2.groups.io/g/devel/message/118376
Mute This Topic: https://groups.io/mt/105746786/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] Maintainers.txt: Update StandaloneMmPkg and UefiCpuPkg Reviewer

[Ard Biesheuvel]

On Mon, 29 Apr 2024 at 07:32, Jiaxin Wu  wrote:
>
> This is to update StandaloneMmPkg and UefiCpuPkg Reviewer.
>
> Cc: Ray Ni 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Signed-off-by: Jiaxin Wu 

Thanks for helping out.

I am going to queue this up.

> ---
>  Maintainers.txt | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 7d9cdca611..6fccbb6788 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -624,17 +624,19 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebugPkg
>  StandaloneMmPkg
>  F: StandaloneMmPkg/
>  M: Ard Biesheuvel  [ardbiesheuvel]
>  M: Sami Mujawar  [samimujawar]
>  M: Ray Ni  [niruiyu]
> +R: Jiaxin Wu  [jiaxinwu]
>
>  UefiCpuPkg
>  F: UefiCpuPkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
>  M: Ray Ni  [niruiyu]
>  R: Rahul Kumar  [rahul1-kumar]
>  R: Gerd Hoffmann  [kraxel]
> +R: Jiaxin Wu  [jiaxinwu]
>
>  UefiCpuPkg: Sec related modules
>  F: UefiCpuPkg/SecCore/
>  F: UefiCpuPkg/ResetVector/
>  R: Catharine West  [catharine-intl]
> --
> 2.16.2.windows.1
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118375): https://edk2.groups.io/g/devel/message/118375
Mute This Topic: https://groups.io/mt/105795833/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] OvmfPkg: Don't make APIC MMIO accesses with encryption bit set

[Ard Biesheuvel]

On Fri, 26 Apr 2024 at 16:16, Roth, Michael via groups.io
 wrote:
>
> On Fri, Apr 26, 2024 at 08:51:20AM -0500, Roth, Michael via groups.io wrote:
> > For the most part, OVMF will clear the encryption bit for MMIO regions,
> > but there is currently one known exception during SEC when the APIC
> > base address is accessed via MMIO with the encryption bit set for
> > SEV-ES/SEV-SNP guests. In the case of SEV-SNP, this requires special
> > handling on the hypervisor side which may not be available in the
> > future[1], so make the necessary changes in the SEC-configured page
> > table to clear the encryption bit for 4K region containing the APIC
> > base address.
> >
> > Since CpuPageTableLib is used to handle the splitting, some additional
> > care must be taken to clear the C-bit in all non-leaf PTEs since the
> > library expects that to be the case. Add handling for that when setting
> > up the SEC page table.
>
> Tom just noticed another spot where a non-leaf C-bit needs to be cleared
> (the one mapping the GHCB page). It doesn't affect patch functionality
> but should be included for completeness of this change, so will send a
> quick v3 with this addressed.
>
> -Mike
>

While at it, could you please fix your email setup and use 8bit
transfer encoding instead of quoted printable? Also, please put me on
cc so I don't have to apply the garbled groups.io copy.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118343): https://edk2.groups.io/g/devel/message/118343
Mute This Topic: https://groups.io/mt/105750506/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 2/7] OvmfPkg: Add the way of HOBs in QemuFwCfgLibMmio

[Ard Biesheuvel]

On Thu, 25 Apr 2024 at 14:13, Chao Li  wrote:
>
> Added the HOB methods to load and store the QEMU firmware configure
> address, data address and DMA address, which are not enabled during the
> DXE stage.
>
> Build-tested only (with "ArmVirtQemu.dsc and RiscVVirtQemu.dsc").
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
>
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Gerd Hoffmann 
> Cc: Leif Lindholm 
> Cc: Sami Mujawar 
> Cc: Sunil V L 
> Cc: Andrei Warkentin 
> Signed-off-by: Chao Li 
> ---
>  .../Library/QemuFwCfgLib/QemuFwCfgLibMmio.c   | 81 +++--
>  .../Library/QemuFwCfgLib/QemuFwCfgLibMmio.inf |  1 +
>  .../QemuFwCfgLib/QemuFwCfgLibMmioInternal.h   | 74 +++
>  .../Library/QemuFwCfgLib/QemuFwCfgMmioDxe.c   | 91 ---
>  4 files changed, 226 insertions(+), 21 deletions(-)
>
> diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMmio.c 
> b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMmio.c
> index dc949c8e26..b5dbc5e4b5 100644
> --- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMmio.c
> +++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMmio.c
> @@ -8,11 +8,16 @@
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  **/
>
> +#include 
>  #include 
>
> +#include 
> +#include 
> +
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -21,6 +26,62 @@
>
>  #include "QemuFwCfgLibMmioInternal.h"
>
> +EFI_GUID  mFwCfgResourceGuid = FW_CONFIG_RESOURCE_HOB_GUID;
> +
> +/**
> +  Build firmware configure resource address HOB.
> +
> +  @param[in]   FwCfgResource  A pointer to firmware configure resource.
> +
> +  @retval  NULL
> +**/
> +VOID
> +QemuBuildFwCfgResourceHob (
> +  IN QEMU_FW_CFG_RESOURCE  *FwCfgResource
> +  )
> +{
> +  UINT64  Data64;
> +
> +  Data64 = (UINT64)(UINTN)FwCfgResource;
> +
> +  BuildGuidDataHob (
> +,
> +(VOID *),

This looks wrong: why are you taking the address of the stack variable
rather than the address of the resource descriptor?

> +sizeof (QEMU_FW_CFG_RESOURCE)
> +);
> +}
> +
> +/**
> +  Get firmware configure resource in HOB.
> +
> +  @param VOID
> +
> +  @retval  FwCfgResourceThe firmware configure resouce in HOB.

resource

> +   NULL The firmware configure resouce not found.
> +**/
> +QEMU_FW_CFG_RESOURCE *
> +QemuGetFwCfgResourceHob (
> +  VOID
> +  )
> +{
> +  EFI_HOB_GUID_TYPE *GuidHob;
> +  VOID  *DataInHob;
> +  QEMU_FW_CFG_RESOURCE  *FwCfgResource;
> +
> +  GuidHob   = NULL;
> +  DataInHob = NULL;
> +
> +  GuidHob = GetFirstGuidHob ();

Please define this GUID in the package .DEC file and add it to the
[Guids] section in the .INF so that you can refer to its name
directly.

> +  if (GuidHob == NULL) {
> +return NULL;
> +  }
> +
> +  DataInHob = GET_GUID_HOB_DATA (GuidHob);
> +  FwCfgResource = (QEMU_FW_CFG_RESOURCE *)(*(UINTN *)DataInHob);
> +
> +  return FwCfgResource;
> +}
> +
>  /**
>Returns a boolean indicating if the firmware configuration interface
>is available or not.
> @@ -37,7 +98,7 @@ QemuFwCfgIsAvailable (
>VOID
>)
>  {
> -  return (BOOLEAN)(mFwCfgSelectorAddress != 0 && mFwCfgDataAddress != 0);
> +  return (BOOLEAN)(QemuGetFwCfgSelectorAddress () != 0 && 
> QemuGetFwCfgDataAddress () != 0);
>  }
>
>  /**
> @@ -56,7 +117,7 @@ QemuFwCfgSelectItem (
>)
>  {
>if (QemuFwCfgIsAvailable ()) {
> -MmioWrite16 (mFwCfgSelectorAddress, SwapBytes16 ((UINT16)QemuFwCfgItem));
> +MmioWrite16 (QemuGetFwCfgSelectorAddress (), SwapBytes16 
> ((UINT16)QemuFwCfgItem));
>}
>  }
>
> @@ -86,30 +147,30 @@ MmioReadBytes (
>
>   #if defined (MDE_CPU_AARCH64) || defined (MDE_CPU_RISCV64) || defined 
> (MDE_CPU_LOONGARCH64)
>while (Ptr < End) {
> -*(UINT64 *)Ptr = MmioRead64 (mFwCfgDataAddress);
> +*(UINT64 *)Ptr = MmioRead64 (QemuGetFwCfgDataAddress ());
>  Ptr   += 8;
>}
>
>if (Left & 4) {
> -*(UINT32 *)Ptr = MmioRead32 (mFwCfgDataAddress);
> +*(UINT32 *)Ptr = MmioRead32 (QemuGetFwCfgDataAddress ());
>  Ptr   += 4;
>}
>
>   #else
>while (Ptr < End) {
> -*(UINT32 *)Ptr = MmioRead32 (mFwCfgDataAddress);
> +*(UINT32 *)Ptr = MmioRead32 (QemuGetFwCfgDataAddress ());
>  Ptr   += 4;
>}
>
>   #endif
>
>if (Left & 2) {
> -*(UINT16 *)Ptr = MmioRead16 (mFwCfgDataAddress);
> +*(UINT16 *)Ptr = MmioRead16 (QemuGetFwCfgDataAddress ());
>  Ptr   += 2;
>}
>
>if (Left & 1) {

Re: [edk2-devel] [PATCH v3 1/7] OvmfPkg: Separate QemuFwCfgLibMmio.c into two files

[Ard Biesheuvel]

On Thu, 25 Apr 2024 at 14:13, Chao Li  wrote:
>
> Separate QemuFwCfgLibMmio.c into two files named QemuFwCfgLibMmio.c and
> QemuFwCfgLibMmioDxe.c, added a new header named
> QemuFwCfgLibMmioInternal.h for MMIO version.
>
> Build-tested only (with "ArmVirtQemu.dsc and RiscVVirtQemu.dsc").
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
>
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Gerd Hoffmann 
> Cc: Leif Lindholm 
> Cc: Sami Mujawar 
> Cc: Sunil V L 
> Cc: Andrei Warkentin 
> Signed-off-by: Chao Li 
> ---
>  .../Library/QemuFwCfgLib/QemuFwCfgLibMmio.c   | 194 +-
>  .../Library/QemuFwCfgLib/QemuFwCfgLibMmio.inf |   4 +-
>  .../QemuFwCfgLib/QemuFwCfgLibMmioInternal.h   | 179 
>  .../Library/QemuFwCfgLib/QemuFwCfgMmioDxe.c   | 153 ++
>  4 files changed, 340 insertions(+), 190 deletions(-)
>  create mode 100644 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMmioInternal.h
>  create mode 100644 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgMmioDxe.c
>
> diff --git a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMmio.c 
> b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMmio.c
> index 115a210759..dc949c8e26 100644
> --- a/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMmio.c
> +++ b/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMmio.c
> @@ -1,10 +1,9 @@
>  /** @file
>
> -  Stateful and implicitly initialized fw_cfg library implementation.
> -
>Copyright (C) 2013 - 2014, Red Hat, Inc.
>Copyright (c) 2011 - 2013, Intel Corporation. All rights reserved.
>(C) Copyright 2021 Hewlett Packard Enterprise Development LP
> +  Copyright (c) 2024 Loongson Technology Corporation Limited. All rights 
> reserved.
>

Please only claim copyright for code that you wrote, not for code that
you just moved between files.

>SPDX-License-Identifier: BSD-2-Clause-Patent
>  **/
> @@ -20,63 +19,7 @@
>
>  #include 
>
> -STATIC UINTN  mFwCfgSelectorAddress;
> -STATIC UINTN  mFwCfgDataAddress;
> -STATIC UINTN  mFwCfgDmaAddress;
> -
> -/**
> -  Reads firmware configuration bytes into a buffer
> -
> -  @param[in] SizeSize in bytes to read
> -  @param[in] Buffer  Buffer to store data into  (OPTIONAL if Size is 0)
> -
> -**/
> -typedef
> -VOID(EFIAPI READ_BYTES_FUNCTION)(
> -  IN UINTN Size,
> -  IN VOID  *Buffer OPTIONAL
> -  );
> -
> -/**
> -  Writes bytes from a buffer to firmware configuration
> -
> -  @param[in] SizeSize in bytes to write
> -  @param[in] Buffer  Buffer to transfer data from (OPTIONAL if Size is 0)
> -
> -**/
> -typedef
> -VOID(EFIAPI WRITE_BYTES_FUNCTION)(
> -  IN UINTN Size,
> -  IN VOID  *Buffer OPTIONAL
> -  );
> -
> -/**
> -  Skips bytes in firmware configuration
> -
> -  @param[in] Size  Size in bytes to skip
> -
> -**/
> -typedef
> -VOID(EFIAPI SKIP_BYTES_FUNCTION)(
> -  IN UINTN Size
> -  );
> -
> -//
> -// Forward declaration of the two implementations we have.
> -//
> -STATIC READ_BYTES_FUNCTION   MmioReadBytes;
> -STATIC WRITE_BYTES_FUNCTION  MmioWriteBytes;
> -STATIC SKIP_BYTES_FUNCTION   MmioSkipBytes;
> -STATIC READ_BYTES_FUNCTION   DmaReadBytes;
> -STATIC WRITE_BYTES_FUNCTION  DmaWriteBytes;
> -STATIC SKIP_BYTES_FUNCTION   DmaSkipBytes;
> -
> -//
> -// These correspond to the implementation we detect at runtime.
> -//
> -STATIC READ_BYTES_FUNCTION   *InternalQemuFwCfgReadBytes  = MmioReadBytes;
> -STATIC WRITE_BYTES_FUNCTION  *InternalQemuFwCfgWriteBytes = MmioWriteBytes;
> -STATIC SKIP_BYTES_FUNCTION   *InternalQemuFwCfgSkipBytes  = MmioSkipBytes;
> +#include "QemuFwCfgLibMmioInternal.h"
>
>  /**
>Returns a boolean indicating if the firmware configuration interface
> @@ -97,126 +40,6 @@ QemuFwCfgIsAvailable (
>return (BOOLEAN)(mFwCfgSelectorAddress != 0 && mFwCfgDataAddress != 0);
>  }
>
> -RETURN_STATUS
> -EFIAPI
> -QemuFwCfgInitialize (
> -  VOID
> -  )
> -{
> -  EFI_STATUS   Status;
> -  FDT_CLIENT_PROTOCOL  *FdtClient;
> -  CONST UINT64 *Reg;
> -  UINT32   RegSize;
> -  UINTNAddressCells, SizeCells;
> -  UINT64   FwCfgSelectorAddress;
> -  UINT64   FwCfgSelectorSize;
> -  UINT64   FwCfgDataAddress;
> -  UINT64   FwCfgDataSize;
> -  UINT64   FwCfgDmaAddress;
> -  UINT64   FwCfgDmaSize;
> -
> -  Status = gBS->LocateProtocol (
> -  ,
> -  NULL,
> -  (VOID **)
> -  );
> -  ASSERT_EFI_ERROR (Status);
> -
> -  Status = FdtClient->FindCompatibleNodeReg (
> -FdtClient,
> -"qemu,f

Re: [edk2-devel] [PATCH v2 2/7] OvmfPkg: Add the way of HOBs in QemuFwCfgLibMmio

[Ard Biesheuvel]

On Thu, 25 Apr 2024 at 10:10, Chao Li  wrote:
>
> Hi Gerd,
>
>
> Thanks,
> Chao
> On 2024/4/25 15:40, Gerd Hoffmann wrote:
>
>   Hi,
>
> +EFI_GUID  mFwCfgSelectorAddressGuid = FW_CONFIG_SELECTOR_ADDRESS_HOB_GUID;
> +EFI_GUID  mFwCfgDataAddressGuid = FW_CONFIG_DATA_ADDRESS_HOB_GUID;
> +EFI_GUID  mFwCfgDmaAddressGuid  = FW_CONFIG_DMA_ADDRESS_HOB_GUID;
>
> Oh.  I assumed that would be obvious (because it's common practice for
> HOBs), but I was thinking about a single HOB containing a struct with
> all three values instead of a separate HOB for each value.
>
> If uses a single HOB, it must define a structure in this library, and it may 
> be more complicated to build and parse the HOB.
>

Please use a single HOB, and avoid global variables in PEI (PEI
modules may execute in place from read-only NOR flash, so global
variables are not allowed in PEI)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118280): https://edk2.groups.io/g/devel/message/118280
Mute This Topic: https://groups.io/mt/105724969/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in confidential guests

[Ard Biesheuvel]

On Wed, 24 Apr 2024 at 18:36, Yao, Jiewen  wrote:
>
> Thanks Ard.
>
> I have submitted https://github.com/tianocore/edk2/pull/5595 3 hours ago.
> But it seems the CI stops working...
>

OK, I have dropped my PR.



>
>
> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Thursday, April 25, 2024 12:27 AM
> > To: Yao, Jiewen 
> > Cc: Gerd Hoffmann ; devel@edk2.groups.io; Oliver Steffen
> > ; Ard Biesheuvel ; Srikanth
> > Aithal 
> > Subject: Re: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in
> > confidential guests
> >
> > On Wed, 24 Apr 2024 at 08:45, Yao, Jiewen  wrote:
> > >
> > > Reviewed-by: Jiewen Yao 
> > >
> >
> > Thanks, I've queued this up.
> >
> >
> > > > -Original Message-
> > > > From: Gerd Hoffmann 
> > > > Sent: Wednesday, April 24, 2024 2:00 PM
> > > > To: devel@edk2.groups.io
> > > > Cc: Oliver Steffen ; Gerd Hoffmann
> > > > ; Ard Biesheuvel ; Yao,
> > Jiewen
> > > > ; Srikanth Aithal 
> > > > Subject: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in
> > confidential
> > > > guests
> > > >
> > > > The VirtHstiDxe does not work in confidential guests.  There also isn't
> > > > anything we can reasonably test, neither flash storage nor SMM mode will
> > > > be used in that case.  So just skip driver load when running in a
> > > > confidential guest.
> > > >
> > > > Cc: Ard Biesheuvel 
> > > > Cc: Jiewen Yao 
> > > > Fixes: 506740982bba ("OvmfPkg/VirtHstiDxe: add code flash check")
> > > > Signed-off-by: Gerd Hoffmann 
> > > > Tested-by: Srikanth Aithal 
> > > > ---
> > > >  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf | 1 +
> > > >  OvmfPkg/VirtHstiDxe/VirtHstiDxe.c   | 6 ++
> > > >  2 files changed, 7 insertions(+)
> > > >
> > > > diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > > > b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > > > index 9514933011e8..b5c237288766 100644
> > > > --- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > > > +++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > > > @@ -49,6 +49,7 @@ [FeaturePcd]
> > > >gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> > > >
> > > >  [Pcd]
> > > > +  gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr
> > > >gUefiOvmfPkgTokenSpaceGuid.PcdBfvBase
> > > >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase
> > > >
> > > > diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > > > b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > > > index b6e53a1219d1..efaff0d1f3cb 100644
> > > > --- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > > > +++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > > > @@ -17,6 +17,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  #include 
> > > >
> > > >  #include 
> > > > @@ -140,6 +141,11 @@ VirtHstiDxeEntrypoint (
> > > >EFI_STATUS   Status;
> > > >EFI_EVENTEvent;
> > > >
> > > > +  if (PcdGet64 (PcdConfidentialComputingGuestAttr)) {
> > > > +DEBUG ((DEBUG_INFO, "%a: confidential guest\n", __func__));
> > > > +return EFI_UNSUPPORTED;
> > > > +  }
> > > > +
> > > >DevId = VirtHstiGetHostBridgeDevId ();
> > > >switch (DevId) {
> > > >  case INTEL_82441_DEVICE_ID:
> > > > --
> > > > 2.44.0
> > >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118225): https://edk2.groups.io/g/devel/message/118225
Mute This Topic: https://groups.io/mt/105705705/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] OvmfPkg: Harden #VC instruction emulation somewhat (CVE-2024-25742)

[Ard Biesheuvel]

On Tue, 23 Apr 2024 at 11:28, Gerd Hoffmann  wrote:
>
> On Fri, Apr 19, 2024 at 11:21:46AM -0700, Adam Dunlap wrote:
> > Ensure that when a #VC exception happens, the instruction at the
> > instruction pointer matches the instruction that is expected given the
> > error code. This is to mitigate the ahoi WeSee attack [1] that could
> > allow hypervisors to breach integrity and confidentiality of the
> > firmware by maliciously injecting interrupts. This change is a
> > translated version of a linux patch e3ef461af35a ("x86/sev: Harden #VC
> > instruction emulation somewhat")
> >
> > [1] https://ahoi-attacks.github.io/wesee/
> >
> > Cc: Borislav Petkov (AMD) 
> > Cc: Tom Lendacky 
> > Signed-off-by: Adam Dunlap 
>
> Reviewed-by: Gerd Hoffmann 
>

Thanks all, I've merged this now.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118221): https://edk2.groups.io/g/devel/message/118221
Mute This Topic: https://groups.io/mt/105623545/21656
Mute #vc:https://edk2.groups.io/g/devel/mutehashtag/vc
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in confidential guests

[Ard Biesheuvel]

On Wed, 24 Apr 2024 at 08:45, Yao, Jiewen  wrote:
>
> Reviewed-by: Jiewen Yao 
>

Thanks, I've queued this up.


> > -Original Message-
> > From: Gerd Hoffmann 
> > Sent: Wednesday, April 24, 2024 2:00 PM
> > To: devel@edk2.groups.io
> > Cc: Oliver Steffen ; Gerd Hoffmann
> > ; Ard Biesheuvel ; Yao, Jiewen
> > ; Srikanth Aithal 
> > Subject: [PATCH v4 1/1] OvmfPkg/VirtHstiDxe: do not load driver in 
> > confidential
> > guests
> >
> > The VirtHstiDxe does not work in confidential guests.  There also isn't
> > anything we can reasonably test, neither flash storage nor SMM mode will
> > be used in that case.  So just skip driver load when running in a
> > confidential guest.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Jiewen Yao 
> > Fixes: 506740982bba ("OvmfPkg/VirtHstiDxe: add code flash check")
> > Signed-off-by: Gerd Hoffmann 
> > Tested-by: Srikanth Aithal 
> > ---
> >  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf | 1 +
> >  OvmfPkg/VirtHstiDxe/VirtHstiDxe.c   | 6 ++
> >  2 files changed, 7 insertions(+)
> >
> > diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > index 9514933011e8..b5c237288766 100644
> > --- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > +++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
> > @@ -49,6 +49,7 @@ [FeaturePcd]
> >gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> >
> >  [Pcd]
> > +  gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr
> >gUefiOvmfPkgTokenSpaceGuid.PcdBfvBase
> >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase
> >
> > diff --git a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > index b6e53a1219d1..efaff0d1f3cb 100644
> > --- a/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > +++ b/OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
> > @@ -17,6 +17,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  #include 
> > @@ -140,6 +141,11 @@ VirtHstiDxeEntrypoint (
> >EFI_STATUS   Status;
> >EFI_EVENTEvent;
> >
> > +  if (PcdGet64 (PcdConfidentialComputingGuestAttr)) {
> > +DEBUG ((DEBUG_INFO, "%a: confidential guest\n", __func__));
> > +return EFI_UNSUPPORTED;
> > +  }
> > +
> >DevId = VirtHstiGetHostBridgeDevId ();
> >switch (DevId) {
> >  case INTEL_82441_DEVICE_ID:
> > --
> > 2.44.0
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118220): https://edk2.groups.io/g/devel/message/118220
Mute This Topic: https://groups.io/mt/105705705/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 0/4] Adjust the QemuFwCfgLibMmio and add PEI stage

[Ard Biesheuvel]

On Wed, 24 Apr 2024 at 13:19, Gerd Hoffmann  wrote:
>
> On Wed, Apr 24, 2024 at 09:57:50AM +0800, Chao Li wrote:
> > Hi Gerd and Ard,
> >
> > Can I submit the V2 this week? I want all OvmfPkg changes to be meged before
> > the 202405 feature freeze.
>
> Yea, go ahead, lets stick to the PCD approach, given that Ard seems to
> not have objections to that ;)
>

Apologies for my late response.

As I have mentioned before (I think?) I strongly prefer HOBs over
dynamic PCDs for values that are determined during PEI and not updated
later.

For other cases, I actually prefer protocols over PCDs because you can
depex on protocols, and not on PCDs so you never know if the dispatch
order is correct, i.e., whether PCD producers are dispatched before
PCD consumers.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118219): https://edk2.groups.io/g/devel/message/118219
Mute This Topic: https://groups.io/mt/105573103/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 0/5] OvmfPkg: Add VirtHstiDxe driver

[Ard Biesheuvel]

On Mon, 22 Apr 2024 at 12:47, Gerd Hoffmann  wrote:
>
> v3:
>  - use PcdOvmfFlashNvStorageVariableBase
>  - add reviewed-by tags
> v2:
>  - remove 'Q35' from test bits
>  - add patch with a README.md
>
> Gerd Hoffmann (3):
>   OvmfPkg/VirtHstiDxe: add varstore flash check
>   OvmfPkg/VirtHstiDxe: add code flash check
>   OvmfPkg/VirtHstiDxe: add README.md
>
> Konstantin Kostiuk (2):
>   OvmfPkg: Add VirtHstiDxe driver
>   OvmfPkg: Add VirtHstiDxe to OVMF firmware build
>

I'll take these - thanks.


>  OvmfPkg/OvmfPkgIa32.dsc |   2 +
>  OvmfPkg/OvmfPkgIa32X64.dsc  |   2 +
>  OvmfPkg/OvmfPkgX64.dsc  |   2 +
>  OvmfPkg/OvmfPkgIa32.fdf |   1 +
>  OvmfPkg/OvmfPkgIa32X64.fdf  |   1 +
>  OvmfPkg/OvmfPkgX64.fdf  |   1 +
>  OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf |  56 +
>  OvmfPkg/VirtHstiDxe/VirtHstiDxe.h   |  94 +++
>  OvmfPkg/VirtHstiDxe/Flash.c |  90 +++
>  OvmfPkg/VirtHstiDxe/QemuCommon.c|  36 ++
>  OvmfPkg/VirtHstiDxe/QemuPC.c|  38 ++
>  OvmfPkg/VirtHstiDxe/QemuQ35.c   |  71 
>  OvmfPkg/VirtHstiDxe/VirtHstiDxe.c   | 173 
>  OvmfPkg/VirtHstiDxe/README.md   |  48 
>  14 files changed, 615 insertions(+)
>  create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.inf
>  create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.h
>  create mode 100644 OvmfPkg/VirtHstiDxe/Flash.c
>  create mode 100644 OvmfPkg/VirtHstiDxe/QemuCommon.c
>  create mode 100644 OvmfPkg/VirtHstiDxe/QemuPC.c
>  create mode 100644 OvmfPkg/VirtHstiDxe/QemuQ35.c
>  create mode 100644 OvmfPkg/VirtHstiDxe/VirtHstiDxe.c
>  create mode 100644 OvmfPkg/VirtHstiDxe/README.md
>
> --
> 2.44.0
>
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118094): https://edk2.groups.io/g/devel/message/118094
Mute This Topic: https://groups.io/mt/105667070/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] ArmVirtPkg/ArmVirtQemu: always build XIP code with strict alignment

[Ard Biesheuvel via groups.io]

From: Ard Biesheuvel 

The optimization that enabled entry with MMU and caches enabled at EL1
removed the strict alignment requirement for XIP code (roughly, any code
that might execute with the MMU and caches off, which means SEC and PEI
phase modules but also *all* BASE libraries), on the basis that QEMU can
only run guest payloads at EL2 in TCG emulation, which used to ignore
alignment violations, and execution at EL1 would always occur with the
MMU enabled.

This assumption no longer holds: not only does QEMU now enforce strict
alignment for memory accesses with device semantics, there are also
cases where this code might execute at EL2 under virtualization (i.e.,
under NV2 nested virtualization) where the strict alignment is required
too.

The latter case could be optimized too, by enabling VHE and pretending
execution is occurring at EL1, which would allow the existing logic for
entry with the MMU enabled to be reused. However, this would leave
non-VHE CPUs behind.

So in summary, strict alignment needs to be enforced for any code that
may execute with the MMU off, so drop the override that sets the XIP
flags to the empty string.

Cc: Jonathan Cameron 
Cc: Richard Henderson 
Cc: Philippe Mathieu-Daud� 
Cc: Idan Horowitz 
Cc: qemu-...@nongnu.org
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirtQemu.dsc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index e48c75b5e99f..f6f78359552d 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -124,8 +124,6 @@ [LibraryClasses.common.UEFI_DRIVER]
 [BuildOptions]

 !if $(CAVIUM_ERRATUM_27456) == TRUE

   GCC:*_*_AARCH64_PP_FLAGS = -DCAVIUM_ERRATUM_27456

-!else

-  GCC:*_*_AARCH64_CC_XIPFLAGS ==

 !endif

 

 !include NetworkPkg/NetworkBuildOptions.dsc.inc

--
2.44.0.769.g3c40516874-goog



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118039): https://edk2.groups.io/g/devel/message/118039
Mute This Topic: https://groups.io/mt/105630615/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 5/6] target/arm: Do memory type alignment check when translation disabled

[Ard Biesheuvel]

On Fri, 19 Apr 2024 at 18:36, Ard Biesheuvel  wrote:
>
> On Fri, 19 Apr 2024 at 18:09, Jonathan Cameron via groups.io
>  wrote:
> >
> > On Fri, 19 Apr 2024 13:52:07 +0200
> > Gerd Hoffmann  wrote:
> >
> > >   Hi,
> > >
> > > > Gerd, any ideas?  Maybe I needs something subtly different in my
> > > > edk2 build?  I've not looked at this bit of the qemu infrastructure
> > > > before - is there a document on how that image is built?
> > >
> > > There is roms/Makefile for that.
> > >
> > > make -C roms help
> > > make -C roms efi
> > >
> > > So easiest would be to just update the edk2 submodule to what you
> > > need, then rebuild.
> > >
> > > The build is handled by the roms/edk2-build.py script,
> > > with the build configuration being in roms/edk2-build.config.
> > > That is usable outside the qemu source tree too, i.e. like this:
> > >
> > >   python3 /path/to/qemu.git/roms/edk2-build.py \
> > > --config /path/to/qemu.git/roms/edk2-build.config \
> > > --core /path/to/edk2.git \
> > > --match armvirt \
> > > --silent --no-logs
> > >
> > > That'll try to place the images build in "../pc-bios", so maybe better
> > > work with a copy of the config file where you adjust this.
> > >
> > > HTH,
> > >   Gerd
> > >
> >
> > Thanks Gerd!
> >
> > So the builds are very similar via the two method...
> > However - the QEMU build sets -D CAVIUM_ERRATUM_27456=TRUE
> >
> > And that's the difference - with that set for my other builds the alignment
> > problems go away...
> >
> > Any idea why we have that set in roms/edk2-build.config?
> > Superficially it seems rather unlikely anyone cares about thunderx1
> > (if they do we need to get them some new hardware with fresh bugs)
> > bugs now and this config file was only added last year.
> >
> >
> > However, the last comment in Ard's commit message below seems
> > highly likely to be relevant!
> >
> > Chasing through Ard's patch it has the side effect of dropping
> > an override of a requirement for strict alignment.
> > So with out the errata
> > DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align -mgeneral-regs-only
> > is replaced with
> >  [BuildOptions]
> > +!if $(CAVIUM_ERRATUM_27456) == TRUE^M
> > +  GCC:*_*_AARCH64_PP_FLAGS = -DCAVIUM_ERRATUM_27456^M
> > +!else^M
> >GCC:*_*_AARCH64_CC_XIPFLAGS ==
> > +!endif^M
> >
> > The edk2 commit that added this was the following +CC Ard.
> >
> > Given I wasn't sure of the syntax of that file I set it
> > manually to the original value and indeed it works.
> >
> >
> > commit ec54ce1f1ab41b92782b37ae59e752fff0ef9c41
> > Author: Ard Biesheuvel 
> > Date:   Wed Jan 4 16:51:35 2023 +0100
> >
> > ArmVirtPkg/ArmVirtQemu: Avoid early ID map on ThunderX
> >
> > The early ID map used by ArmVirtQemu uses ASID scoped non-global
> > mappings, as this allows us to switch to the permanent ID map seamlessly
> > without the need for explicit TLB maintenance.
> >
> > However, this triggers a known erratum on ThunderX, which does not
> > tolerate non-global mappings that are executable at EL1, as this appears
> > to result in I-cache corruption. (Linux disables the KPTI based Meltdown
> > mitigation on ThunderX for the same reason)
> >
> > So work around this, by detecting the CPU implementor and part number,
> > and proceeding without the early ID map if a ThunderX CPU is detected.
> >
> > Note that this requires the C code to be built with strict alignment
> > again, as we may end up executing it with the MMU and caches off.
> >
> > Signed-off-by: Ard Biesheuvel 
> > Acked-by: Laszlo Ersek 
> > Tested-by: dann frazier 
> >
> > Test case is
> > qemu-system-aarch64 -M virt,virtualization=true, -m 4g -cpu cortex-a76 \
> > -bios QEMU_EFI.fd -d int
> >
> > Which gets alignment faults since:
> > https://lore.kernel.org/all/20240301204110.656742-6-richard.hender...@linaro.org/
> >
> > So my feeling here is EDK2 should either have yet another config for QEMU 
> > as a host
> > or should always set the alignment without needing to pick the CAVIUM 27456 
> > errata
> > which I suspect will get dropped soonish anyway if anyone ever cleans up
> > old errata.
> >
>
> This code was never really intended for execution

Re: [edk2-devel] [PATCH v3 5/6] target/arm: Do memory type alignment check when translation disabled

[Ard Biesheuvel]

On Fri, 19 Apr 2024 at 18:09, Jonathan Cameron via groups.io
 wrote:
>
> On Fri, 19 Apr 2024 13:52:07 +0200
> Gerd Hoffmann  wrote:
>
> >   Hi,
> >
> > > Gerd, any ideas?  Maybe I needs something subtly different in my
> > > edk2 build?  I've not looked at this bit of the qemu infrastructure
> > > before - is there a document on how that image is built?
> >
> > There is roms/Makefile for that.
> >
> > make -C roms help
> > make -C roms efi
> >
> > So easiest would be to just update the edk2 submodule to what you
> > need, then rebuild.
> >
> > The build is handled by the roms/edk2-build.py script,
> > with the build configuration being in roms/edk2-build.config.
> > That is usable outside the qemu source tree too, i.e. like this:
> >
> >   python3 /path/to/qemu.git/roms/edk2-build.py \
> > --config /path/to/qemu.git/roms/edk2-build.config \
> > --core /path/to/edk2.git \
> > --match armvirt \
> > --silent --no-logs
> >
> > That'll try to place the images build in "../pc-bios", so maybe better
> > work with a copy of the config file where you adjust this.
> >
> > HTH,
> >   Gerd
> >
>
> Thanks Gerd!
>
> So the builds are very similar via the two method...
> However - the QEMU build sets -D CAVIUM_ERRATUM_27456=TRUE
>
> And that's the difference - with that set for my other builds the alignment
> problems go away...
>
> Any idea why we have that set in roms/edk2-build.config?
> Superficially it seems rather unlikely anyone cares about thunderx1
> (if they do we need to get them some new hardware with fresh bugs)
> bugs now and this config file was only added last year.
>
>
> However, the last comment in Ard's commit message below seems
> highly likely to be relevant!
>
> Chasing through Ard's patch it has the side effect of dropping
> an override of a requirement for strict alignment.
> So with out the errata
> DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align -mgeneral-regs-only
> is replaced with
>  [BuildOptions]
> +!if $(CAVIUM_ERRATUM_27456) == TRUE^M
> +  GCC:*_*_AARCH64_PP_FLAGS = -DCAVIUM_ERRATUM_27456^M
> +!else^M
>GCC:*_*_AARCH64_CC_XIPFLAGS ==
> +!endif^M
>
> The edk2 commit that added this was the following +CC Ard.
>
> Given I wasn't sure of the syntax of that file I set it
> manually to the original value and indeed it works.
>
>
> commit ec54ce1f1ab41b92782b37ae59e752fff0ef9c41
> Author: Ard Biesheuvel 
> Date:   Wed Jan 4 16:51:35 2023 +0100
>
> ArmVirtPkg/ArmVirtQemu: Avoid early ID map on ThunderX
>
> The early ID map used by ArmVirtQemu uses ASID scoped non-global
> mappings, as this allows us to switch to the permanent ID map seamlessly
> without the need for explicit TLB maintenance.
>
> However, this triggers a known erratum on ThunderX, which does not
> tolerate non-global mappings that are executable at EL1, as this appears
> to result in I-cache corruption. (Linux disables the KPTI based Meltdown
> mitigation on ThunderX for the same reason)
>
> So work around this, by detecting the CPU implementor and part number,
> and proceeding without the early ID map if a ThunderX CPU is detected.
>
> Note that this requires the C code to be built with strict alignment
> again, as we may end up executing it with the MMU and caches off.
>
> Signed-off-by: Ard Biesheuvel 
> Acked-by: Laszlo Ersek 
> Tested-by: dann frazier 
>
> Test case is
> qemu-system-aarch64 -M virt,virtualization=true, -m 4g -cpu cortex-a76 \
> -bios QEMU_EFI.fd -d int
>
> Which gets alignment faults since:
> https://lore.kernel.org/all/20240301204110.656742-6-richard.hender...@linaro.org/
>
> So my feeling here is EDK2 should either have yet another config for QEMU as 
> a host
> or should always set the alignment without needing to pick the CAVIUM 27456 
> errata
> which I suspect will get dropped soonish anyway if anyone ever cleans up
> old errata.
>

This code was never really intended for execution at EL2, but it
happened to work, partially because TCG's lack of strict alignment
checking when the MMU is off.

Those assumptions no longer hold, so yes, let's get this fixed properly.

Given VHE and nested virt (which will likely imply VHE in practice), I
would like to extend this functionality (i.e., the use of preliminary
page tables in NOR flash) to EL2 as well, but with VHE enabled. This
means we can still elide TLB maintenance (and BBM checks) by using
different ASIDs, and otherwise, fall back to entering with the MMU off
if VHE is not available. In that case, we should enforce strict
alignment too, so 

Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC files

[Ard Biesheuvel]

On Fri, 19 Apr 2024 at 15:00, Chang, Abner  wrote:
>
> [AMD Official Use Only - General]
>
> I guess my RB misled contributors thought the patch is good to merge. 
> However, I was thinking Eric's team should give the final RB after the 
> validation as they are the maintainers for the subordinate VanGoghBoard 
> platform. Suppose the impacted packages should be built successfully with the 
> patches applied, as this is considered the base requirement of the code 
> change. Nevertheless, the special build sauce for VanGoghBoard may be not 
> easy for contributors to verify the build.
>
> Eric, I have few suggestions for this failure, for the short term, you can 
> commit another change to remove this change, as the build failure has impacts 
> on our customer support. You can decide to recover this or not depends on 
> your business requirement.

Keeping edk2-platforms synced with edk2 is already complicated enough.
So I object to changes to retain compatibility with downstream forks
of EDK2. Surely, you are not telling your customers to use EDK202208
with whatever the top-of-tree of edk2-platforms is at any given
moment?

In any case, if upstream edk2 is important to you, please fix the
current situation in edk2 first. If it is not important to you, I
don't see a reason to revert anything, and you can fix it in your
downstream.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118029): https://edk2.groups.io/g/devel/message/118029
Mute This Topic: https://groups.io/mt/105537744/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC files

[Ard Biesheuvel]

On Fri, 19 Apr 2024 at 11:06, Xing, Eric  wrote:
>
> [AMD Official Use Only - General]
>
> Hi Ard,
>
> This checkin causes VanGoghBoard build fail now. Would you help revert it?
> I will merge PATCH to VanGoghBoard after the code review process done and 
> code changes are verified pass on real board.
>

Please provide a solution instead that makes upstream edk2 work with
upstream edk2-platforms.

For downstream builds, you can combine the old EDK2_202208 with an
older checkout of edk2-platforms, right?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118015): https://edk2.groups.io/g/devel/message/118015
Mute This Topic: https://groups.io/mt/105537744/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] Platform/AMD: Add AmdSvsmLib to required DSC files

[Ard Biesheuvel]

On Fri, 19 Apr 2024 at 10:10, Xing, Eric via groups.io
 wrote:
>
> [AMD Official Use Only - General]
>
>
> Thanks Duke.
>
>
>
> Hi Thomas,
>
>
>
> PATCH1/2 still cannot be checked in because today’s VanGoghBoard is based off 
> EDK2_202208. Please hold on this PATCH check in.
>
>

Apologies, but I already merged this patch two days ago.

edk2-platforms should build in combination with edk2. If your platform
has other dependencies that are not in edk2, edk2-platforms or
edk2-non-osi, please host and maintain the platform elsewhere.

I also noticed that
Platform/AMD/VanGoghBoard/ChachaniBoardPkg/build.sh requires that the
various repo checkouts are inside the workspace, but the BaseTools
don't actually require this. Personally, I use

$HOME/edk2-workspace for the builds

$HOME/edk2
$HOME/edk2-platforms
$HOME/edk2-non-osi

for the checkouts, which keeps things separate, and allow me to wipe
the workspace entirely without touching the repos.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118010): https://edk2.groups.io/g/devel/message/118010
Mute This Topic: https://groups.io/mt/105537744/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] MdeModulePkg: Fix MAT SplitRecord() Logic introduce one bug and will cause SUT reset when boot to windows

[Ard Biesheuvel]

Hello Dandan,

On Thu, 18 Apr 2024 at 15:03, Dandan Bi  wrote:
>
> Hi Taylor,
>
>
>
> >>Extra EfiRuntimeServicesCode regions which aren't part of loaded runtime 
> >>images.
>
> This may be related to the original size of EfiRuntimeServicesCode in memory 
> map, and the size can be configured via PcdPlatformEfiRtCodeMemorySize.
>

That PCD does not exist in EDK2. Can you explain what it does on your platform?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117990): https://edk2.groups.io/g/devel/message/117990
Mute This Topic: https://groups.io/mt/105477564/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg: Harden #VC instruction emulation somewhat (CVE-2024-25742)

[Ard Biesheuvel]

(cc Jiewen)

Please cc the OVMF maintainers when you send edk2 patches. (There is a
Maintainers file in the root of the repo)


On Wed, 17 Apr 2024 at 18:54, Adam Dunlap via groups.io
 wrote:
>
> Ensure that when a #VC exception happens, the instruction at the
> instruction pointer matches the instruction that is expected given the
> error code. This is to mitigate the ahoi WeSee attack [1] that could
> allow hypervisors to breach integrity and confidentiality of the
> firmware by maliciously injecting interrupts. This change is a
> translated version of a linux patch e3ef461af35a ("x86/sev: Harden #VC
> instruction emulation somewhat")
>
> [1] https://ahoi-attacks.github.io/wesee/
>
> Cc: Borislav Petkov (AMD) 
> Cc: Tom Lendacky 
> Signed-off-by: Adam Dunlap 
> ---
>  OvmfPkg/Library/CcExitLib/CcExitVcHandler.c | 171 ++--
>  1 file changed, 160 insertions(+), 11 deletions(-)
>
> diff --git a/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c 
> b/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
> index 0fc30f7bc4..bd3e9f304a 100644
> --- a/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
> +++ b/OvmfPkg/Library/CcExitLib/CcExitVcHandler.c
> @@ -532,8 +532,6 @@ MwaitExit (
>IN CC_INSTRUCTION_DATA *InstructionData
>)
>  {
> -  CcDecodeModRm (Regs, InstructionData);
> -
>Ghcb->SaveArea.Rax = Regs->Rax;
>CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
>Ghcb->SaveArea.Rcx = Regs->Rcx;
> @@ -564,8 +562,6 @@ MonitorExit (
>IN CC_INSTRUCTION_DATA *InstructionData
>)
>  {
> -  CcDecodeModRm (Regs, InstructionData);
> -
>Ghcb->SaveArea.Rax = Regs->Rax;  // Identity mapped, so VA = PA
>CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
>Ghcb->SaveArea.Rcx = Regs->Rcx;
> @@ -670,8 +666,6 @@ VmmCallExit (
>  {
>UINT64  Status;
>
> -  CcDecodeModRm (Regs, InstructionData);
> -
>Ghcb->SaveArea.Rax = Regs->Rax;
>CcExitVmgSetOffsetValid (Ghcb, GhcbRax);
>Ghcb->SaveArea.Cpl = (UINT8)(Regs->Cs & 0x3);
> @@ -1603,8 +1597,6 @@ Dr7WriteExit (
>Ext   = >Ext;
>SevEsData = (SEV_ES_PER_CPU_DATA *)(Ghcb + 1);
>
> -  CcDecodeModRm (Regs, InstructionData);
> -
>//
>// MOV DRn always treats MOD == 3 no matter how encoded
>//
> @@ -1655,8 +1647,6 @@ Dr7ReadExit (
>Ext   = >Ext;
>SevEsData = (SEV_ES_PER_CPU_DATA *)(Ghcb + 1);
>
> -  CcDecodeModRm (Regs, InstructionData);
> -
>//
>// MOV DRn always treats MOD == 3 no matter how encoded
>//
> @@ -1671,6 +1661,160 @@ Dr7ReadExit (
>return 0;
>  }
>
> +/**
> +  Check that the opcode matches the exit code for a #VC.
> +
> +  Each exit code should only be raised while executing certain instructions.
> +  Verify that rIP points to a correct instruction based on the exit code to
> +  protect against maliciously injected interrupts via the hypervisor. If it 
> does
> +  not, report an unsupported event to the hypervisor.
> +
> +  Decodes the ModRm byte into InstructionData if necessary.
> +
> +  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
> Communication
> +   Block
> +  @param[in, out] Regs x64 processor context
> +  @param[in, out] InstructionData  Instruction parsing context
> +  @param[in]  ExitCode Exit code given by #VC.
> +
> +  @retval 0No problems detected.
> +  @return  New exception value to propagate
> +
> +
> +**/
> +STATIC
> +UINT64
> +VcCheckOpcodeBytes (
> +  IN OUT GHCB*Ghcb,
> +  IN OUT EFI_SYSTEM_CONTEXT_X64  *Regs,
> +  IN OUT CC_INSTRUCTION_DATA *InstructionData,
> +  IN UINT64  ExitCode
> +  )
> +{
> +  UINT8  OpCode;
> +
> +  //
> +  // Expected opcodes are either 1 or 2 bytes. If they are 2 bytes, they 
> always
> +  // start with TWO_BYTE_OPCODE_ESCAPE (0x0f), so skip over that.
> +  //
> +  OpCode = *(InstructionData->OpCodes);
> +  if (OpCode == TWO_BYTE_OPCODE_ESCAPE) {
> +OpCode = *(InstructionData->OpCodes + 1);
> +  }
> +
> +  switch (ExitCode) {
> +case SVM_EXIT_IOIO_PROT:
> +case SVM_EXIT_NPF:
> +  /* handled separately */
> +  return 0;
> +
> +case SVM_EXIT_CPUID:
> +  if (OpCode == 0xa2) {
> +return 0;
> +  }
> +
> +  break;
> +
> +case SVM_EXIT_INVD:
> +  break;
> +
> +case SVM_EXIT_MONITOR:
> +  CcDecodeModRm (Regs, InstructionData);
> +
> +  if ((OpCode == 0x01) && (InstructionData->ModRm.Uint8 == 0xc8)) {
> +return 0;
> +  }
> +
> +  break;
> +
> +case SVM_EXIT_MWAIT:
> +  CcDecodeModRm (Regs, InstructionData);
> +
> +  if ((OpCode == 0x01) && (InstructionData->ModRm.Uint8 == 0xc9)) {
> +return 0;
> +  }
> +
> +  break;
> +
> +case SVM_EXIT_MSR:
> +  /* RDMSR */
> +  if ((OpCode == 0x32) ||
> +  /* WRMSR */
> +  (OpCode == 0x30))
> +  {
> +return 0;
> +  }
> +
> +  break;
> +
> +case SVM_EXIT_RDPMC:
> +  if (OpCode == 0x33) 

Re: [edk2-devel] [PATCH v1] MdeModulePkg: Fixup MAT Attributes After Splitting EFI Memory Map

[Ard Biesheuvel]

On Wed, 17 Apr 2024 at 16:34, Taylor Beebe  wrote:
>
>
> On 4/17/2024 7:09 AM, Oliver Smith-Denny wrote:
> > On 4/17/2024 7:05 AM, Taylor Beebe wrote:
> >>
> >> On 4/17/2024 6:40 AM, Oliver Smith-Denny wrote:
> >>> Aside from this, I wonder if we can be more aspirational here. These
> >>> EfiRuntimeServicesCode regions without attributes set are, if I am
> >>> understanding correctly, from loaded images.
> >> These EfiRuntimeServicesCode regions without attributes set are
> >> not part of loaded image memory. I think that's what you meant but
> >> wanted to clarify.
> >
> > Are these regions without attributes from image sections that have
> > been padded to RUNTIME_PAGE_ALLOCATION_GRANULARITY, i.e. they are
> > the pads? Or are we saying we don't know what these regions are
> > at this point? It is true in theory someone could just allocate
> > an EfiRuntimeServicesCode section.
> Good question -- I had not considered the extra padding applied
> to these allocations. It could be either. The memory map returned
> via GetMemoryMap() will merge descriptors together based on type
> so it's possible to mistake an unrelated EfiRuntimeServicesCode
> allocation with padding applied to a runtime image memory
> allocation if they are contiguous.
>

An arbitary Linux/arm64 on edk2 VM boot gives me

memory map:
...
0x7c77-0x7c7e [Runtime Code|RUN|  |  |  |  |  |  |  |  ]
0x7c7f-0x7c95 [Runtime Data|RUN|  |  |  |  |  |  |  |  ]
0x7c96-0x7c9a [Runtime Code|RUN|  |  |  |  |  |  |  |  ]
0x7c9b-0x7ca4 [Runtime Data|RUN|  |  |  |  |  |  |  |  ]
0x7ca5-0x7cb3 [Runtime Code|RUN|  |  |  |  |  |  |  |  ]
0x7cb4-0x7cb42fff [Conventional|   |  |  |  |  |  |  |  |  ]
0x7cb43000-0x7cb43fff [Loader Data |   |  |  |  |  |  |  |  |  ]
0x7cb44000-0x7ecd5fff [Conventional|   |  |  |  |  |  |  |  |  ]
0x7ecd6000-0x7fa37fff [Boot Data   |   |  |  |  |  |  |  |  |  ]
0x7fa38000-0x7faa0fff [Conventional|   |  |  |  |  |  |  |  |  ]
0x7faa1000-0x7fe1 [Boot Code   |   |  |  |  |  |  |  |  |  ]
0x7fe2-0x7fea [Runtime Code|RUN|  |  |  |  |  |  |  |  ]
0x7feb-0x7feb [Conventional|   |  |  |  |  |  |  |  |  ]
0x7fec-0x7ffd [Runtime Data|RUN|  |  |  |  |  |  |  |  ]
...

MAT:
0x7c77-0x7c77 [Runtime Code|RUN|  |  |  |  |XP|  |  |  ]
0x7c78-0x7c78 [Runtime Code|RUN|  |  |  |  |  |  |  |RO]
0x7c79-0x7c7b [Runtime Code|RUN|  |  |  |  |XP|  |  |  ]
0x7c7c-0x7c7c [Runtime Code|RUN|  |  |  |  |  |  |  |RO]
0x7c7d-0x7c7e [Runtime Code|RUN|  |  |  |  |XP|  |  |  ]
0x7c7f-0x7c95 [Runtime Data|RUN|  |  |  |  |XP|  |  |  ]
0x7c96-0x7c96 [Runtime Code|RUN|  |  |  |  |XP|  |  |  ]
0x7c97-0x7c97 [Runtime Code|RUN|  |  |  |  |  |  |  |RO]
0x7c98-0x7c9a [Runtime Code|RUN|  |  |  |  |XP|  |  |  ]
0x7c9b-0x7ca4 [Runtime Data|RUN|  |  |  |  |XP|  |  |  ]
0x7ca5-0x7ca5 [Runtime Code|RUN|  |  |  |  |XP|  |  |  ]
0x7ca6-0x7ca6 [Runtime Code|RUN|  |  |  |  |  |  |  |RO]
0x7ca7-0x7caa [Runtime Code|RUN|  |  |  |  |XP|  |  |  ]
0x7cab-0x7cab [Runtime Code|RUN|  |  |  |  |  |  |  |RO]
0x7cac-0x7caf [Runtime Code|RUN|  |  |  |  |XP|  |  |  ]
0x7cb0-0x7cb0 [Runtime Code|RUN|  |  |  |  |  |  |  |RO]
0x7cb1-0x7cb3 [Runtime Code|RUN|  |  |  |  |XP|  |  |  ]
0x7fe2-0x7fe2 [Runtime Code|RUN|  |  |  |  |XP|  |  |  ]
0x7fe3-0x7fe3 [Runtime Code|RUN|  |  |  |  |  |  |  |RO]
0x7fe4-0x7fe6 [Runtime Code|RUN|  |  |  |  |XP|  |  |  ]
0x7fe7-0x7fe7 [Runtime Code|RUN|  |  |  |  |  |  |  |RO]
0x7fe8-0x7fea [Runtime Code|RUN|  |  |  |  |XP|  |  |  ]
0x7fec-0x7ffd [Runtime Data|RUN|  |  |  |  |XP|  |  |  ]

So there are far fewer entries in the memory map than in the MAT, due
to the merging. AFAICT, there are ~8 runtime DXEs here.

I imagine other Rt Code regions could easily be get merged in here as well.

The wording about describing the larger region entirely is
unfortunate: I was involved in the creation of the MAT, and this
merging was definitely not taken into account.

The MAT replaced a feature where runtime DXE images were split into
separate Rt code and date memmap entries based on the PE sections, and
this broke spectacularly due to the fact that SetVirtualAddressMap()
may reorder those regions in virtual memory, which breaks relative
references between code and data in those runtime DXE programs.

So the intent has always been to describe memory attributes at a
higher level of detail without relying on the PE/COFF header directly
(which principle went out the window with PRM but that is another
discussion)

So the purpose of the MAT is 

Re: [edk2-devel] [PATCH 0/4] OvmfPkg: Add VirtHstiDxe driver

[Ard Biesheuvel]

On Wed, 17 Apr 2024 at 10:18, Gerd Hoffmann  wrote:
>
> On Fri, Mar 22, 2024 at 03:27:31PM +0100, Gerd Hoffmann wrote:
> >
> >
> > Gerd Hoffmann (2):
> >   OvmfPkg/VirtHstiDxe: add varstore flash check
> >   OvmfPkg/VirtHstiDxe: add code flash check
> >
> > Konstantin Kostiuk (2):
> >   OvmfPkg: Add VirtHstiDxe driver
> >   OvmfPkg: Add VirtHstiDxe to OVMF firmware build
>
> Ping.  Any comments on this series?
>

Dunno. What does it do?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117917): https://edk2.groups.io/g/devel/message/117917
Mute This Topic: https://groups.io/mt/105086174/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] MdeModulePkg: Fixup MAT Attributes After Splitting EFI Memory Map

[Ard Biesheuvel]

Hi Taylor,

On Wed, 17 Apr 2024 at 04:28, Taylor Beebe  wrote:
>
> The Memory Attributes Table is generated by fetching the EFI
> memory map and splitting entries which contain loaded
> images so DATA and CODE sections have separate descriptors.
> The splitting is done via a call to SplitTable() which
> marks image DATA sections with the EFI_MEMORY_XP attribute
> and CODE sections with the EFI_MEMORY_RO attribute when
> splitting. After this process, there may still be
> EfiRuntimeServicesCode regions which did not have their
> attributes set because they are not part of loaded images.
>
> This patch updates the MAT EnforceMemoryMapAttribute logic
> to set the access attributes of runtime memory regions
> which are not part of loaded images (have not had their
> access attributes set).
>
> Cc: Liming Gao 
> Signed-off-by: Taylor Beebe 
> ---
>  MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c | 29 ++--
>  1 file changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c 
> b/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> index e9343a2c4e..1d9f935db0 100644
> --- a/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> @@ -425,8 +425,8 @@ MergeMemoryMap (
>  }
>
>  /**
> -  Enforce memory map attributes.
> -  This function will set 
> EfiRuntimeServicesData/EfiMemoryMappedIO/EfiMemoryMappedIOPortSpace to be 
> EFI_MEMORY_XP.
> +  Walk the memory map and set 
> EfiRuntimeServicesData/EfiMemoryMappedIO/EfiMemoryMappedIOPortSpace
> +  to EFI_MEMORY_XP and EfiRuntimeServicesCode to EFI_MEMORY_RO.
>
>@param  MemoryMap  A pointer to the buffer in which firmware 
> places
>   the current memory map.
> @@ -447,18 +447,19 @@ EnforceMemoryMapAttribute (
>MemoryMapEntry = MemoryMap;
>MemoryMapEnd   = (EFI_MEMORY_DESCRIPTOR *)((UINT8 *)MemoryMap + 
> MemoryMapSize);
>while ((UINTN)MemoryMapEntry < (UINTN)MemoryMapEnd) {
> -switch (MemoryMapEntry->Type) {
> -  case EfiRuntimeServicesCode:
> -// do nothing
> -break;
> -  case EfiRuntimeServicesData:
> -  case EfiMemoryMappedIO:
> -  case EfiMemoryMappedIOPortSpace:
> -MemoryMapEntry->Attribute |= EFI_MEMORY_XP;
> -break;
> -  case EfiReservedMemoryType:
> -  case EfiACPIMemoryNVS:
> -break;
> +if ((MemoryMapEntry->Attribute & EFI_MEMORY_ACCESS_MASK) == 0) {
> +  switch (MemoryMapEntry->Type) {
> +case EfiRuntimeServicesCode:
> +  MemoryMapEntry->Attribute |= EFI_MEMORY_RO;

I'm not sure this is safe. If EFI_MEMORY_RO is not set, it might be intentional.

Note that the purpose of the MAT is primarily to describe permission
attributes that are more granular than the entry itself. Originally,
we tried to split those in the memory map but that broke
SetVirtualAddressMap() so we were forced to add a second table
instead.

For entries where we lack such additional metadata, I don't think we
can make assumptions based on the type beyond mapping data and MMIO
regions XP. We have no idea how those EfiRuntimeServicesCode regions
may be used, and currently, the spec permits RWX semantics for those
if no restrictions are specified.

The spec suggests that omitting an entry from the MAT is the same as
listing it with RO|XP cleared. How RO|XP from the original entry
should be interpreted wrt to the MAT is unspecified. So I think the
only thing we can do at this point is preserve the entry if it has
RO|XP set, or just drop it otherwise.

Note that the spec also mentions that the MAT must only contain
EfiRuntimeServicesCode or EfiRuntimeServicesData entries, and it looks
like this is not being enforced either.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117895): https://edk2.groups.io/g/devel/message/117895
Mute This Topic: https://groups.io/mt/105570114/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 00/24] Provide SEV-SNP support for running under an SVSM

[Ard Biesheuvel]

(cc'ing the stewards)

On Fri, 12 Apr 2024 at 17:14, Tom Lendacky  wrote:
>
> On 4/12/24 10:05, Ard Biesheuvel wrote:
> > On Fri, 12 Apr 2024 at 16:02, Tom Lendacky  wrote:
> >>
> >> Re-pinging the list/maintainers, again. I need reviews from the
> >> maintainers on patches #2, #7, #10, #11 and #13.
> >>
> >> Once I get final approval, I'll submit the change to edk2-platforms for
> >> the new library as a reply to this series for a quick review.
> >>
> >
> > So this is MdePkg and UefiCpuPkg, right?
>
> MdePkg and UefiPayloadPkg.
>
> >
> > @Liming, Mike, Ray: please let me know if you are ok with these
>
> Ray already reviewed/acked the UefiCpuPkg patches.
>
> Looking for
> MdePkg: Liming, Mike or Zhiguang
> UefiPayloadPkg: Gua, Guo, James or Sean
>

Given the lack of objections by these maintainers, I will go ahead and
merge this series tomorrow.

> > changes, or whether there are any objections.
> >
> > I intend to merge this somewhere next week unless there are issues raised.
>
> I'll submit the edk2-platforms series (2 patches, one for Platform/AMD and
> one for Platform/Intel) on Monday, just to have out there.
>

Noted. I will merge this in two phases, and merge the [trivial]
edk2-platforms pieces in between to preserve some notion of
monotonicity  between the repos.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117867): https://edk2.groups.io/g/devel/message/117867
Mute This Topic: https://groups.io/mt/104810672/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance of vTPM and RTMR.

[Ard Biesheuvel]

On Sat, 13 Apr 2024 at 11:37, Qinkun Bao  wrote:
>
...
> >
> > I think it is a bad idea to go and apply changes all across the boot
> > software ecosystem to measure the same assets into different
> > measurement protocols. I'mm afraid it creates technical debt that will
> > come and bite us in the future.
>
> Could you shed some lights on why it creates technical debts?
>

If it is so vitally important that measurements are taken into both
the TPM PCRs and the RTMRs if both are available, can we really trust
all those boot components to do the right thing? And do we really want
to have to reason about that?

Given that the guest system firmware exposes both protocols anyway,
wouldn't it make more sense to make it the guest firmware's job to
duplicate measurements into the RTMRs and only expose the TCG protocol
to the guest OS stack?

The hybrid model of trusting the host (and using a vTPM) and not
trusting the host (and therefore relying on TDX/RTMRs) at the same
time seems a bit odd to me in any case: under which circumstances
would a guest distrust the host but still rely on the vTPM?


> >
> > Given that RTMR is a proper subset of vTPM (modulo the PCR/RTMR index
> > conversion), I feel that it should be the CoCo firmware's
> > responsibility to either:
> > - expose RTMR and not vTPM
> > - expose vTPM, and duplicate each measurement into RTMR as they are taken
> >
> > However, I understand that this is only viable for execution under the
> > UEFI boot services, and after that, the vTPM and RTMR are exposed in
> > different ways to the OS.
>
> Yes, they are exposed in different ways. In Linux, the TPM driver uses
> the mmio interface rather than the EFI service. Even if
> EFI_TCG2_PROTOCOL is not installed, the TPM as a device is still
> visible to the guest. The RTMR values are included in the TD report
> and could be extended through a TDCALL. The security concern caused by
> not measuring into every device that is available is a concern.

That does not imply that each and every component should be
responsible for taking both measurements.

> Please
> see CVE-2021-42299.
>
> >
> > Could someone explain how that piece of the puzzle is supposed to
> > work? Do we measure into RTMR after ExitBootServices()?
>
> Yes, we still measure into RTMR after ExitBootServices() [1]. One
> example is measuring container images into RTMR2 during the loading
> [2].
>

Fair enough. So keeping RTMRs and PCRs in sync after EBS() is going to
be problematic :-(


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117788): https://edk2.groups.io/g/devel/message/117788
Mute This Topic: https://groups.io/mt/105070442/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 00/24] Provide SEV-SNP support for running under an SVSM

[Ard Biesheuvel]

On Fri, 12 Apr 2024 at 16:02, Tom Lendacky  wrote:
>
> Re-pinging the list/maintainers, again. I need reviews from the
> maintainers on patches #2, #7, #10, #11 and #13.
>
> Once I get final approval, I'll submit the change to edk2-platforms for
> the new library as a reply to this series for a quick review.
>

So this is MdePkg and UefiCpuPkg, right?

@Liming, Mike, Ray: please let me know if you are ok with these
changes, or whether there are any objections.

I intend to merge this somewhere next week unless there are issues raised.

Thanks,
Ard.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117709): https://edk2.groups.io/g/devel/message/117709
Mute This Topic: https://groups.io/mt/104810672/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance of vTPM and RTMR.

[Ard Biesheuvel]

On Thu, 11 Apr 2024 at 12:29, Gerd Hoffmann  wrote:
>
> On Thu, Apr 11, 2024 at 09:56:48AM +, Yao, Jiewen wrote:
> > Please allow me to clarify what you are proposing:
> > Do you mean in vTPM case, we extend both, but we only need TCG event log, 
> > NOT CC event log?
>
> Elsewhere in this thread it was mentioned that writing both vTPM and
> RTMR events to the event log is problematic because the event log format
> has no field to specify whenever a given event was measured to vTPM or
> RTMR.
>
> If the firmware can make sure all events are measured to both vTPM and
> RTMR the need to trace them separately goes away.
>
> So, yes, in case a vTPM is present the firmware would:
>   (a) expose EFI_TCG2_PROTOCOL, measure to both vTPM + RTMR
>   (b) not expose EFI_CC_MEASUREMENT_PROTOCOL
>   (c) log measurements to TCG event log
>

A TDX attestation would require the PCR to RTMR mapping used by the
firmware in order to reconstruct the RTMR values from the TCG event
log, but that seems feasible to me.

In any case, I think it should be the guest firmware's job to abstract
away the difference.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117630): https://edk2.groups.io/g/devel/message/117630
Mute This Topic: https://groups.io/mt/105070442/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance of vTPM and RTMR.

[Ard Biesheuvel]

Hello all,

On Thu, 11 Apr 2024 at 03:20, Yao, Jiewen  wrote:
>
> Hi Dionna/Qinkun
> I am not sure if systemd is the last software in guest we need to patch to 
> support coexistence to extend the measurement.
> Are you aware of any other Linux guest software needs to be updated? Such as 
> Linux IMA (Integrity Measurement Architecture)?
>
> To move this forward.
>
> In Intel, we had discussed and we did see the potential security risk. As I 
> mentioned in the first email, "In case that any the guest component only 
> knows one of vTPM or RTMR, and only extends one of vTPM or RTMR, but the 
> other one only verifies the other, then the chain of trust is broken."
>
> At same time, we also respect that it might be a valid use case for Google.
> I would like to ask the opinion in the EDKII community, especially the OVMF 
> and CC maintainer and reviewer.
>
>
> Hi Ard Biesheuvel
> Do you think Kernel is OK with this coexistence proposal?
> Are you willing to give "reviewed-by"?
>

I think it is a bad idea to go and apply changes all across the boot
software ecosystem to measure the same assets into different
measurement protocols. I'mm afraid it creates technical debt that will
come and bite us in the future.

Given that RTMR is a proper subset of vTPM (modulo the PCR/RTMR index
conversion), I feel that it should be the CoCo firmware's
responsibility to either:
- expose RTMR and not vTPM
- expose vTPM, and duplicate each measurement into RTMR as they are taken

However, I understand that this is only viable for execution under the
UEFI boot services, and after that, the vTPM and RTMR are exposed in
different ways to the OS.

Could someone explain how that piece of the puzzle is supposed to
work? Do we measure into RTMR after ExitBootServices()?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117616): https://edk2.groups.io/g/devel/message/117616
Mute This Topic: https://groups.io/mt/105070442/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] OvmfPkg: OVMF supports USB mouses

[Ard Biesheuvel]

On Tue, 9 Apr 2024 at 13:56, Gerd Hoffmann  wrote:
>
> On Mon, Apr 08, 2024 at 08:53:10AM +0100, Phillip Tennen wrote:
> > Hi, thank you for taking a look at the patch!
> >
> > This patch can be verified to be working with this app (which was the
> > motivation for submitting this):
> > https://github.com/codyd51/uefirc/releases/tag/1.0.1.
>
> Quoting https://github.com/codyd51/uefirc:
>
> Q: Should I use this?
> A: This should not exist.
>
> Well.  This certainly one of the more interesting ways to have some fun
> and improve your rust coding skills.  But a justification to include a
> mouse driver by default which is not used by anything else?  IMHO it
> isn't.
>

Agreed.

> Note that you can load drivers from efi shell with the 'load' command,
> so there is no need to have a ovmf firmware image with the mouse drivers
> included.  You can boot into efi shell and use a startup.nsh script to
> automatically load drivers needed and start the irc app.
>

startup.nsh is ignored unless you boot into the EFI shell.

UEFI supports 'driver' entries in addition to Boot entries, which
can be programmed (using efibootmgr under Linux, for instance) to
point to a UEFI driver on the ESP that needs to be loaded at boot,
before any boot options are evaluated.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117545): https://edk2.groups.io/g/devel/message/117545
Mute This Topic: https://groups.io/mt/105365480/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/3] MdeModulePkg: ImagePropertiesRecordLib Fixes

[Ard Biesheuvel]

On Wed, 27 Mar 2024 at 20:14, Oliver Smith-Denny
 wrote:
>
> Hi Mike and Ray,
>
> I'm here to bug you again :). I have another patchset that
> unfortunately Liming has not gotten to review in a month's
> time frame with weekly pings. When I bugged you last time,
> he reviewed the next day, so something must have worked out
> there. Can you please help get this merged?
>
> Liming, do you need the community to find another member
> to help as a second MdeModulePkg maintainer? It's obviously
> a large job and you have been less responsive the past few
> months, which has slowed down getting some really
> important fixes into MdeModulePkg.
>

Yes, could we please get this merged? These are important fixes.

In case it was missed, for the series:

Reviewed-by: Ard Biesheuvel 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117231): https://edk2.groups.io/g/devel/message/117231
Mute This Topic: https://groups.io/mt/104873191/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] MdeModulePkg/AcpiTableDxe: PCD switch to avoid using ACPI reclaim memory

[Ard Biesheuvel]

Hello Aaron,

Could you describe the problem that is being solved by the ability to
use EfiAcpiMemoryNVS for ACPI tables?


On Thu, 28 Mar 2024 at 05:59, Aaron Li  wrote:
>
> Hi Liming,
>
> Currently this patch does not have a related Bugzilla.
>
> According to UEFI spec, the ACPI Tables at boot time can be contained in 
> memory of type EfiACPIReclaimMemory or EfiAcpiMemoryNVS.
> Current implementation in AcpiTableDxe only allocate memory with type 
> EfiACPIReclaimMemory by default.
> This patch provides an option method to let ACPI Tables be allocated in 
> memory with type EfiAcpiMemoryNVS controlled by PCD.
>
>
> Best,
> Aaron
>
> -Original Message-
> From: gaoliming 
> Sent: Thursday, March 28, 2024 9:15 AM
> To: Li, Aaron ; devel@edk2.groups.io
> Cc: Liu, Zhiguang ; Bi, Dandan ; 
> Liu, Yun Y ; Yao, Jiewen ; Ni, Ray 
> ; Kinney, Michael D 
> Subject: 回复: [PATCH v2 1/1] MdeModulePkg/AcpiTableDxe: PCD switch to avoid 
> using ACPI reclaim memory
>
> Aaron:
>  Is there a Bugzilla for this issue? What problem will be resolved with this
> change?
>
> Thanks
> Liming
> > -邮件原件-
> > 发件人: Aaron Li 
> > 发送时间: 2024年3月26日 15:58
> > 收件人: devel@edk2.groups.io
> > 抄送: Zhiguang Liu ; Dandan Bi
> > ; Liming Gao ; Liu Yun
> > ; Jiewen Yao ; Ray Ni
> > ; Michael D Kinney 
> > 主题: [PATCH v2 1/1] MdeModulePkg/AcpiTableDxe: PCD switch to avoid
> > using ACPI reclaim memory
> >
> > UEFI spec defined ACPI Tables at boot time can be contained in memory of
> > type EfiACPIReclaimMemory or EfiAcpiMemoryNVS, although InstallAcpiTable
> > with AcpiTableProtocol will only allocate memory with type
> > EfiACPIReclaimMemory (Except FACS).
> >
> > This patch provides an optional method controlled by PCD to avoid using
> > EfiACPIReclaimMemory, by setting the PCD PcdNoACPIReclaimMemory to
> > TRUE,
> > all ACPI allocated memory will use EfiAcpiMemoryNVS instead.
> >
> > Cc: Zhiguang Liu 
> > Cc: Dandan Bi 
> > Cc: Liming Gao 
> > Cc: Liu Yun 
> > Cc: Jiewen Yao 
> > Cc: Ray Ni 
> > Cc: Michael D Kinney 
> > Signed-off-by: Aaron Li 
> > ---
> >  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 37
> > +++-
> >  MdeModulePkg/MdeModulePkg.dec
> > |  7 
> >  MdeModulePkg/MdeModulePkg.uni
> > |  8 +
> >  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf|  1 +
> >  4 files changed, 45 insertions(+), 8 deletions(-)
> >
> > diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> > b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> > index e09bc9b704f5..080768033cfa 100644
> > --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> > +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> > @@ -340,6 +340,7 @@ ReallocateAcpiTableBuffer (
> >EFI_ACPI_TABLE_INSTANCE  TempPrivateData;
> >EFI_STATUS   Status;
> >UINT64   CurrentData;
> > +  EFI_MEMORY_TYPE  AcpiAllocateMemoryType;
> >
> >CopyMem (, AcpiTableInstance, sizeof
> > (EFI_ACPI_TABLE_INSTANCE));
> >//
> > @@ -359,6 +360,12 @@ ReallocateAcpiTableBuffer (
> >   NewMaxTableNumber * sizeof (UINT32);
> >}
> >
> > +  if (PcdGetBool (PcdNoACPIReclaimMemory)) {
> > +AcpiAllocateMemoryType = EfiACPIMemoryNVS;
> > +  } else {
> > +AcpiAllocateMemoryType = EfiACPIReclaimMemory;
> > +  }
> > +
> >if (mAcpiTableAllocType != AllocateAnyPages) {
> >  //
> >  // Allocate memory in the lower 32 bit of address range for
> > @@ -372,13 +379,13 @@ ReallocateAcpiTableBuffer (
> >  PageAddress = 0x;
> >  Status  = gBS->AllocatePages (
> >   mAcpiTableAllocType,
> > - EfiACPIReclaimMemory,
> > + AcpiAllocateMemoryType,
> >   EFI_SIZE_TO_PAGES (TotalSize),
> >   
> >   );
> >} else {
> >  Status = gBS->AllocatePool (
> > -EfiACPIReclaimMemory,
> > +AcpiAllocateMemoryType,
> >  TotalSize,
> >  (VOID **)
> >  );
> > @@ -512,6 +519,7 @@ AddTableToList (
> >EFI_PHYSICAL_ADDRESS  AllocPhysAddress;
> >UINT64Buffer64;
> >BOOLEAN   AddToRsdt;
> > +  EFI_MEMORY_TYPE   AcpiAllocateMemoryType;
> >
> >//
> >// Check for invalid input parameters
> > @@ -550,6 +558,12 @@ AddTableToList (
> >CurrentTableList->TableSize  = CurrentTableSize;
> >CurrentTableList->PoolAllocation = FALSE;
> >
> > +  if (PcdGetBool (PcdNoACPIReclaimMemory)) {
> > +AcpiAllocateMemoryType = EfiACPIMemoryNVS;
> > +  } else {
> > +AcpiAllocateMemoryType = EfiACPIReclaimMemory;
> > +  }
> > +
> >//
> >// Allocation memory type depends on the type of the table
> >//
> > @@ -585,7 +599,7 @@ AddTableToList (
> >  // such as AArch64 that allocate multiples of 64 KB
> >  //
> >

Re: [edk2-devel] [PATCH v1 1/1] ArmVirtPkg: Kvmtool: Fix ACPI/DT boot selection

[Ard Biesheuvel]

Hello Sami,

On Tue, 26 Mar 2024 at 19:07, Sami Mujawar  wrote:
>
> The Kvmtool guest firmware uses the dynamic HII
> PCD PcdForceNoAcpi to determine if ACPI tables
> or the DT must be used for booting an OS.
>
> This PcdForceNoAcpi is a BOOLEAN value that can
> be configured using the variable "ForceNoAcpi"
> specifing the gOvmfVariableGuid GUID which is
> "50BEA1E5-A2C5-46E9-9B3A-59596516B00A".
>
> However, this feature was not working as the
> PCD was not defined in the platform DSC file
> and the DEPEX section in KvmtoolPlatfomDxe.inf
> was not set correctly.
>

Understood. I do wonder whether gEfiVariableArchProtocolGuid is the
appropriate protocol here to DEPEX on. Shouldn't PcdDxe depend on this
already, and should we depend on the PCD protocol instead?

Other than that, this looks fine to me.

> Therefore, fix this issue so that the ACPI/DT
> boot selection can be done from the UEFI shell
> as shown below.
>
> 1. Check the status of the 'ForceNoAcpi' variable
>setvar ForceNoAcpi -guid
>  "50BEA1E5-A2C5-46E9-9B3A-59596516B00A"
>  -nv -bs
>
> Value 00 indicates ACPI boot
> Value 01 indicates DT boot
>
> 2. Set the boot mode to ACPI
>setvar ForceNoAcpi -guid
>  "50BEA1E5-A2C5-46E9-9B3A-59596516B00A"
>  -nv -bs =0x00
>
> 3. Set the boot mode to DT
>setvar ForceNoAcpi -guid
>  "50BEA1E5-A2C5-46E9-9B3A-59596516B00A"
>  -nv -bs =0x01
>
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Cc: Gerd Hoffmann 
> Signed-off-by: Sami Mujawar 
> ---
> The changes can be seen at:
> https://github.com/samimujawar/edk2/tree/2954_kvmtool_fix_acpi_dt_selection_v1
>
>  ArmVirtPkg/ArmVirtKvmTool.dsc| 14 ++
>  ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf |  2 +-
>  2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/ArmVirtPkg/ArmVirtKvmTool.dsc b/ArmVirtPkg/ArmVirtKvmTool.dsc
> index 
> 20da3319667900e64755272fa110d57452d1fc67..c3c27b2765b34599c7312026ce5cb9474a22c684
>  100644
> --- a/ArmVirtPkg/ArmVirtKvmTool.dsc
> +++ b/ArmVirtPkg/ArmVirtKvmTool.dsc
> @@ -189,6 +189,20 @@ [PcdsPatchableInModule.common]
>  [PcdsDynamicHii]
>
> gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|5
>
> +  #
> +  #  Dynamic Hii PCD to select ACPI/DT boot.
> +  #
> +  #   1. Check the status of the 'ForceNoAcpi' variable
> +  #  setvar ForceNoAcpi -guid "50BEA1E5-A2C5-46E9-9B3A-59596516B00A" -nv 
> -bs
> +  #Value 00 indicates ACPI boot
> +  #Value 01 indicates DT boot
> +  #   2. Set the boot mode to ACPI
> +  #  setvar ForceNoAcpi -guid "50BEA1E5-A2C5-46E9-9B3A-59596516B00A" -nv 
> -bs =0x00
> +  #   3. Set the boot mode to DT
> +  #  setvar ForceNoAcpi -guid "50BEA1E5-A2C5-46E9-9B3A-59596516B00A" -nv 
> -bs =0x01
> +  #
> +  
> gUefiOvmfPkgTokenSpaceGuid.PcdForceNoAcpi|L"ForceNoAcpi"|gOvmfVariableGuid|0x0|FALSE|NV,BS
> +
>  [PcdsDynamicDefault.common]
>gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum|0x0
>gArmTokenSpaceGuid.PcdArmArchTimerIntrNum|0x0
> diff --git a/ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf 
> b/ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf
> index 
> b0583d52058805aaeece31d7e3776ac498f101ad..508bfa60c2c2cb3f3e7456b010f4e9057437cda8
>  100644
> --- a/ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf
> +++ b/ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf
> @@ -42,4 +42,4 @@ [Pcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdForceNoAcpi
>
>  [Depex]
> -  TRUE
> +  gEfiVariableArchProtocolGuid
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117160): https://edk2.groups.io/g/devel/message/117160
Mute This Topic: https://groups.io/mt/105162199/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg: Align the SEC module within OvmfPkgX64

[Ard Biesheuvel]

On Tue, 26 Mar 2024 at 22:01, Glenn Griffin  wrote:
>
> Prior to this change the alignment of the SEC module would be 4 bytes.
> This is inconsistent with the expectations of the compiler and can lead
> to unexpected behavior.
>
> For example a modern version of clang with size optimizations enabled
> (-Oz) can break the ALIGN_POINTER macro in the SEC module.
>

...
>
> However by mapping the data section that contains mArray onto a
> 4-byte-aligned base address we violate the compiler's expectations. The
> last 4 bits of the mArray address are no longer zeroes leading to an
> ALIGN_POINTER macro that doesn't work.
>
> Cc: Ard Biesheuvel 
>
> Signed-off-by: Glenn Griffin 
> ---
>  OvmfPkg/OvmfPkgX64.fdf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> index eb3fb90cb8b6..8b60355de40b 100644
> --- a/OvmfPkg/OvmfPkgX64.fdf
> +++ b/OvmfPkg/OvmfPkgX64.fdf
> @@ -434,7 +434,7 @@ [FV.FVMAIN_COMPACT]
>
>  [Rule.Common.SEC]
>FILE SEC = $(NAMED_GUID) {
> -PE32 PE32   $(INF_OUTPUT)/$(MODULE_NAME).efi
> +PE32 PE32   Align=Auto$(INF_OUTPUT)/$(MODULE_NAME).efi
>  UI   STRING ="$(MODULE_NAME)" Optional
>  VERSION  STRING ="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
>}

Thanks Glenn. As you have mentioned to me off-list, this is the same
issue Andrew reported here

Link: https://bugzilla.tianocore.org/show_bug.cgi?id=3887

Your fix is obviously correct, and I intend to merge it unless anyone
has any concerns with this.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117140): https://edk2.groups.io/g/devel/message/117140
Mute This Topic: https://groups.io/mt/105165329/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v2 1/1] Maintainers.txt: add myself as QemuSbsa maintainer

[Ard Biesheuvel]

On Tue, 26 Mar 2024 at 14:11, Marcin Juszkiewicz
 wrote:
>
> With all changes going around sbsa-ref/QemuSbsa platform Leif suggested
> that I should become maintainer as well.
>
> My GitHub account name is "hrw".
>
> Signed-off-by: Marcin Juszkiewicz 

Welcome!

Reviewed-by: Ard Biesheuvel 

> ---
>  Maintainers.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Maintainers.txt b/Maintainers.txt
> index e57c32f16a05..ca36aa679470 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -383,8 +383,8 @@ F: Platform/Qemu/SbsaQemu/
>  F: Silicon/Qemu/SbsaQemu/
>  M: Ard Biesheuvel 
>  M: Leif Lindholm 
> +M: Marcin Juszkiewicz  [hrw]
>  R: Graeme Gregory 
> -R: Marcin Juszkiewicz 
>
>  Raspberry Pi platforms and silicon
>  F: Platform/RaspberryPi/
> --
> 2.44.0
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117111): https://edk2.groups.io/g/devel/message/117111
Mute This Topic: https://groups.io/mt/105156582/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v7 1/4] Platform/SbsaQemu: add SbsaQemuHardwareInfoLib

[Ard Biesheuvel]

On Tue, 19 Mar 2024 at 14:50, Marcin Juszkiewicz
 wrote:
>
> This library provides functions to check for hardware information.
> For now it covers CPU ones:
>
> - amount of cpu cores
> - MPIDR value for cpu core
> - NUMA node id for cpu core
>
> Values are read from TF-A using platform specific SMC calls.
>
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  3 +-
>  .../SbsaQemuHardwareInfoLib.inf  | 31 +++
>  .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h  | 17 +++-
>  .../Include/Library/SbsaQemuHardwareInfoLib.h| 45 +
>  .../SbsaQemuHardwareInfoLib.c| 96 
> 
>  5 files changed, 187 insertions(+), 5 deletions(-)
>
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 378600050df9..07cb3490f4cf 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -1,6 +1,6 @@
>  #
>  #  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -#  Copyright (c) 2019, Linaro Limited. All rights reserved.
> +#  Copyright (c) 2019-2024, Linaro Ltd. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -128,6 +128,7 @@ [LibraryClasses.common]
>
>FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
>OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> +  
> SbsaQemuHardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>
># Debug Support
>
> PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> new file mode 100644
> index ..e621c422bd40
> --- /dev/null
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> @@ -0,0 +1,31 @@
> +#/* @file
> +#
> +#  Copyright (c) 2024, Linaro Ltd. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +#*/
> +
> +[Defines]
> +  INF_VERSION= 0x0001001c
> +  BASE_NAME  = SbsaQemuHardwareInfoLib
> +  FILE_GUID  = 6454006f-6502-46e2-9be4-4bba8d4b29fb
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = ArmPlatformLib
> +

Please define a suitable library class and add it to the
Silicon/Qemu/SbsaQemu/SbsaQemu.dec, as I mentioned in the previous
round of review.

Thanks,
Ard.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116902): https://edk2.groups.io/g/devel/message/116902
Mute This Topic: https://groups.io/mt/105024010/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-non-osi 1/1] Qemu/Sbsa: update TF-A binaries to get needed SMC calls

[Ard Biesheuvel]

On Thu, 14 Mar 2024 at 15:21, Marcin Juszkiewicz
 wrote:
>
> W dniu 14.03.2024 o 15:17, Marcin Juszkiewicz via groups.io pisze:
> > We want to stop parsing DeviceTree (in EDK2) to gather hardware information.
> >
> > Instead we ask TF-A for those details using SMC calls. On real hardware
> > platform it could be asking on-board Embedded Controller.
> >
> > Hardware information (CPU, Memory) is now in SbsaQemuHardwareInfoLib 
> > together
> > with new code for handling SMC stuff. If TF-A answer to SMC call would be 
> > not
> > success then we go back to parsing DeviceTree data directly. There is no DT
> > parsing elsewhere.
> >
> > This change brings TF-A with all changes needed for it.
>
> Signed-off-by: Marcin Juszkiewicz 
>

Pushed as  476d087..0544808

Thanks,


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116894): https://edk2.groups.io/g/devel/message/116894
Mute This Topic: https://groups.io/mt/104927188/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v6 2/7] Platform/SbsaQemu: read amount of cpus during init

[Ard Biesheuvel]

On Tue, 19 Mar 2024 at 11:25, Marcin Juszkiewicz
 wrote:
>
> W dniu 15.03.2024 o 12:49, Marcin Juszkiewicz pisze:
> > W dniu 14.03.2024 o 16:13, Ard Biesheuvel pisze:
>
> >> How is it guaranteed that other components will only see the correct
> >> core count? DXE dispatch is ordered using a dependency graph, so all
> >> users of this PCD should never execute before this driver.
> >
> > SbsaQemuPlatformDxe is a DXE, right? So it is called on platform init.
> >
> > At the end of initialization it calls SbsaQemuGetCpuCount() from
> > SbsaQemuHardwareInfoLib to SET this PCD. It does not use it during
> > platform init cause it does not require this information. But calls
> > function to make sure that amount of cpus is known to whatever will be
> > called later.
> >
> > Sure, maybe SbsaQemuHardwareInfoLib should be something else (DXE,
> > Protocol or other EDK2 magic thing) but it is set of functions to be
> > called from other places of EDK2.
>
> EDK2 starts and one of the first DXE called is SbsaQemuPlatformDxe one:
>

How is this guaranteed? DXE are generally dispatched in the order in
which they appear in the FDF, but only if all DEPEX dependencies are
satisfied. DEPEXes are compiled from the DXE .inf along with all its
[recursive] library dependencies, so upstream changes could affect the
DEPEX of SbsaQemuPlatformDxe, and therefore where it appears in the
dispatch order.

None of the below is relevant, really. If you want to rely on dynamic
PCDs in DXE, the only safe way to set them is from the PEI phase.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116891): https://edk2.groups.io/g/devel/message/116891
Mute This Topic: https://groups.io/mt/104763764/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 17/26] OvmfPkg/LoongArchVirt: Add serial port hook library

[Ard Biesheuvel]

On Fri, 15 Mar 2024 at 10:49, Chao Li  wrote:
>
> Hi Gerd,
>
>
> Thanks,
> Chao
> On 2024/3/15 17:33, Gerd Hoffmann wrote:
>
> On Mon, Mar 11, 2024 at 05:39:02PM +0800, Chao Li wrote:
>
> Add a serial port hook library in LoongArchVirt named
> Fdt16550SerialProtHookLib, this library is referenced from ArmVirtPkg.
>
> LoongArch QEMU virtual machine uses register of LOONGARCH_CSR_KS1 to
> transfer serial port base addres from the PEI phase to the DXE phase.
>
> Why use LOONGARCH_CSR_KS1?  Can't you simply set PcdSerialRegisterBase?
>
> The LoongArch QEMU PEI stage runs on flash and does not allow set PCD 
> operations(memory have not enabled), so the address can only be transferred 
> through a SAVE register.
>

Then maybe use a HOB instead?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116797): https://edk2.groups.io/g/devel/message/116797
Mute This Topic: https://groups.io/mt/104859892/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel][PATCH v3 0/3] Fix Runtime Granularity Issues

[Ard Biesheuvel]

On Thu, 14 Mar 2024 at 15:52, gaoliming via groups.io
 wrote:
>
> For this patch set, I have no comments. Reviewed-by: Liming Gao 
> 
>

Merged as #5471



> > -邮件原件-
> > 发件人: Oliver Smith-Denny 
> > 发送时间: 2024年3月10日 3:06
> > 收件人: devel@edk2.groups.io
> > 抄送: Leif Lindholm ; Ard Biesheuvel
> > ; Sami Mujawar ;
> > Liming Gao 
> > 主题: [edk2-devel][PATCH v3 0/3] Fix Runtime Granularity Issues
> >
> > This patch series is the third version of
> > MdeModulePkg: DxeCore: Don't Guard Large Runtime Granularity Allocations.
> > The subject line has been updated because this went from a one commit
> > patch with no cover letter to a multi-commit patch.
> >
> > The commit messages cover the vast amount of detail here, but this
> > patchset fixes three issues:
> > - a UEFI spec violation for which memory types require runtime page
> > allocation granularity alignment
> > - An incompatibility of the heap guard system to guard these regions
> > that require runtime page allocation granularities greater than
> > the EFI_PAGE_SIZE.
> > - A CodeQL error that fails CI when updating the Page.c code
> >
> > v3:
> > - edit comments for readability
> >
> > v2:
> > - Add commit to fix UEFI spec violation
> > - Add commit to fix newly flagged CodeQL error
> > - Update guard commit message, comments, and static assert to use
> > the correct types
> >
> > Cc: Leif Lindholm 
> > Cc: Ard Biesheuvel 
> > Cc: Sami Mujawar 
> > Cc: Liming Gao 
> >
> > Oliver Smith-Denny (3):
> >   MdeModulePkg: DxeCore: Fix CodeQL Error in FreePages
> >   MdeModulePkg: DxeCore: Correct Runtime Granularity Memory Type
> >   MdeModulePkg: DxeCore: Do Not Apply Guards to Unsupported Types
> >
> >  MdeModulePkg/MdeModulePkg.dec | 10 +
> >  MdeModulePkg/Core/Dxe/Mem/HeapGuard.h | 14
> > +
> >  MdeModulePkg/Core/Dxe/Mem/Page.c  | 22
> > +---
> >  MdeModulePkg/Core/Dxe/Mem/Pool.c  | 15
> > +++--
> >  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c |  4 ++--
> >  MdeModulePkg/Core/Pei/Memory/MemoryServices.c |  2 +-
> >  6 files changed, 59 insertions(+), 8 deletions(-)
> >
> > --
> > 2.40.1
>
>
>
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116772): https://edk2.groups.io/g/devel/message/116772
Mute This Topic: https://groups.io/mt/104930045/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: 回复: [edk2-devel][PATCH v2 1/1] MdeModulePkg: Remove ArmPkg Dependency

[Ard Biesheuvel]

On Thu, 14 Mar 2024 at 15:46, Oliver Smith-Denny
 wrote:
>
> Thanks for the review!
>

I'll queue this up, along with the other series Liming just acked.


>
> On 3/14/2024 7:43 AM, gaoliming wrote:
> > Sorry for the late response. I think this is a good clean up. Reviewed-by:
> > Liming Gao 
> >
> >> -邮件原件-
> >> 发件人: Oliver Smith-Denny 
> >> 发送时间: 2024年2月15日 7:20
> >> 收件人: devel@edk2.groups.io
> >> 抄送: Leif Lindholm ; Ard Biesheuvel
> >> ; Sami Mujawar ;
> >> Liming Gao ; Sean Brogan
> >> ; Ard Biesheuvel 
> >> 主题: [edk2-devel][PATCH v2 1/1] MdeModulePkg: Remove ArmPkg
> >> Dependency
> >>
> >> With commita21a994f55e53325d3e060c435ca3a87fd7c2c79
> >> MdeModulePkg no longer has a hard dependency on ArmMmuLib and
> >> therefore
> >> ArmLib. This is the final dependency on ArmPkg, so remove the
> >> unused libs and drop the allowed dependency on ArmPkg as
> >> MdeModulePkg should not depend on it as this is a circular
> >> dependency.
> >>
> >> Github PR: https://github.com/tianocore/edk2/pull/5361
> >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3651
> >>
> >> Cc: Leif Lindholm 
> >> Cc: Ard Biesheuvel 
> >> Cc: Sami Mujawar 
> >> Cc: Liming Gao 
> >>
> >> Signed-off-by: Oliver Smith-Denny 
> >> Reviewed-by: Sean Brogan 
> >> Acked-by: Ard Biesheuvel 
> >> ---
> >>
> >> Notes:
> >>  v2:
> >>  - Add bugzilla link to commit message
> >>  - Add Sean's RB and Ard's ack
> >>
> >>   MdeModulePkg/MdeModulePkg.dsc | 2 --
> >>   MdeModulePkg/MdeModulePkg.ci.yaml | 3 +--
> >>   2 files changed, 1 insertion(+), 4 deletions(-)
> >>
> >> diff --git a/MdeModulePkg/MdeModulePkg.dsc
> >> b/MdeModulePkg/MdeModulePkg.dsc
> >> index 6b3052ff4614..c0f1df3bfbca 100644
> >> --- a/MdeModulePkg/MdeModulePkg.dsc
> >> +++ b/MdeModulePkg/MdeModulePkg.dsc
> >> @@ -179,8 +179,6 @@ [LibraryClasses.common.MM_STANDALONE]
> >>
> >> MemLib|StandaloneMmPkg/Library/StandaloneMmMemLib/StandaloneMm
> >> MemLib.inf
> >>
> >>   [LibraryClasses.ARM, LibraryClasses.AARCH64]
> >> -  ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> >> -  ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> >> LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> >>
> >> #
> >> diff --git a/MdeModulePkg/MdeModulePkg.ci.yaml
> >> b/MdeModulePkg/MdeModulePkg.ci.yaml
> >> index 669f54e33c0d..a3de60a12c9e 100644
> >> --- a/MdeModulePkg/MdeModulePkg.ci.yaml
> >> +++ b/MdeModulePkg/MdeModulePkg.ci.yaml
> >> @@ -53,8 +53,7 @@
> >>   "AcceptableDependencies": [
> >>   "MdePkg/MdePkg.dec",
> >>   "MdeModulePkg/MdeModulePkg.dec",
> >> -"StandaloneMmPkg/StandaloneMmPkg.dec",
> >> -"ArmPkg/ArmPkg.dec"  # this should be fixed by promoting
> >> an abstraction
> >> +"StandaloneMmPkg/StandaloneMmPkg.dec"
> >>   ],
> >>   # For host based unit tests
> >>   "AcceptableDependencies-HOST_APPLICATION":[
> >> --
> >> 2.40.1
> >
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116771): https://edk2.groups.io/g/devel/message/116771
Mute This Topic: https://groups.io/mt/104927624/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v6 6/7] Platform/SbsaQemu: get the information of memory via SMC calls

[Ard Biesheuvel]

On Wed, 6 Mar 2024 at 12:42, Marcin Juszkiewicz
 wrote:
>
> From: Xiong Yining 
>
> Provide functions to check for memory information:
>
> - amount of memory nodes
> - memory address
> - NUMA node id for memory
>
> Values are read from TF-A using platform specific SMC calls.
>
> Signed-off-by: Xiong Yining 
> Signed-off-by: Chen Baozi 
> ---
>  .../SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf |  2 +-
>  .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h  |  2 +
>  .../Include/Library/SbsaQemuHardwareInfoLib.h| 28 ++
>  .../SbsaQemuHardwareInfoLib.c| 47 +
>  .../Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c  | 54 
> +---
>  5 files changed, 91 insertions(+), 42 deletions(-)
>
> diff --git a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> index c067a80cc715..fb856efe4c27 100644
> --- a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> +++ b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> @@ -32,9 +32,9 @@ [LibraryClasses]
>ArmLib
>BaseMemoryLib
>DebugLib
> -  FdtLib
>MemoryAllocationLib
>PcdLib
> +  SbsaQemuHardwareInfoLib
>
>  [Pcd]
>gArmTokenSpaceGuid.PcdSystemMemoryBase
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> index d9faee7fa5b2..e7bf54978d4e 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> @@ -16,6 +16,8 @@
>  #define SIP_SVC_GET_GIC_ITSSMC_SIP_FUNCTION_ID(101)
>  #define SIP_SVC_GET_CPU_COUNT  SMC_SIP_FUNCTION_ID(200)
>  #define SIP_SVC_GET_CPU_NODE   SMC_SIP_FUNCTION_ID(201)
> +#define SIP_SVC_GET_MEMORY_NODE_COUNT SMC_SIP_FUNCTION_ID(300)
> +#define SIP_SVC_GET_MEMORY_NODE SMC_SIP_FUNCTION_ID(301)
>
>  /*
>   *  SMCC does not define return codes for SiP functions.
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
> index ca52c6b27093..0b71a3f7e6eb 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
> @@ -9,6 +9,12 @@
>  #ifndef SBSA_QEMU_HARDWARE_INFO_
>  #define SBSA_QEMU_HARDWARE_INFO_
>
> +typedef struct{
> +  UINT32  NodeId;
> +  UINT64  AddressBase;
> +  UINT64  AddressSize;
> +} MemoryInfo;
> +
>  /**
>Get CPU count from information passed by Qemu.
>
> @@ -42,4 +48,26 @@ SbsaQemuGetCpuNumaNode (
>IN UINTN  CpuId
>);
>
> +/**
> +  Get the number of memory node from device tree passed by Qemu.
> +
> +  @retval   the number of memory nodes.
> +**/
> +UINT32
> +SbsaQemuGetMemNodeCount (
> +  VOID
> +  );
> +
> +/**
> +  Get memory infomation(node-id, addressbase, addresssize) for a given 
> memory node from device tree passed by Qemu.
> +
> +  @param [in]   MemoryIdIndex of memory to retrieve memory information.
> +
> +  @retval   memory infomation for given memory node.
> +**/
> +MemoryInfo

Let's avoid aggregates as return types. Pass/return by reference
instead using an OUT pointer.


> +SbsaQemuGetMemInfo (
> +  IN UINTN   MemoryId
> +  );
> +
>  #endif /* SBSA_QEMU_HARDWARE_INFO_ */
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> index e1f1a9588b19..88b50e46c072 100644
> --- 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> @@ -201,3 +201,50 @@ SbsaQemuGetCpuNumaNode (
>
>return Arg0;
>  }
> +
> +UINT32
> +SbsaQemuGetMemNodeCount (
> +  VOID
> +  )
> +{
> +  UINTNSmcResult;
> +  UINTNArg0;
> +
> +  SmcResult = ArmCallSmc0 (SIP_SVC_GET_MEMORY_NODE_COUNT, , NULL, NULL);
> +  if (SmcResult != SMC_SIP_CALL_SUCCESS) {
> +DEBUG ((DEBUG_ERROR, "SIP_SVC_GET_MEMORY_NODE_COUNT call failed.\n"));
> +  }
> +
> +  DEBUG(( DEBUG_INFO, "The number of the memory nodes is %ld\n", Arg0));
> +  return (UINT32)Arg0;
> +}
> +
> +MemoryInfo
> +SbsaQemuGetMemInfo (
> +  IN UINTN   MemoryId
> +  )
> +{
> +  UINTN   SmcResult;
> +  UINTN   Arg0;
> +  UINTN   Arg1;
> +  UINTN   Arg2;
> +  MemoryInfo  MemInfo;
> +
> +  Arg0 = MemoryId;
> +
> +  SmcResult = ArmCallSmc1 (SIP_SVC_GET_MEMORY_NODE, , , );
> +  if (SmcResult != SMC_SIP_CALL_SUCCESS) {
> +DEBUG ((DEBUG_ERROR, "SIP_SVC_GET_MEMORY_NODE call failed.\n"));
> +  } else {
> +MemInfo.NodeId = Arg0;
> +MemInfo.AddressBase = Arg1;
> +MemInfo.AddressSize = Arg2;
> +  }
> +
> +  DEBUG(( DEBUG_INFO, "NUMA node for System RAM:%d = 0x%lx - 0x%lx\n",
> +  MemInfo.NodeId,
> +  

Re: [edk2-devel] [PATCH edk2-platforms v6 4/7] Platform/SbsaQemu: move FdtHandlerLib to SbsaQemuHardwareInfoLib

[Ard Biesheuvel]

On Wed, 6 Mar 2024 at 12:42, Marcin Juszkiewicz
 wrote:
>
> There is no need for EDK2 to know that there is DeviceTree around.
> All hardware information is read using functions from
> SbsaQemuHardwareInfoLib library.
>
> Library fallbacks to parsing DT if needed.
>

I'd prefer to have only a single method of obtaining this information.

> Signed-off-by: Marcin Juszkiewicz 
> Reviewed-by: Leif Lindholm 
> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc |   1 -
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf |   4 +-
>  .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf  |  33 ---
>  .../SbsaQemuHardwareInfoLib.inf |   2 +
>  .../Qemu/SbsaQemu/Include/Library/FdtHelperLib.h|  36 ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   |   4 +-
>  .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c|  98 --
>  .../SbsaQemuHardwareInfoLib.c   | 104 
> 
>  8 files changed, 110 insertions(+), 172 deletions(-)
>
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 07cb3490f4cf..bde61651da2e 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -126,7 +126,6 @@ [LibraryClasses.common]
># ARM PL011 UART Driver
>PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
>
> -  FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
>OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
>
> SbsaQemuHardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
> index 291743b19115..9bf0a13de5d1 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  This driver modifies ACPI tables for the Qemu SBSA platform
>  #
> -#  Copyright (c) 2020, Linaro Ltd. All rights reserved.
> +#  Copyright (c) Linaro Ltd. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -35,9 +35,9 @@ [LibraryClasses]
>BaseLib
>DebugLib
>DxeServicesLib
> -  FdtHelperLib
>PcdLib
>PrintLib
> +  SbsaQemuHardwareInfoLib
>UefiDriverEntryPoint
>UefiLib
>UefiRuntimeServicesTableLib
> diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf 
> b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
> deleted file mode 100644
> index 9c059f3e5851..
> --- a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -#/** @file
> -#
> -#  Component description file for FdtHelperLib module
> -#
> -#  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -#
> -#  SPDX-License-Identifier: BSD-2-Clause-Patent
> -#
> -#**/
> -
> -[Defines]
> -  INF_VERSION= 1.29
> -  BASE_NAME  = FdtHelperLib
> -  FILE_GUID  = 34e4396f-c2fc-4f9e-ad58-0f98e99e3875
> -  MODULE_TYPE= BASE
> -  VERSION_STRING = 1.0
> -  LIBRARY_CLASS  = FdtHelperLib
> -
> -[Sources.common]
> -  FdtHelperLib.c
> -
> -[Packages]
> -  EmbeddedPkg/EmbeddedPkg.dec
> -  MdePkg/MdePkg.dec
> -  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> -
> -[LibraryClasses]
> -  DebugLib
> -  FdtLib
> -  PcdLib
> -
> -[FixedPcd]
> -  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> index 8c2def1878e6..5358dd339eb3 100644
> --- 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> @@ -27,6 +27,8 @@ [LibraryClasses]
>ArmSmcLib
>BaseMemoryLib
>DebugLib
> +  FdtLib
>
>   [Pcd]
> +  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
> deleted file mode 100644
> index ea9159857215..
> --- a/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
> +++ /dev/null
> @@ -1,36 +0,0 @@
> -/** @file
> -*  FdtHelperLib.h
> -*
> -*  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -*
> -*  SPDX-License-Identifier: BSD-2-Clause-Patent
> -*
> -**/
> -
> -#ifndef FDT_HELPER_LIB_
> -#define FDT_HELPER_LIB_
> -
> -/**
> -  Get MPIDR for a given cpu from device tree passed by Qemu.
> -
> -  @param [in]   CpuIdIndex of cpu to retrieve MPIDR value for.
> -
> -  @retvalMPIDR 

Re: [edk2-devel] [PATCH edk2-platforms v6 3/7] Platform/SbsaQemu: use PcdCoreCount directly

[Ard Biesheuvel]

On Wed, 6 Mar 2024 at 12:42, Marcin Juszkiewicz
 wrote:
>
> During platform initialization we read amount of cpu cores and set
> PcdCoreCount so there is no need to call FdtHandler.
>

How can you be sure that that code executes first?

> Signed-off-by: Marcin Juszkiewicz 
> ---
>  Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf  |  6 ++
>  Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c| 10 --
>  .../Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   | 11 
> ++-
>  3 files changed, 8 insertions(+), 19 deletions(-)
>
> diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf 
> b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> index a34f54d431d4..8e2bf8c512f1 100644
> --- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> +++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> @@ -3,7 +3,7 @@
>  #
>  #Copyright (c) 2021, NUVIA Inc. All rights reserved.
>  #Copyright (c) 2018, Hisilicon Limited. All rights reserved.
> -#Copyright (c) 2018, Linaro Limited. All rights reserved.
> +#Copyright (c) 2023, Linaro Ltd. All rights reserved.
>  #
>  #SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -29,8 +29,6 @@ [Packages]
>
>  [LibraryClasses]
>BaseMemoryLib
> -  FdtLib
> -  FdtHelperLib
>IoLib
>PcdLib
>
> @@ -40,7 +38,6 @@ [Guids]
>  [Pcd]
>gArmTokenSpaceGuid.PcdEmbeddedControllerFirmwareRelease
>gArmTokenSpaceGuid.PcdSystemBiosRelease
> -  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
>
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSystemManufacturer
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSystemSerialNumber
> @@ -56,3 +53,4 @@ [Pcd]
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdChassisManufacturer
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdChassisAssetTag
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdChassisSKU
> +  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
> diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c 
> b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> index c38f2851904f..ab97768b5ddc 100644
> --- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> +++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> @@ -2,7 +2,7 @@
>  *  OemMiscLib.c
>  *
>  *  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
> +*  Copyright (c) Linaro Ltd. All rights reserved.
>  *
>  *  SPDX-License-Identifier: BSD-2-Clause-Patent
>  *
> @@ -12,14 +12,12 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>
>  /** Returns whether the specified processor is present or not.
>
> @@ -33,7 +31,7 @@ OemIsProcessorPresent (
>UINTN ProcessorIndex
>)
>  {
> -  if (ProcessorIndex < FdtHelperCountCpus ()) {
> +  if (ProcessorIndex < PcdGet32 (PcdCoreCount)) {
>  return TRUE;
>}
>
> @@ -76,7 +74,7 @@ OemGetProcessorInformation (
>  {
>UINT16 ProcessorCount;
>
> -  ProcessorCount = FdtHelperCountCpus ();
> +  ProcessorCount = PcdGet32 (PcdCoreCount);
>
>if (ProcessorIndex < ProcessorCount) {
>  ProcessorStatus->Bits.CpuStatus   = 1; // CPU enabled
> @@ -121,7 +119,7 @@ OemGetMaxProcessors (
>VOID
>)
>  {
> -  return FdtHelperCountCpus ();
> +  return PcdGet32 (PcdCoreCount);
>  }
>
>  /** Gets information about the cache at the specified cache level.
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index 9fb17151d7b8..59536ea9575e 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -1,7 +1,7 @@
>  /** @file
>  *  This file is an ACPI driver for the Qemu SBSA platform.
>  *
> -*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
> +*  Copyright (c) Linaro Ltd. All rights reserved.
>  *
>  *  SPDX-License-Identifier: BSD-2-Clause-Patent
>  *
> @@ -255,7 +255,6 @@ AddMadtTable (
>   // Initialize GIC Redistributor Structure
>EFI_ACPI_6_0_GICR_STRUCTURE Gicr = SBSAQEMU_MADT_GICR_INIT();
>
> -  // Get CoreCount which was determined eariler after parsing device tree
>NumCores = PcdGet32 (PcdCoreCount);
>
>// Calculate the new table size based on the number of cores
> @@ -291,7 +290,7 @@ AddMadtTable (
>New += sizeof (EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER);
>
>// Add new GICC structures for the Cores
> -  for (CoreIndex = 0; CoreIndex < PcdGet32 (PcdCoreCount); CoreIndex++) {
> +  for (CoreIndex = 0; CoreIndex < NumCores; CoreIndex++) {
>  EFI_ACPI_6_0_GIC_STRUCTURE *GiccPtr;
>
>  CopyMem (New, , sizeof (EFI_ACPI_6_0_GIC_STRUCTURE));
> @@ -758,12 +757,6 @@ InitializeSbsaQemuAcpiDxe (
>  {
>EFI_STATUS Status;
>EFI_ACPI_TABLE_PROTOCOL*AcpiTable;
> -  UINT32 NumCores;
> -
> -  // Parse the device 

Re: [edk2-devel] [PATCH edk2-platforms v6 1/7] Platform/SbsaQemu: add SbsaQemuHardwareInfoLib

[Ard Biesheuvel]

On Thu, 14 Mar 2024 at 16:09, Ard Biesheuvel  wrote:
>
> On Wed, 6 Mar 2024 at 12:42, Marcin Juszkiewicz
>  wrote:
> >
> > This library provides functions to check for hardware information.
> > For now it covers CPU ones:
> >
> > - amount of cpu cores
> > - MPIDR value for cpu core
> > - NUMA node id for cpu core
> >
> > Values are read from TF-A using platform specific SMC calls.
> >
> > Signed-off-by: Marcin Juszkiewicz 
> > ---
> >  Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  3 +-
> >  .../SbsaQemuHardwareInfoLib.inf  | 32 +++
> >  .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h  | 15 ++-
> >  .../Include/Library/SbsaQemuHardwareInfoLib.h| 45 +
> >  .../SbsaQemuHardwareInfoLib.c| 98 
> > 
> >  5 files changed, 189 insertions(+), 4 deletions(-)
> >
> > diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> > b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> > index 378600050df9..07cb3490f4cf 100644
> > --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> > +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> > @@ -1,6 +1,6 @@
> >  #
> >  #  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> > -#  Copyright (c) 2019, Linaro Limited. All rights reserved.
> > +#  Copyright (c) 2019-2024, Linaro Ltd. All rights reserved.
> >  #
> >  #  SPDX-License-Identifier: BSD-2-Clause-Patent
> >  #
> > @@ -128,6 +128,7 @@ [LibraryClasses.common]
> >
> >FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
> >OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> > +  
> > SbsaQemuHardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> >
> ># Debug Support
> >
> > PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
> > diff --git 
> > a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> >  
> > b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> > new file mode 100644
> > index ..8c2def1878e6
> > --- /dev/null
> > +++ 
> > b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> > @@ -0,0 +1,32 @@
> > +#/* @file
> > +#
> > +#  Copyright (c) Linaro Ltd. All rights reserved.
> > +#
> > +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +#
> > +#*/
> > +
> > +[Defines]
> > +  INF_VERSION= 0x0001001c
> > +  BASE_NAME  = SbsaQemuHardwareInfoLib
> > +  FILE_GUID  = 6454006f-6502-46e2-9be4-4bba8d4b29fb
> > +  MODULE_TYPE= BASE
> > +  VERSION_STRING = 1.0
> > +  LIBRARY_CLASS  = ArmPlatformLib
> > +
>
> This is a new library class, so you should name it and define it in
> the associated .DEC file (which does not exist yet)
>
> You can look at Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.dec
> for inspiration (but please use 1.27 and not 0x00010005 for the
> version)
>

Just noticed there is already a .DEC in Silicon/Qemu/SbsaQemu/ so
better to put it there.

>
> > +[Sources]
> > +  SbsaQemuHardwareInfoLib.c
> > +
> > +[Packages]
> > +  ArmPkg/ArmPkg.dec
> > +  EmbeddedPkg/EmbeddedPkg.dec
> > +  MdePkg/MdePkg.dec
> > +  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> > +
> > +[LibraryClasses]
> > +  ArmSmcLib
> > +  BaseMemoryLib
> > +  DebugLib
> > +
> > + [Pcd]
> > +  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
> > diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
> > b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> > index 7934875e4aba..d9faee7fa5b2 100644
> > --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> > +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> > @@ -11,8 +11,17 @@
> >
> >  #include 
> >
> > -#define SIP_SVC_VERSION  SMC_SIP_FUNCTION_ID(1)
> > -#define SIP_SVC_GET_GIC  SMC_SIP_FUNCTION_ID(100)
> > -#define SIP_SVC_GET_GIC_ITS  SMC_SIP_FUNCTION_ID(101)
> > +#define SIP_SVC_VERSIONSMC_SIP_FUNCTION_ID(1)
> > +#define SIP_SVC_GET_GICSMC_SIP_FUNCTION_ID(100)
> > +#define SIP_SVC_GET_GIC_ITSSMC_SIP_FUNCTION_ID(101)
> > +#define SIP_SVC_GET_CPU_COUNT  SMC_SIP_FUNCTION_ID(200)
> > +#define SIP_SVC_GET_CPU_NODE   SMC_SIP_FUNCTION_ID(201)
> > +
> > +/*
> &g

Re: [edk2-devel] [PATCH edk2-platforms v6 2/7] Platform/SbsaQemu: read amount of cpus during init

[Ard Biesheuvel]

On Wed, 6 Mar 2024 at 12:42, Marcin Juszkiewicz
 wrote:
>
> We read it once and store in Pcd for future use.
>
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  .../SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.inf | 4 +++-
>  .../SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c   | 9 
> +
>  2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.inf 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.inf
> index 19534b7a274a..9752694a432b 100644
> --- 
> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.inf
> +++ 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  This driver effectuates SbsaQemu platform configuration settings
>  #
> -#  Copyright (c) 2019, Linaro Ltd. All rights reserved.
> +#  Copyright (c) Linaro Ltd. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -32,6 +32,7 @@ [LibraryClasses]
>PcdLib
>DebugLib
>NonDiscoverableDeviceRegistrationLib
> +  SbsaQemuHardwareInfoLib
>UefiDriverEntryPoint
>
>  [Pcd]
> @@ -46,6 +47,7 @@ [Pcd]
>gArmTokenSpaceGuid.PcdGicDistributorBase
>gArmTokenSpaceGuid.PcdGicRedistributorsBase
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdGicItsBase
> +  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
>
>
>  [Depex]

How is it guaranteed that other components will only see the correct
core count? DXE dispatch is ordered using a dependency graph, so all
users of this PCD should never execute before this driver.

This is why PCDs suck for dynamic information, to be honest. Much
better to use a protocol (DEPEXes declare dependencies on protocols,
so a driver will never run before the protocols it depends on have
been made available)

Given that this is intended as reference code, I think it is very
important to get this right.


> diff --git 
> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
> index 4ebbe7c93a19..14e1ec7eab29 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c
> @@ -1,7 +1,7 @@
>  /** @file
> -*  FDT client protocol driver for qemu,mach-virt-ahci DT node
> +*  SbsaQemu Platform Initialization
>  *
> -*  Copyright (c) 2019, Linaro Ltd. All rights reserved.
> +*  Copyright (c) Linaro Ltd. All rights reserved.
>  *
>  *  SPDX-License-Identifier: BSD-2-Clause-Patent
>  *
> @@ -12,13 +12,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>
> -#include 
> -
>  EFI_STATUS
>  EFIAPI
>  InitializeSbsaQemuPlatformDxe (
> @@ -123,5 +122,7 @@ InitializeSbsaQemuPlatformDxe (
>  }
>}
>
> +  SbsaQemuGetCpuCount ();
> +
>return EFI_SUCCESS;
>  }
>
> --
> 2.44.0
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116766): https://edk2.groups.io/g/devel/message/116766
Mute This Topic: https://groups.io/mt/104763764/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v6 1/7] Platform/SbsaQemu: add SbsaQemuHardwareInfoLib

[Ard Biesheuvel]

On Wed, 6 Mar 2024 at 12:42, Marcin Juszkiewicz
 wrote:
>
> This library provides functions to check for hardware information.
> For now it covers CPU ones:
>
> - amount of cpu cores
> - MPIDR value for cpu core
> - NUMA node id for cpu core
>
> Values are read from TF-A using platform specific SMC calls.
>
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  3 +-
>  .../SbsaQemuHardwareInfoLib.inf  | 32 +++
>  .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h  | 15 ++-
>  .../Include/Library/SbsaQemuHardwareInfoLib.h| 45 +
>  .../SbsaQemuHardwareInfoLib.c| 98 
> 
>  5 files changed, 189 insertions(+), 4 deletions(-)
>
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 378600050df9..07cb3490f4cf 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -1,6 +1,6 @@
>  #
>  #  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -#  Copyright (c) 2019, Linaro Limited. All rights reserved.
> +#  Copyright (c) 2019-2024, Linaro Ltd. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -128,6 +128,7 @@ [LibraryClasses.common]
>
>FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
>OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> +  
> SbsaQemuHardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>
># Debug Support
>
> PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> new file mode 100644
> index ..8c2def1878e6
> --- /dev/null
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> @@ -0,0 +1,32 @@
> +#/* @file
> +#
> +#  Copyright (c) Linaro Ltd. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +#*/
> +
> +[Defines]
> +  INF_VERSION= 0x0001001c
> +  BASE_NAME  = SbsaQemuHardwareInfoLib
> +  FILE_GUID  = 6454006f-6502-46e2-9be4-4bba8d4b29fb
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = ArmPlatformLib
> +

This is a new library class, so you should name it and define it in
the associated .DEC file (which does not exist yet)

You can look at Platform/Qemu/QemuOpenBoardPkg/QemuOpenBoardPkg.dec
for inspiration (but please use 1.27 and not 0x00010005 for the
version)


> +[Sources]
> +  SbsaQemuHardwareInfoLib.c
> +
> +[Packages]
> +  ArmPkg/ArmPkg.dec
> +  EmbeddedPkg/EmbeddedPkg.dec
> +  MdePkg/MdePkg.dec
> +  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> +
> +[LibraryClasses]
> +  ArmSmcLib
> +  BaseMemoryLib
> +  DebugLib
> +
> + [Pcd]
> +  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> index 7934875e4aba..d9faee7fa5b2 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> @@ -11,8 +11,17 @@
>
>  #include 
>
> -#define SIP_SVC_VERSION  SMC_SIP_FUNCTION_ID(1)
> -#define SIP_SVC_GET_GIC  SMC_SIP_FUNCTION_ID(100)
> -#define SIP_SVC_GET_GIC_ITS  SMC_SIP_FUNCTION_ID(101)
> +#define SIP_SVC_VERSIONSMC_SIP_FUNCTION_ID(1)
> +#define SIP_SVC_GET_GICSMC_SIP_FUNCTION_ID(100)
> +#define SIP_SVC_GET_GIC_ITSSMC_SIP_FUNCTION_ID(101)
> +#define SIP_SVC_GET_CPU_COUNT  SMC_SIP_FUNCTION_ID(200)
> +#define SIP_SVC_GET_CPU_NODE   SMC_SIP_FUNCTION_ID(201)
> +
> +/*
> + *  SMCC does not define return codes for SiP functions.
> + *  We use Architecture ones then.
> + */
> +
> +#define SMC_SIP_CALL_SUCCESS  SMC_ARCH_CALL_SUCCESS
>
>  #endif /* SBSA_QEMU_SMC_H_ */
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
> new file mode 100644
> index ..ca52c6b27093
> --- /dev/null
> +++ b/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
> @@ -0,0 +1,45 @@
> +/** @file
> +*
> +*  Copyright (c) Linaro Ltd. All rights reserved.
> +*
> +*  SPDX-License-Identifier: BSD-2-Clause-Patent
> +*
> +**/
> +
> +#ifndef SBSA_QEMU_HARDWARE_INFO_
> +#define SBSA_QEMU_HARDWARE_INFO_
> +
> +/**
> +  Get CPU count from information passed by Qemu.
> +
> +**/
> +VOID
> +SbsaQemuGetCpuCount (
> +  VOID
> +  );
> +
> +/**
> +  Get MPIDR for a given cpu from device tree passed by Qemu.
> +
> +  @param [in]   CpuIdIndex of cpu to retrieve MPIDR value for.
> +
> +  @retvalMPIDR value 

Re: [edk2-devel] [PATCH 1/1] EmbeddedPkg/NonCoherentIoMmuDxe: Make SetAttributes always succeed

[Ard Biesheuvel]

On Tue, 12 Mar 2024 at 17:56, Leif Lindholm  wrote:
>
> On 2024-03-12 09:50, Ard Biesheuvel wrote:
> > On Tue, 12 Mar 2024 at 17:38, Leif Lindholm  
> > wrote:
> >>
> >> On 2024-03-12 08:17, Ard Biesheuvel wrote:
> >>> From: Ard Biesheuvel 
> >>>
> >>> NonCoherentIoMmuSetAttribute() does nothing except return
> >>> EFI_UNSUPPORTED. This was fine when it was introduced, but now, the PCI
> >>> bus driver will fail a PCI I/O Map() operation if the SetAttributes
> >>> fails.
> >>>
> >>> So return EFI_SUCCESS instead.
> >>
> >> It's unclear to me why this change is safe (looking forward).
> >> Does NonCoherentIoMmuDxe also imply no IoMmu actually exists?
> >>
> >
> > Basically. NonCoherentIoMmuDxe is just a vehicle to allow
> > NonCoherentDmaLib to be plugged into the PCI host bridge driver. It is
> > not intended to ever do anything more than that.
>
> Not that it needs to happen for this
> (Reviewed-by: Leif Lindholm )
> but maybe we ought to consider renaming it then?
> DummyIoMmuDxe?
>

Fair point. Or PassThroughIoMmuDxe perhaps?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116696): https://edk2.groups.io/g/devel/message/116696
Mute This Topic: https://groups.io/mt/104886877/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] EmbeddedPkg/NonCoherentIoMmuDxe: Make SetAttributes always succeed

[Ard Biesheuvel]

On Tue, 12 Mar 2024 at 17:38, Leif Lindholm  wrote:
>
> On 2024-03-12 08:17, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel 
> >
> > NonCoherentIoMmuSetAttribute() does nothing except return
> > EFI_UNSUPPORTED. This was fine when it was introduced, but now, the PCI
> > bus driver will fail a PCI I/O Map() operation if the SetAttributes
> > fails.
> >
> > So return EFI_SUCCESS instead.
>
> It's unclear to me why this change is safe (looking forward).
> Does NonCoherentIoMmuDxe also imply no IoMmu actually exists?
>

Basically. NonCoherentIoMmuDxe is just a vehicle to allow
NonCoherentDmaLib to be plugged into the PCI host bridge driver. It is
not intended to ever do anything more than that.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116693): https://edk2.groups.io/g/devel/message/116693
Mute This Topic: https://groups.io/mt/104886877/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/1] EmbeddedPkg/NonCoherentIoMmuDxe: Make SetAttributes always succeed

[Ard Biesheuvel via groups.io]

From: Ard Biesheuvel 

NonCoherentIoMmuSetAttribute() does nothing except return
EFI_UNSUPPORTED. This was fine when it was introduced, but now, the PCI
bus driver will fail a PCI I/O Map() operation if the SetAttributes
fails.

So return EFI_SUCCESS instead.

Signed-off-by: Ard Biesheuvel 
---
This fixes a regression on Raspberry Pi4, which no longer boots.

 EmbeddedPkg/Drivers/NonCoherentIoMmuDxe/NonCoherentIoMmuDxe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmbeddedPkg/Drivers/NonCoherentIoMmuDxe/NonCoherentIoMmuDxe.c 
b/EmbeddedPkg/Drivers/NonCoherentIoMmuDxe/NonCoherentIoMmuDxe.c
index 4e7a5698c162..f02a76a62ea8 100644
--- a/EmbeddedPkg/Drivers/NonCoherentIoMmuDxe/NonCoherentIoMmuDxe.c
+++ b/EmbeddedPkg/Drivers/NonCoherentIoMmuDxe/NonCoherentIoMmuDxe.c
@@ -70,7 +70,7 @@ NonCoherentIoMmuSetAttribute (
   IN UINT64IoMmuAccess
   )
 {
-  return EFI_UNSUPPORTED;
+  return EFI_SUCCESS;
 }
 
 /**
-- 
2.44.0.278.ge034bb2e1d-goog



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116688): https://edk2.groups.io/g/devel/message/116688
Mute This Topic: https://groups.io/mt/104886877/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms 1/1] Platform/RPI4: Grow FV size to accommodate DEBUG build

[Ard Biesheuvel via groups.io]

From: Ard Biesheuvel 

The DEBUG build no longer fits when all build options used by the
release script on github.com/pftf are used, presumably due to the
OpenSSL upgrade.

So bump the size for all builds.

Signed-off-by: Ard Biesheuvel 
---
 Platform/RaspberryPi/RPi4/RPi4.fdf | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Platform/RaspberryPi/RPi4/RPi4.fdf 
b/Platform/RaspberryPi/RPi4/RPi4.fdf
index 816927761513..951488260ed4 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.fdf
+++ b/Platform/RaspberryPi/RPi4/RPi4.fdf
@@ -25,11 +25,11 @@
 
 [FD.RPI_EFI]
 BaseAddress   = 0x|gArmTokenSpaceGuid.PcdFdBaseAddress
-Size  = 0x001f|gArmTokenSpaceGuid.PcdFdSize
+Size  = 0x0021|gArmTokenSpaceGuid.PcdFdSize
 ErasePolarity = 1
 
 BlockSize = 0x1000|gRaspberryPiTokenSpaceGuid.PcdFirmwareBlockSize
-NumBlocks = 0x1f0
+NumBlocks = 0x210
 
 

 #
@@ -56,7 +56,7 @@ [FD.RPI_EFI]
 #
 # UEFI image
 #
-0x0002|0x001b
+0x0002|0x001d
 gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
 FV = FVMAIN_COMPACT
 
@@ -70,7 +70,7 @@ [FD.RPI_EFI]
 #
 
 # NV_VARIABLE_STORE
-0x001d|0xe000
+0x001f|0xe000
 
gRaspberryPiTokenSpaceGuid.PcdNvStorageVariableBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
 
 DATA = {
@@ -113,11 +113,11 @@ [FD.RPI_EFI]
 }
 
 # NV_EVENT_LOG
-0x001de000|0x1000
+0x001fe000|0x1000
 
gRaspberryPiTokenSpaceGuid.PcdNvStorageEventLogBase|gRaspberryPiTokenSpaceGuid.PcdNvStorageEventLogSize
 
 # NV_FTW_WORKING header
-0x001df000|0x1000
+0x001ff000|0x1000
 
gRaspberryPiTokenSpaceGuid.PcdNvStorageFtwWorkingBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
 
 DATA = {
@@ -132,7 +132,7 @@ [FD.RPI_EFI]
 }
 
 # NV_FTW_WORKING data
-0x001e|0x0001
+0x0020|0x0001
 
gRaspberryPiTokenSpaceGuid.PcdNvStorageFtwSpareBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
 
 #
-- 
2.44.0.278.ge034bb2e1d-goog



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116687): https://edk2.groups.io/g/devel/message/116687
Mute This Topic: https://groups.io/mt/104882052/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 1/1] Platform/RPI4: Grow FV size to accommodate DEBUG build

[Ard Biesheuvel]

On Tue, 12 Mar 2024 at 11:29, Ard Biesheuvel  wrote:
>
> From: Ard Biesheuvel 
>
> The DEBUG build no longer fits when all build options used by the
> release script on github.com/pftf are used, presumably due to the
> OpenSSL upgrade.
>
> So bump the size for all builds.
>
> Signed-off-by: Ard Biesheuvel 
> ---
>  Platform/RaspberryPi/RPi4/RPi4.fdf | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/Platform/RaspberryPi/RPi4/RPi4.fdf 
> b/Platform/RaspberryPi/RPi4/RPi4.fdf
> index 816927761513..951488260ed4 100644
> --- a/Platform/RaspberryPi/RPi4/RPi4.fdf
> +++ b/Platform/RaspberryPi/RPi4/RPi4.fdf
> @@ -25,11 +25,11 @@
>
>  [FD.RPI_EFI]
>  BaseAddress   = 0x|gArmTokenSpaceGuid.PcdFdBaseAddress
> -Size  = 0x001f|gArmTokenSpaceGuid.PcdFdSize
> +Size  = 0x0021|gArmTokenSpaceGuid.PcdFdSize
>  ErasePolarity = 1
>

Ugh just realized that this breaks DT loading from TFA, which places
the DT at a fixed offset of 0x1f


>  BlockSize = 0x1000|gRaspberryPiTokenSpaceGuid.PcdFirmwareBlockSize
> -NumBlocks = 0x1f0
> +NumBlocks = 0x210
>
>  
> 
>  #
> @@ -56,7 +56,7 @@ [FD.RPI_EFI]
>  #
>  # UEFI image
>  #
> -0x0002|0x001b
> +0x0002|0x001d
>  gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
>  FV = FVMAIN_COMPACT
>
> @@ -70,7 +70,7 @@ [FD.RPI_EFI]
>  #
>
>  # NV_VARIABLE_STORE
> -0x001d|0xe000
> +0x001f|0xe000
>  
> gRaspberryPiTokenSpaceGuid.PcdNvStorageVariableBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
>
>  DATA = {
> @@ -113,11 +113,11 @@ [FD.RPI_EFI]
>  }
>
>  # NV_EVENT_LOG
> -0x001de000|0x1000
> +0x001fe000|0x1000
>  
> gRaspberryPiTokenSpaceGuid.PcdNvStorageEventLogBase|gRaspberryPiTokenSpaceGuid.PcdNvStorageEventLogSize
>
>  # NV_FTW_WORKING header
> -0x001df000|0x1000
> +0x001ff000|0x1000
>  
> gRaspberryPiTokenSpaceGuid.PcdNvStorageFtwWorkingBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
>
>  DATA = {
> @@ -132,7 +132,7 @@ [FD.RPI_EFI]
>  }
>
>  # NV_FTW_WORKING data
> -0x001e|0x0001
> +0x0020|0x0001
>  
> gRaspberryPiTokenSpaceGuid.PcdNvStorageFtwSpareBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
>
>  #
> --
> 2.44.0.278.ge034bb2e1d-goog
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116676): https://edk2.groups.io/g/devel/message/116676
Mute This Topic: https://groups.io/mt/104882052/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/3] MdeModulePkg: ImagePropertiesRecordLib: Use SectionAlignment for CodeSize

[Ard Biesheuvel]

On Mon, 11 Mar 2024 at 22:29, Oliver Smith-Denny
 wrote:
>
> When an ImageRecord is stored by ImagePropertiesRecordLib, it reports the
> CodeSegmentSize as the SizeOfRawData from the image. However, the image
> as loaded into memory is aligned to the SectionAlignment, so
> SizeOfRawData is under the actual size in memory. This is important,
> because the memory attributes table uses these image records to create
> its entries and it will report that the alignment of an image is
> incorrect, even though the actual image is correct.
>
> This was discovered on ARM64, which has a 64k runtime page granularity
> alignment, which is backed by a 64k section alignment for
> DXE_RUNTIME_DRIVERs. The runtime code and data was correctly being
> loaded into memory, however the memory attribute table was incorrectly
> reporting misaligned ranges to the OS, causing attributes to be
> ignored for these sections for OSes using greater than 4k pages.
>
> This patch correctly aligns the CodeSegmentSize to the SectionAlignment
> and the corresponding memory attribute table entries are now correctly
> aligned and pointing to the right places in memory.
>
> Cc: Liming Gao 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> Cc: Taylor Beebe 
>
> Signed-off-by: Oliver Smith-Denny 
> ---
>  MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c | 4 
> +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>

Reviewed-by: Ard Biesheuvel 

> diff --git 
> a/MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c 
> b/MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c
> index e53ce086c54c..763a8d65d565 100644
> --- a/MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c
> +++ b/MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c
> @@ -1090,7 +1090,9 @@ CreateImagePropertiesRecord (
>ImageRecordCodeSection->Signature = 
> IMAGE_PROPERTIES_RECORD_CODE_SECTION_SIGNATURE;
>
>ImageRecordCodeSection->CodeSegmentBase = (UINTN)ImageBase + 
> Section[Index].VirtualAddress;
> -  ImageRecordCodeSection->CodeSegmentSize = Section[Index].SizeOfRawData;
> +  // We still need to align the VirtualSize to the SectionAlignment 
> because MSVC does not do
> +  // this when creating a PE image. It expects the loader to do this.
> +  ImageRecordCodeSection->CodeSegmentSize = ALIGN_VALUE 
> (Section[Index].Misc.VirtualSize, SectionAlignment);
>
>InsertTailList (>CodeSegmentList, 
> >Link);
>ImageRecord->CodeSegmentCount++;
> --
> 2.40.1
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116672): https://edk2.groups.io/g/devel/message/116672
Mute This Topic: https://groups.io/mt/104873193/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel][PATCH v1 1/3] MdeModulePkg: ImagePropertiesRecordLib: Use SectionAlignment for CodeSize

[Ard Biesheuvel]

On Mon, 11 Mar 2024 at 20:34, Oliver Smith-Denny
 wrote:
>
> On 3/4/2024 2:38 PM, Oliver Smith-Denny wrote:
> > On 3/4/2024 11:24 AM, Oliver Smith-Denny wrote:
> >> On 3/4/2024 10:54 AM, Ard Biesheuvel wrote:
> >>> On Mon, 4 Mar 2024 at 18:49, Oliver Smith-Denny
> >>>  wrote:
> >>>>
> >>>> Hi Ard,
> >>>>
> >>>> On 3/1/2024 3:58 AM, Ard Biesheuvel wrote:
> >>>>> Hi Oliver,
> >>>>>
> >>>>> On Tue, 27 Feb 2024 at 21:27, Oliver Smith-Denny
> >>>>>  wrote:
> >>>>>>
> >>>>>> -  ImageRecordCodeSection->CodeSegmentSize =
> >>>>>> Section[Index].SizeOfRawData;
> >>>>>> +  ImageRecordCodeSection->CodeSegmentSize = ALIGN_VALUE
> >>>>>> (Section[Index].SizeOfRawData, SectionAlignment);
> >>>>>>
> >>>>>
> >>>>> This should be the virtual size, not the file size, right?
> >>>>
> >>>> Correct, SectionAlignment is the alignment of the image as loaded in
> >>>> memory, so in the case of a DXE runtime driver on ARM64, it will be
> >>>> 64k.
> >>>>
> >>>
> >>> No, I mean we should not be using SizeOfRawData here but VirtualSize.
> >>>
> >>> I understand this is unlikely to make a difference in practice, but
> >>> VirtualSize may exceed SizeOfRawData by a wide margin, and we need the
> >>> whole region to be covered.
> >>>
> >>
> >> I see, yes I do believe VirtualSize could be used here instead. Two
> >> things give me pause. One is that the PE spec states that SizeOfRawData
> >> is rounded and VirtualSize is not, so that SizeOfRawData may be greater
> >> than the VirtualSize in some cases (which seems incorrect).
> >>
> >> The other is that the image loader partially uses VirtualSize when
> >> loading:
> >>
> >> https://github.com/tianocore/edk2/blob/918288ab5a7c3abe9c58d576ccc0ae32e2c7dea0/MdePkg/Library/BasePeCoffLib/BasePeCoff.c#L1399-L1400
> >>
> >> However, when determining the size of a loaded image (and therefore the
> >> number of pages to allocate) it will allocate an extra page:
> >>
> >> https://github.com/tianocore/edk2/blob/918288ab5a7c3abe9c58d576ccc0ae32e2c7dea0/MdeModulePkg/Core/Dxe/Image/Image.c#L646-L652
> >>
> >> as ImageSize here is:
> >>
> >> https://github.com/tianocore/edk2/blob/918288ab5a7c3abe9c58d576ccc0ae32e2c7dea0/MdePkg/Library/BasePeCoffLib/BasePeCoff.c#L312
> >>
> >> Which according to the spec, SizeOfImage is the size of the image as
> >> loaded into memory and must be a multiple of section alignment.
> >>
> >> So, reflecting on this, let me test with VirtualSize here, I think
> >> that is the right value to use, the only time we would have a
> >> SizeOfRawData that is greater than the VirtualSize would be if our
> >> FileAlignment is greater than our SectionAlignment, which would be
> >> a misconfiguration.
> >>
> >> I do think the ImageLoader should also be fixed to only allocate
> >> ImageSize number of pages (which should be the sum of the section
> >> VirtualSizes + any headers that aren't included). Might as well not
> >> waste an extra page for each image and then our image record code is
> >> simpler as well (ensuring we are protecting the right pages).
> >>
> >> I think this patch series should go in, as it is fixing an active bug,
> >> but I will also take a look at the image loader creating the image
> >> records and having a protocol it produces to retrieve the list, to
> >> attempt to avoid issues like this in the future.
> >>
> >
> > Surprisingly, I am seeing that the VirtualSize is not 64k aligned there.
> > I am looking deeper into GenFw to make sure it is correctly getting set
> > to align to SectionAlignment in the section headers. When I use dumpbin
> > to dump the headers, it shows each section having VirtualSize as 64k
> > aligned for a runtime image, but the same image doesn't show that in FW.
> >
> > I'll do some digging here.
> >
>
> Following up on this:
>
> Not surprisingly, different toolchains do different things here.
>
> gcc obviously creates ELF files and ElfConvert*.c converts these to PE
> images. However, when it does this, it always sets the section and file
> alignment to the same value (I'm not as familiar with ELF im

Re: [edk2-devel] [PATCH v2 0/5] Platform/RaspberryPi: Various minor fixes

[Ard Biesheuvel]

On Wed, 17 Jan 2024 at 22:36, Jeremy Linton  wrote:
>
> This includes a change to always initialize the PL011 to the
> configured baud (which should be 115200 for the SBSA UART), which
> fixes linux's assumption that SBSA UARTs are pre-programmed for
> 115200. This in turn (re)enables the PL011 when the console is on the
> miniuart per the config.txt file.
>
> Also included is another spin with the DT/XHCI reset patch which puts
> removal of the DT node that causes linux to reset the XHCI controller,
> as well as an additional patch that updates the DT to match the PCIe
> MMIO window we have programmed. This cures much of the problem with
> the PCIe/XHCI configuration when booted in DT mode on linux.
>
> There is also a few menu visibility/section tweaks to assure ACPI/DT
> specific settings show up at the appropriate time.
>
> As well as a minor fix to work around a bogus compiler warning.
>
> v1->v2: Ard's review comments.
> Convert PCIe MMIO address to use the fixedPCDs defined elsewhere
> Hardcode 115200 for the SBSA UART
>
> Jeremy Linton (5):
>   Platform/RaspberryPi/DualSerialPortLib: Always configure the pl011
>   Silicon/Broadcom/BcmGenetDxe: Suppress some bogus compiler warnings
>   Platform/RaspberryPi: Cleanup menu visibility
>   Platform/RaspberryPi: Give the user control over the XHCI mailbox
>   Platform/RaspberryPi: Update PCIe MMIO window for DT
>

Pushed patches #2 - #5. Thanks.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116636): https://edk2.groups.io/g/devel/message/116636
Mute This Topic: https://groups.io/mt/103796306/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/5] Platform/RaspberryPi/DualSerialPortLib: Always configure the pl011

[Ard Biesheuvel]

On Wed, 17 Jan 2024 at 22:36, Jeremy Linton  wrote:
>
> The rpi's config.txt controls which uart (pl011, or miniuart) is
> selected as the console. TFA and edk2 follow its lead, but if the
> miniuart is selected as the primary and the machine is booted in ACPI
> mode the baud/etc is never configured for the pl011. The linux kernel
> won't reconfigure it either as its listed as a "SBSA" uart, so it
> simply won't work.
>
> This re-enables BT on the pl011 in ACPI mode, and it somewhat starts
> to work again.
>
> Signed-off-by: Jeremy Linton 
> ---
>  .../DualSerialPortLib/DualSerialPortLib.c | 44 ---
>  1 file changed, 29 insertions(+), 15 deletions(-)
>
> diff --git 
> a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c 
> b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
> index d2f983bf0a..09d3e33c00 100644
> --- a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
> +++ b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
> @@ -76,6 +76,8 @@ SerialPortInitialize (
>EFI_PARITY_TYPE Parity;
>UINT8   DataBits;
>EFI_STOP_BITS_TYPE  StopBits;
> +  RETURN_STATUS   Ret;
> +  UINTN   Timeout;
>
>//
>// First thing we need to do is determine which of PL011 or miniUART is 
> selected
> @@ -85,23 +87,34 @@ SerialPortInitialize (
>  UsePl011UartSet = TRUE;
>}
>
> -  if (UsePl011Uart) {
> -BaudRate = FixedPcdGet64 (PcdUartDefaultBaudRate);
> +  // always init the pl011 on the RPi4, linux expects a SBSA uart to be at 
> 115200
> +  // this means we need to set the baud/etc even if we aren't using it as a 
> console
> +  if ((UsePl011Uart) || (RPI_MODEL == 4)) {
>  ReceiveFifoDepth = 0; // Use default FIFO depth
> +if (!UsePl011Uart)
> +{
> +  BaudRate = 115200;
> +}
> +else
> +{
> +  BaudRate = FixedPcdGet64 (PcdUartDefaultBaudRate);
> +}
>  Parity = (EFI_PARITY_TYPE)FixedPcdGet8 (PcdUartDefaultParity);
>  DataBits = FixedPcdGet8 (PcdUartDefaultDataBits);
>  StopBits = (EFI_STOP_BITS_TYPE) FixedPcdGet8 (PcdUartDefaultStopBits);
>
> -return PL011UartInitializePort (
> - PL011_UART_REGISTER_BASE,
> - PL011UartClockGetFreq(),
> - ,
> - ,
> - ,
> - ,
> - 
> - );
> -  } else {
> +Ret = PL011UartInitializePort (
> +   PL011_UART_REGISTER_BASE,
> +   PL011UartClockGetFreq(),
> +   ,
> +   ,
> +   ,
> +   ,
> +   
> +   );
> +  }
> +
> +  if (!UsePl011Uart) {
>  SerialRegisterBase = MINI_UART_REGISTER_BASE;
>  Divisor = SerialPortGetDivisor (PcdGet32 (PcdSerialBaudRate));
>
> @@ -127,7 +140,8 @@ SerialPortInitialize (
>  // Wait for the serial port to be ready.
>  // Verify that both the transmit FIFO and the shift register are empty.
>  //
> -while ((SerialPortReadRegister (SerialRegisterBase, R_UART_LSR) & 
> (B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) != (B_UART_LSR_TEMT | 
> B_UART_LSR_TXRDY));
> +Timeout = 1000;
> +while (((SerialPortReadRegister (SerialRegisterBase, R_UART_LSR) & 
> (B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) != (B_UART_LSR_TEMT | 
> B_UART_LSR_TXRDY)) && (Timeout--));
>

Why is this necessary, and what does it have to do with the rest of the patch?

>  //
>  // Configure baud rate
> @@ -158,9 +172,9 @@ SerialPortInitialize (
>  // Put Modem Control Register(MCR) into its reset state of 0x00.
>  //
>  SerialPortWriteRegister (SerialRegisterBase, R_UART_MCR, 0x00);
> -
> -return RETURN_SUCCESS;
> +Ret = RETURN_SUCCESS;
>}
> +  return Ret;
>  }
>
>  /**
> --
> 2.43.0
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116630): https://edk2.groups.io/g/devel/message/116630
Mute This Topic: https://groups.io/mt/103796307/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 3/4] StandaloneMmPkg: Support to unregister MMI handler inside MMI handler

[Ard Biesheuvel]

On Wed, 28 Feb 2024 at 03:28, Zhiguang Liu  wrote:
>
> To support unregister MMI handler inside MMI handler itself,
> get next node before MMI handler is executed, since LIST_ENTRY that
> Link points to may be freed if unregister MMI handler in MMI handler
> itself.
>
> Cc: Liming Gao 
> Cc: Jiaxin Wu 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> Signed-off-by: Zhiguang Liu 
> ---
>  StandaloneMmPkg/Core/Mmi.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>

Reviewed-by: Ard Biesheuvel 

> diff --git a/StandaloneMmPkg/Core/Mmi.c b/StandaloneMmPkg/Core/Mmi.c
> index 0de6fd17fc..c1a1d76e85 100644
> --- a/StandaloneMmPkg/Core/Mmi.c
> +++ b/StandaloneMmPkg/Core/Mmi.c
> @@ -154,9 +154,14 @@ MmiManage (
>  Head = >MmiHandlers;
>}
>
> -  for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
> +  for (Link = Head->ForwardLink; Link != Head;) {
>  MmiHandler = CR (Link, MMI_HANDLER, Link, MMI_HANDLER_SIGNATURE);
> -
> +//
> +// To support unregister MMI handler inside MMI handler itself,
> +// get next node before handler is executed, since LIST_ENTRY that
> +// Link points to may be freed if unregister MMI handler.
> +//
> +Link   = Link->ForwardLink;
>  Status = MmiHandler->Handler (
> (EFI_HANDLE)MmiHandler,
> Context,
> --
> 2.31.1.windows.1
>
>
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116629): https://edk2.groups.io/g/devel/message/116629
Mute This Topic: https://groups.io/mt/104616994/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel][PATCH v3 3/3] MdeModulePkg: DxeCore: Do Not Apply Guards to Unsupported Types

[Ard Biesheuvel]

On Sat, 9 Mar 2024 at 20:06, Oliver Smith-Denny
 wrote:
>
> Currently, there are multiple issues when page or pool guards are
> allocated for runtime memory regions that are aligned to
> non-EFI_PAGE_SIZE alignments. Multiple other issues have been fixed
> for these same systems (notably ARM64 which has a 64k runtime page
> allocation granularity) recently. The heap guard system is only built
> to support 4k guard pages and 4k alignment.
>
> Today, the address returned to a caller of AllocatePages will not be
> aligned correctly to the runtime page allocation granularity, because
> the heap guard system does not take non-4k alignment requirements into
> consideration.
>
> However, even with this bug fixed, the Memory Allocation Table cannot
> be produced and an OS with a larger than 4k page granularity will not
> have aligned memory regions because the guard pages are reported as
> part of the same memory allocation. So what would have been, on an
> ARM64 system, a 64k runtime memory allocation is actually a 72k
> memory allocation as tracked by the Page.c code because the guard
> pages are tracked as part of the same allocation. This is a core
> function of the current heap guard architecture.
>
> This could also be fixed with rearchitecting the heap guard system to
> respect alignment requirements and shift the guard pages inside of the
> outer rounded allocation or by having guard pages be the runtime
> granularity. Both of these approaches have issues. In the former case,
> we break UEFI spec 2.10 section 2.3.6 for AARCH64, which states that
> each 64k page for runtime memory regions may not have mixed memory
> attributes, which pushing the guard pages inside would create. In the
> latter case, an immense amount of memory is wasted to support such
> large guard pages, and with pool guard many systems could not support
> an additional 128k allocation for all runtime memory.
>
> The simpler and safer solution is to disallow page and pool guards for
> runtime memory allocations for systems that have a runtime granularity
> greater than the EFI_PAGE_SIZE (4k). The usefulness of such guards is
> limited, as OSes do not map guard pages today, so there is only boot
> time protection of these ranges. This also prevents other bugs from
> being exposed by using guards for regions that have a non-4k alignment
> requirement, as again, multiple have cropped up because the heap guard
> system was not built to support it.
>
> This patch adds both a static assert to ensure that either the runtime
> granularity is the EFI_PAGE_SIZE or that the PCD bits are not set to
> enable heap guard for runtime memory regions. It also adds a check in
> the page and pool allocation system to ensure that at runtime we are
> not allocating a runtime region and attempt to guard it (the PCDs are
> close to being removed in favor of dynamic heap guard configurations).
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4674
> Github PR: https://github.com/tianocore/edk2/pull/5382
>
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> Cc: Liming Gao 
>
> Signed-off-by: Oliver Smith-Denny 
> ---
>  MdeModulePkg/MdeModulePkg.dec | 10 ++
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.h | 14 ++++++
>  MdeModulePkg/Core/Dxe/Mem/Page.c  | 11 +++
>  MdeModulePkg/Core/Dxe/Mem/Pool.c  | 11 +++
>  4 files changed, 46 insertions(+)
>

Reviewed-by: Ard Biesheuvel 

> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index a2cd83345f5b..a82dedc070df 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -1027,6 +1027,11 @@ [PcdsFixedAtBuild]
># free pages for all of them. The page allocation for the type related to
># cleared bits keeps the same as ususal.
>#
> +  # The heap guard system only supports guarding EfiRuntimeServicesCode, 
> EfiRuntimeServicesData,
> +  # EfiReservedMemoryType, and EfiACPIMemoryNVS memory types for systems 
> that have
> +  # RUNTIME_PAGE_ALLOCATION_GRANULARITY == EFI_PAGE_SIZE. This is to 
> preserve alignment requirements
> +  # without extending the page guard size to very large granularities.
> +  #
># This PCD is only valid if BIT0 and/or BIT2 are set in 
> PcdHeapGuardPropertyMask.
>#
># Below is bit mask for this PCD: (Order is same as UEFI spec)
> @@ -1058,6 +1063,11 @@ [PcdsFixedAtBuild]
># if there's enough free memory for all of them. The pool allocation for 
> the
># type related to cleared bits keeps the same as ususal.
>#
> +  # The heap guard system only supports guarding EfiRuntimeServicesCode, 
> EfiRuntimeServicesData,
> +  # EfiReservedMemoryType, and EfiACPIMemoryNVS memo

Re: [edk2-devel] [PATCH] Maintainers.txt: remove Laszlo's entries

[Ard Biesheuvel]

On Fri, 8 Mar 2024 at 10:14, Laszlo Ersek  wrote:
>
> On 3/6/24 23:22, Michael D Kinney wrote:
> > Reviewed-by: Michael D Kinney 
>
> Merged as commit ccf91b518f22, via
> .
>
> Thank you all for everything,

Goodbye Laszlo. It was great to have you back, even if only for a short while.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116499): https://edk2.groups.io/g/devel/message/116499
Mute This Topic: https://groups.io/mt/104775206/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 05/10] ArmPlatformPkg: auto-generate SEC ProcessLibraryConstructorList() decl

[Ard Biesheuvel]

On Tue, 5 Mar 2024 at 12:39, Laszlo Ersek  wrote:
>
> Rely on AutoGen for declaring ProcessLibraryConstructorList().
>
> Build-tested with:
>
>   build -a AARCH64 -b DEBUG \
> -m ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf \
> -p ArmPlatformPkg/ArmPlatformPkg.dsc -t GCC5
>
>   build -a AARCH64 -b DEBUG \
> -m ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf \
> -p ArmPlatformPkg/ArmPlatformPkg.dsc -t GCC5
>
>   build -a AARCH64 -b DEBUG \
> -m ArmPlatformPkg/PrePi/PeiMPCore.inf \
> -p ArmPlatformPkg/ArmPlatformPkg.dsc -t GCC5
>
>   build -a AARCH64 -b DEBUG \
> -m ArmPlatformPkg/PrePi/PeiUniCore.inf \
>     -p ArmPlatformPkg/ArmPlatformPkg.dsc -t GCC5
>
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990
> Signed-off-by: Laszlo Ersek 
> ---
>  ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf  |  2 +-
>  ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf |  2 +-
>  ArmPlatformPkg/PrePi/PeiMPCore.inf  |  2 +-
>  ArmPlatformPkg/PrePi/PeiUniCore.inf |  2 +-
>  ArmPlatformPkg/PrePeiCore/PrePeiCore.h  | 10 --
>  ArmPlatformPkg/PrePi/PrePi.h        |  6 --
>  6 files changed, 4 insertions(+), 20 deletions(-)
>

Reviewed-by: Ard Biesheuvel 

> diff --git a/ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf 
> b/ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf
> index 4a3112b58dcb..c5cad7e37fbd 100644
> --- a/ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf
> +++ b/ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore.inf
> @@ -8,7 +8,7 @@
>  #**/
>
>  [Defines]
> -  INF_VERSION= 0x00010005
> +  INF_VERSION= 1.30
>BASE_NAME  = ArmPlatformPrePeiCore
>FILE_GUID  = b78d02bb-d0b5-4389-bc7f-b39ee846c784
>MODULE_TYPE= SEC
> diff --git a/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf 
> b/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
> index ab5bf1dac2d8..1d50b4d0b5f2 100644
> --- a/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
> +++ b/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore.inf
> @@ -8,7 +8,7 @@
>  #**/
>
>  [Defines]
> -  INF_VERSION= 0x00010005
> +  INF_VERSION= 1.30
>BASE_NAME  = ArmPlatformPrePeiCore
>FILE_GUID  = 469fc080-aec1-11df-927c-0002a5d5c51b
>MODULE_TYPE= SEC
> diff --git a/ArmPlatformPkg/PrePi/PeiMPCore.inf 
> b/ArmPlatformPkg/PrePi/PeiMPCore.inf
> index a613b24c340e..0b13b723539c 100644
> --- a/ArmPlatformPkg/PrePi/PeiMPCore.inf
> +++ b/ArmPlatformPkg/PrePi/PeiMPCore.inf
> @@ -8,7 +8,7 @@
>  #**/
>
>  [Defines]
> -  INF_VERSION= 0x00010005
> +  INF_VERSION= 1.30
>BASE_NAME  = ArmPlatformPrePiMPCore
>FILE_GUID  = d959e387-7b91-452c-90e0-a1dbac90ddb8
>MODULE_TYPE= SEC
> diff --git a/ArmPlatformPkg/PrePi/PeiUniCore.inf 
> b/ArmPlatformPkg/PrePi/PeiUniCore.inf
> index b62ea3c485bd..2e237172d571 100644
> --- a/ArmPlatformPkg/PrePi/PeiUniCore.inf
> +++ b/ArmPlatformPkg/PrePi/PeiUniCore.inf
> @@ -9,7 +9,7 @@
>  #**/
>
>  [Defines]
> -  INF_VERSION= 0x00010005
> +  INF_VERSION= 1.30
>BASE_NAME  = ArmPlatformPrePiUniCore
>FILE_GUID  = 3e401783-cc94-4fcd-97bc-bd35ac369d2f
>MODULE_TYPE= SEC
> diff --git a/ArmPlatformPkg/PrePeiCore/PrePeiCore.h 
> b/ArmPlatformPkg/PrePeiCore/PrePeiCore.h
> index c1e13e23e11e..fbf6207db816 100644
> --- a/ArmPlatformPkg/PrePeiCore/PrePeiCore.h
> +++ b/ArmPlatformPkg/PrePeiCore/PrePeiCore.h
> @@ -73,14 +73,4 @@ PeiCommonExceptionEntry (
>IN UINTN   LR
>);
>
> -/*
> - * Autogenerated function that calls the library constructors for all of the
> - * module's dependent libraries.
> - */
> -VOID
> -EFIAPI
> -ProcessLibraryConstructorList (
> -  VOID
> -  );
> -
>  #endif
> diff --git a/ArmPlatformPkg/PrePi/PrePi.h b/ArmPlatformPkg/PrePi/PrePi.h
> index 6074a22108d2..1d47ba26be3a 100644
> --- a/ArmPlatformPkg/PrePi/PrePi.h
> +++ b/ArmPlatformPkg/PrePi/PrePi.h
> @@ -79,10 +79,4 @@ ArchInitialize (
>VOID
>);
>
> -VOID
> -EFIAPI
> -ProcessLibraryConstructorList (
> -  VOID
> -  );
> -
>  #endif /* _PREPI_H_ */
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116389): https://edk2.groups.io/g/devel/message/116389
Mute This Topic: https://groups.io/mt/104742525/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 06/10] ArmVirtPkg: auto-generate SEC ProcessLibraryConstructorList() decl

[Ard Biesheuvel]

On Tue, 5 Mar 2024 at 12:39, Laszlo Ersek  wrote:
>
> Rely on AutoGen for declaring ProcessLibraryConstructorList().
>
> Build-tested with:
>
>   build -a AARCH64 -b DEBUG \
> -m ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf \
> -p ArmVirtPkg/ArmVirtKvmTool.dsc -t GCC5
>
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Cc: Leif Lindholm 
> Cc: Sami Mujawar 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990
> Signed-off-by: Laszlo Ersek 
> ---
>  ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf | 2 +-
>  ArmVirtPkg/PrePi/PrePi.c| 6 --
>  2 files changed, 1 insertion(+), 7 deletions(-)
>

Reviewed-by: Ard Biesheuvel 


> diff --git a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf 
> b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
> index 6b9244bd1a6b..578ee37e7467 100755
> --- a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
> +++ b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
> @@ -8,7 +8,7 @@
>  #**/
>
>  [Defines]
> -  INF_VERSION= 0x00010005
> +  INF_VERSION= 1.30
>BASE_NAME  = ArmVirtPrePiUniCoreRelocatable
>FILE_GUID  = f7d9fd14-9335-4389-80c5-334d6abfcced
>MODULE_TYPE= SEC
> diff --git a/ArmVirtPkg/PrePi/PrePi.c b/ArmVirtPkg/PrePi/PrePi.c
> index ff51a757a21a..f27e0ad3d223 100755
> --- a/ArmVirtPkg/PrePi/PrePi.c
> +++ b/ArmVirtPkg/PrePi/PrePi.c
> @@ -22,12 +22,6 @@
>
>  #include "PrePi.h"
>
> -VOID
> -EFIAPI
> -ProcessLibraryConstructorList (
> -  VOID
> -  );
> -
>  VOID
>  PrePiMain (
>IN  UINTN   UefiMemoryBase,
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116388): https://edk2.groups.io/g/devel/message/116388
Mute This Topic: https://groups.io/mt/104742526/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms PATCH v2 1/4] BeagleBoardPkg: auto-generate SEC ProcessLibraryConstructorList() decl

[Ard Biesheuvel]

On Tue, 5 Mar 2024 at 13:01, Laszlo Ersek  wrote:
>
> Rely on AutoGen for declaring ProcessLibraryConstructorList().
>
> Build-tested with:
>
>   build -a ARM -b DEBUG \
> -m Platform/BeagleBoard/BeagleBoardPkg/PrePi/PeiUniCore.inf \
> -p Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.dsc -t GCC5
>
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>  Platform/BeagleBoard/BeagleBoardPkg/PrePi/PeiUniCore.inf | 2 +-
>  Platform/BeagleBoard/BeagleBoardPkg/PrePi/PrePi.h| 6 --
>  2 files changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/Platform/BeagleBoard/BeagleBoardPkg/PrePi/PeiUniCore.inf 
> b/Platform/BeagleBoard/BeagleBoardPkg/PrePi/PeiUniCore.inf
> index 414091957cb2..03d8f4daab48 100644
> --- a/Platform/BeagleBoard/BeagleBoardPkg/PrePi/PeiUniCore.inf
> +++ b/Platform/BeagleBoard/BeagleBoardPkg/PrePi/PeiUniCore.inf
> @@ -9,7 +9,7 @@
>  #**/
>
>  [Defines]
> -  INF_VERSION= 0x0001001A
> +  INF_VERSION= 1.30
>BASE_NAME  = BeagleBoardPrePiUniCore
>FILE_GUID  = 8a5dc3de-fe31-4ad9-9c93-dd73626932e7
>MODULE_TYPE= SEC
> diff --git a/Platform/BeagleBoard/BeagleBoardPkg/PrePi/PrePi.h 
> b/Platform/BeagleBoard/BeagleBoardPkg/PrePi/PrePi.h
> index b64dd764a435..a2932f0f5116 100644
> --- a/Platform/BeagleBoard/BeagleBoardPkg/PrePi/PrePi.h
> +++ b/Platform/BeagleBoard/BeagleBoardPkg/PrePi/PrePi.h
> @@ -81,10 +81,4 @@ ArchInitialize (
>VOID
>);
>
> -VOID
> -EFIAPI
> -ProcessLibraryConstructorList (
> -  VOID
> -  );
> -
>  #endif /* _PREPI_H_ */
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116387): https://edk2.groups.io/g/devel/message/116387
Mute This Topic: https://groups.io/mt/104742757/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel][PATCH v1 1/3] MdeModulePkg: ImagePropertiesRecordLib: Use SectionAlignment for CodeSize

[Ard Biesheuvel]

On Mon, 4 Mar 2024 at 18:49, Oliver Smith-Denny
 wrote:
>
> Hi Ard,
>
> On 3/1/2024 3:58 AM, Ard Biesheuvel wrote:
> > Hi Oliver,
> >
> > On Tue, 27 Feb 2024 at 21:27, Oliver Smith-Denny
> >  wrote:
> >>
> >> When an ImageRecord is stored by ImagePropertiesRecordLib, it reports the
> >> CodeSegmentSize as the SizeOfRawData from the image. However, the image
> >> as loaded into memory is aligned to the SectionAlignment, so
> >> SizeOfRawData is under the actual size in memory. This is important,
> >> because the memory attributes table uses these image records to create
> >> its entries and it will report that the alignment of an image is
> >> incorrect, even though the actual image is correct.
> >>
> >> This was discovered on ARM64, which has a 64k runtime page granularity
> >> alignment, which is backed by a 64k section alignment for
> >> DXE_RUNTIME_DRIVERs. The runtime code and data was correctly being
> >> loaded into memory, however the memory attribute table was incorrectly
> >> reporting misaligned ranges to the OS, causing attributes to be
> >> ignored for these sections for OSes using greater than 4k pages.
> >>
> >> This patch correctly aligns the CodeSegmentSize to the SectionAlignment
> >> and the corresponding memory attribute table entries are now correctly
> >> aligned and pointing to the right places in memory.
> >>
> >
> > Can you explain how these can differ in the first place? Our flaky
> > ELF-to-PE/COFF converter should never generate such images to begin
> > with (which is probably how we ended up with this problem in the first
> > place), so I  suppose this is native PE/COFF tooling emitting sections
> > either using a non-1:1 file:memory mapping, or with unallocated holes
> > in the file representation?
> >
>
> This is an artifact of PE/COFF itself and is useful for having smaller
> FW images. In PE/COFF we have the section alignment (which is how we get
> loaded into memory) and the file alignment (how the actual file is
> aligned). It is valid for these two to be different. For example, these
> runtime DXE drivers, which are not XIP (which the case we do need the
> section and file alignment to be the same, as we are executing from
> the file image) can be a smaller size in the file, but when loaded into
> memory we will relocate them and do the proper rebasing to set these on
> 64k boundaries. Different toolchains have different ways of specifying
> the two things, on gcc I have seen common-page-size affect the section
> alignment and max-page-size affect both section and file alignment. For
> msvc there are /ALIGN and /FILEALIGN commands which directly manipulate
> these values.
>
> The issue here was not that we have different section and file
> alignment, in fact, the issue still exists if section alignement ==
> file alignment. This is because SizeOfRawData in the PE/COFF header is
> the raw size of bytes used, not even page aligned. So no matter what,
> the image records we were creating here had bad sizes being set which
> do not match what the image loader was actually doing.
>

IIUC the SizeOfRawData is the file view not the memory view, and must
always be aligned to the FileAlignment.

> I do think there is a fair argument that would say the image loader
> should create the image records when it loads images, since in the
> end we want the record to match exactly what the image in memory is,
> creating after the fact is a poor pattern.
>

Yeah, no disagreement there.

> >> Cc: Liming Gao 
> >> Cc: Leif Lindholm 
> >> Cc: Ard Biesheuvel 
> >> Cc: Sami Mujawar 
> >> Cc: Taylor Beebe 
> >>
> >> Signed-off-by: Oliver Smith-Denny 
> >> ---
> >>   MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c 
> >> | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git 
> >> a/MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c 
> >> b/MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c
> >> index e53ce086c54c..07ced0e54e38 100644
> >> --- 
> >> a/MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c
> >> +++ 
> >> b/MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c
> >> @@ -1090,7 +1090,7 @@ CreateImagePropertiesRecord (
> >> ImageRecordCodeSection->Signature = 
> >> IMAGE_PROPERTIES_RECORD_CODE_SECTION_SIGNATURE;
> >>
> >> ImageRecordCodeSection->CodeSegmentBase = 

Re: [edk2-devel] [edk2][PATCH V2 1/2] ArmPkg/ArmGicArchLib: Add macros for SPI and extended SPI ranges

[Ard Biesheuvel]

On Wed, 28 Feb 2024 at 17:59, Sami Mujawar  wrote:
>
> +Resending with email address for maintainers.
>
>
>
> Hi Ard, Leif,
>
> This patch adds macros that can be used to validate that the SPI ranges are 
> valid.
> These have been define here so that we do not duplicate it at multiple places.
>
> Can you let me know if I can merge this patch, please?
>

I have no problems with that, please go ahead.

Acked-by: Ard Biesheuvel 

I will note that we will have to clean this up in the future, though:
the architected GIC pieces should not be part of a library header, but
a separate IndustryStandard/ header that is separate from the GIC
library code. But that can wait until later.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116259): https://edk2.groups.io/g/devel/message/116259
Mute This Topic: https://groups.io/mt/103518972/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel][PATCH v1 1/3] MdeModulePkg: ImagePropertiesRecordLib: Use SectionAlignment for CodeSize

[Ard Biesheuvel]

Hi Oliver,

On Tue, 27 Feb 2024 at 21:27, Oliver Smith-Denny
 wrote:
>
> When an ImageRecord is stored by ImagePropertiesRecordLib, it reports the
> CodeSegmentSize as the SizeOfRawData from the image. However, the image
> as loaded into memory is aligned to the SectionAlignment, so
> SizeOfRawData is under the actual size in memory. This is important,
> because the memory attributes table uses these image records to create
> its entries and it will report that the alignment of an image is
> incorrect, even though the actual image is correct.
>
> This was discovered on ARM64, which has a 64k runtime page granularity
> alignment, which is backed by a 64k section alignment for
> DXE_RUNTIME_DRIVERs. The runtime code and data was correctly being
> loaded into memory, however the memory attribute table was incorrectly
> reporting misaligned ranges to the OS, causing attributes to be
> ignored for these sections for OSes using greater than 4k pages.
>
> This patch correctly aligns the CodeSegmentSize to the SectionAlignment
> and the corresponding memory attribute table entries are now correctly
> aligned and pointing to the right places in memory.
>

Can you explain how these can differ in the first place? Our flaky
ELF-to-PE/COFF converter should never generate such images to begin
with (which is probably how we ended up with this problem in the first
place), so I  suppose this is native PE/COFF tooling emitting sections
either using a non-1:1 file:memory mapping, or with unallocated holes
in the file representation?

> Cc: Liming Gao 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> Cc: Taylor Beebe 
>
> Signed-off-by: Oliver Smith-Denny 
> ---
>  MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c | 2 
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git 
> a/MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c 
> b/MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c
> index e53ce086c54c..07ced0e54e38 100644
> --- a/MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c
> +++ b/MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.c
> @@ -1090,7 +1090,7 @@ CreateImagePropertiesRecord (
>ImageRecordCodeSection->Signature = 
> IMAGE_PROPERTIES_RECORD_CODE_SECTION_SIGNATURE;
>
>ImageRecordCodeSection->CodeSegmentBase = (UINTN)ImageBase + 
> Section[Index].VirtualAddress;
> -  ImageRecordCodeSection->CodeSegmentSize = Section[Index].SizeOfRawData;
> +  ImageRecordCodeSection->CodeSegmentSize = ALIGN_VALUE 
> (Section[Index].SizeOfRawData, SectionAlignment);
>

This should be the virtual size, not the file size, right?

>InsertTailList (>CodeSegmentList, 
> >Link);
>ImageRecord->CodeSegmentCount++;
> --
> 2.40.1
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116237): https://edk2.groups.io/g/devel/message/116237
Mute This Topic: https://groups.io/mt/104610770/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch 3/4] BaseTools/Scripts/PatchCheck: Error if no Cc tags are present

[Ard Biesheuvel]

On Wed, 21 Feb 2024 at 23:16, Laszlo Ersek  wrote:
>
> On 2/20/24 15:48, Ard Biesheuvel wrote:
> > Hello Mike,
> >
> > I understand the desire to be pedantic about cc'ing the right
> > maintainers, but I'm not convinced this is the way.
> >
> > - the presence of a cc: tag does not guarantee that the person was
> > cc'ed - only git send-email will take CC:s in the message body into
> > account by default (but this can also be disabled), but generally, the
> > sender has to ensure the cc list is copied into the cc: field
> > - the absence of a cc: tag does not imply that the person was not cc'ed,
> >
> > - in Linux, the cc: tag has slightly different semantics from the ones
> > we appear to be assuming here: a cc tag in patch going into the
> > repository is a statement by the maintainer that the person in
> > question has been cc'ed, may have some 'jurisdiction' over the area,
> > but hasn't bothered to respond. IOW, it is to record the fact that
> > this person has been given the opportunity to respond.
> >
> > Then there is the matter of a maintainer that has reviewed the patch
> > themselves. I usually remove the cc lines listing people that have
> > reviewed/acked/tested the patch, as those tags already convey that the
> > person is aware of it cc'ed or not.
>
> I've noticed this (on patches you merged), and -- not having similar
> maintainer experience in Linux -- I was surprised. I more or less
> deduced the intent, but it felt a bit foreign (or at least novel!) to edk2.
>
> To me, the greatest benefits of Cc's in commit messages are (as opposed
> to command line specified Cc's):
>
> - fine-grained: each patch can target a specific set of reviewers /
> maintainers,
>
> - long-lived: the CC list survives rebases / v2, v3 etc iterations! (Of
> course, if a patch undergoes serious scope changes when revised, then
> the Cc list will have to be updated manually. But that's quite rare.)
>
> >
> > So perhaps it would be better to make this check part of the
> > contributor workflow but not the GitHub PR/CI workflow?
>
> I agree that adding Cc's to the commit message body is not fool-proof
> (like you explain), but like Mike, I have no better idea for preventing
> contributors from posting patches without properly CC'ing
> reviewers/maintainers (be it with whatever particular CC'ing method they
> prefer).
>
> I tend to run PatchCheck locally (not solely relying on CI for that --
> PatchCheck is quick and has no intrusive dependencies, plus seeing CI
> fail just because of PatchCheck is super irritating), so in my workflow,
> this patch would fit well. Of course, with the same effort of
> remembering to run PatchCheck locally, I also remember to add Cc's in
> the first place...
>
> I admit that reviewer assignment is a significant shortcoming of the
> email-based workflow. What we'd really need is a groups.io-level action
> :) -- if the subject contains PATCH or Patch in brackets, but the body
> lacks ^Cc or ^CC, *reject* the email. (Rejection gives the sender an
> explanation.) Alas, rejection is currently only a manual action that's
> available to moderators (and only on messages for senders that have not
> been unmoderated yet).
>
> So, my take: not perfect, but much better than nothing.
>

Yeah, I can't argue with that. I agree that it is very annoying that
patches don't get cc'ed to the right people. (It is even more annoying
that many maintainers [including myself at times - mea culpa] don't
bother to respond, but that is a different matter)

So let's try this, and in case it does more harm than good, we can
always back it out again (or make modifications to the logic)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115752): https://edk2.groups.io/g/devel/message/115752
Mute This Topic: https://groups.io/mt/104434584/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Merge commit in edk2-non-osi

[Ard Biesheuvel]

On Wed, 21 Feb 2024 at 16:05, Michael D Kinney
 wrote:
>
> Hi Ard,
>
> I disagree.  We have never allowed a force push to the main
> branch of TianoCore repos.  This has happened before and
> was discussed and the policy is to not fix.  Even the edk2
> repo has some merge commits in its history that were discussed
> and not fixed.
>
> We can never know how many downstream consumers are syncing
> with main branches.
>

Fair enough. Better to be cautious, and my argument works both ways:
the contents would not change by 'fixing' the history, and this change
does not look problematic for bisect.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115751): https://edk2.groups.io/g/devel/message/115751
Mute This Topic: https://groups.io/mt/104481195/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel][PATCH v2 0/3] Fix Runtime Granularity Issues

[Ard Biesheuvel]

On Sat, 17 Feb 2024 at 02:27, Oliver Smith-Denny
 wrote:
>
> This patch series is the second version of
> MdeModulePkg: DxeCore: Don't Guard Large Runtime Granularity Allocations.
> The subject line has been updated because this went from a one commit
> patch with no cover letter to a multi-commit patch.
>
> The commit messages cover the vast amount of detail here, but this
> patchset fixes three issues:
> - a UEFI spec violation for which memory types require runtime page
> allocation granularity alignment
> - An incompatibility of the heap guard system to guard these regions
> that require runtime page allocation granularities greater than
> the EFI_PAGE_SIZE.
> - A CodeQL error that fails CI when updating the Page.c code
>
> v2:
> - Add commit to fix UEFI spec violation
> - Add commit to fix newly flagged CodeQL error
> - Update guard commit message, comments, and static assert to use
> the correct types
>
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> Cc: Liming Gao 
>
> Oliver Smith-Denny (3):
>   MdeModulePkg: DxeCore: Fix CodeQL Error in FreePages
>   MdeModulePkg: DxeCore: Correct Runtime Granularity Memory Type
>   MdeModulePkg: DxeCore: Do Not Apply Guards to Unsupported Types
>

Reviewed-by: Ard Biesheuvel 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115727): https://edk2.groups.io/g/devel/message/115727
Mute This Topic: https://groups.io/mt/104405577/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 0/6] OvmfPkg: Add support for 5-level paging

[Ard Biesheuvel]

On Tue, 20 Feb 2024 at 10:06, Gerd Hoffmann  wrote:
>
> Patch #1 + #2 fix MdeModulePkg/DxeIplPeim to not assert in case a
> 5-level enabled build runs in 4-level paging mode.
>
> Patch #2 - #4 update OvmfPkg ResetVector, adding support for 5-level
> paging (setup 5-level page tables in case both la57 and gigabyte pages
> are supported by the vCPU).
>
> Patch #5 updates PlatformInitLib for 5-level paging support (update
> PhysBits calculation).
>
> Known issues / limitations:
>  - BaseMemEncryptSevLib must be updated to also support 5-level
>paging for full 5-level paging support in SEV mode.
>
> The patch series does *not* enable 5-level paging by default.
> Building with 5-level paging support can be done by compiling
> OVMF with '--pcd PcdUse5LevelPageTable=TRUE'.
>
> v3:
>  - add resetvector fixes for sev and tdx
> v2 changes:
>  - fix sev/tdx handling with 5-level paging.
>  - more comments for 5-level page table setup.
>  - improve PAGE_* naming (new patch #3).
>  - rename Page5LevelSupported to Page5LevelEnabled (new patch #2).
>  - pick up some review tags.
>
> Gerd Hoffmann (6):
>   MdeModulePkg/DxeIplPeim: fix PcdUse5LevelPageTable assert
>   MdeModulePkg/DxeIplPeim: rename variable
>   OvmfPkg/ResetVector: improve page table flag names
>   OvmfPkg/ResetVector: SEV: keep #vc handler installed longer
>   OvmfPkg/ResetVector: add 5-level paging support
>   OvmfPkg/PlatformInitLib: add 5-level paging support
>

I'm fine with all this but I haven't looked in great detail, so

Acked-by: Ard Biesheuvel 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115726): https://edk2.groups.io/g/devel/message/115726
Mute This Topic: https://groups.io/mt/104464306/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Merge commit in edk2-non-osi

[Ard Biesheuvel]

On Wed, 21 Feb 2024 at 02:49, Nate DeSimone
 wrote:
>
> Hi Everyone,
>
> It appears that a merge commit was introduced to edk2-non-osi due to a PR 
> merge:
>
> https://github.com/tianocore/edk2-non-osi/commit/61b65fccfe4c75bc9ecb7b542412a436e3db5de6
>
> I would like to remind everyone that we generally don't accept submissions 
> via PRs yet. At the very least please click "Rebase and merge" when closing 
> the PR instead of "Merge pull request". Since that merge commit is currently 
> at the top of the tree, can we delete it?
>


I think force rebasing is fine in this particular case - the file
contents will remain the same, it is just the git history that gets
linearized, so everyone that pulls from it should get the expected
results.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115719): https://edk2.groups.io/g/devel/message/115719
Mute This Topic: https://groups.io/mt/104481195/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-