Hi,
> > I'm with you on that. Unfortunately the boot loader team is not.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2108083
> >
> > tl;dr: You can't boot Fedora in secure boot mode without microsoft keys
> > today. grub.efi refuses to work without shim.efi, and shim.efi exists
> > onl
Hi,
> I know of 3 categories:
>
> 1) U-Boot
> 2) EC2
> 3) Windows ARM notebooks
Thanks.
> > Well, no. One problem is install media, where you really have only
> > one entry point (EFI/BOOT/BOOT${ARCH}.EFI) which must work under all
> > circumstances. Which must be shim with microsoft signat
Extend the ValidateFvHeader function, additionally to the header checks
walk over the list of variables and sanity check them.
In case we find inconsistencies indicating variable store corruption
return EFI_NOT_FOUND so the variable store will be re-initialized.
Signed-off-by: Gerd Hoffmann
--- cut here
>From c174197c65d2346f519418ded2e645d57423be41 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann
Date: Wed, 6 Dec 2023 13:00:53 +0100
Subject: [PATCH 1/1] ArmVirtPkg: add runtime option to enable/disable
MemoryAttributesProtocol
Based on a patch by Ard
Hi,
> But what we might do is invent a way to avoid setting the XP attribute
> on the entire region based on some heuristic. Given that the main
> purpose of the EFI memory attribute protocol is to provide the ability
> to remove XP (and set RO instead), perhaps we can avoid the set
> entirely?
On Thu, Dec 07, 2023 at 08:40:55AM +, Mike Beaton wrote:
> From commit
> https://github.com/tianocore/edk2/commit/140e4422b16482f0bcafdc20d42141434d450450
> (and see also the preceding commit, which I believe is related) up to
> the current tip of master, CLANGDWARF OVMF is broken. It builds a
Hi,
> > + default:
> > +DEBUG ((
> > + DEBUG_ERROR,
> > + "%a: invalid variable state: 0x%x\n",
> > + __func__,
> > + VarState
> > + ));
>
> Did you want to print VarHeader->State?
Yes, indeed. Good catch, thank you, will fix send send
Extend the ValidateFvHeader function, additionally to the header checks
walk over the list of variables and sanity check them.
In case we find inconsistencies indicating variable store corruption
return EFI_NOT_FOUND so the variable store will be re-initialized.
Signed-off-by: Gerd Hoffmann
On Thu, Dec 07, 2023 at 05:16:10PM +0100, Ard Biesheuvel wrote:
> Hi Gerd,
>
> On Thu, 7 Dec 2023 at 10:44, Gerd Hoffmann wrote:
> >
> > Extend the ValidateFvHeader function, additionally to the header checks
> > walk over the list of variables and sanity check th
On Thu, Dec 07, 2023 at 11:06:03AM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel
>
> Shim's PE loader uses the EFI memory attributes protocol in a way that
> results in an immediate crash when invoking the loaded image, unless the
> base and size of its executable segment are both aligned t
Hi,
> OK, so not worth the trouble of trying to detect the first boot, I guess.
>
> For my info, is rhel-9.3 an old GRUB?
2.06 with a huge stack of downstream patches.
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online
> + //
> + // Work around shim's terminally broken use of the EFI memory attributes
> + // protocol, by uninstalling it if requested on the QEMU command line.
> + //
> + // E.g.,
> + // -fw_cfg opt/org.tianocore/UninstallMemAttrProtocol,string=y
> + //
> + // This is only needed on th
d a PCD to set the default for
> this option when it is omitted.
>
> -fw_cfg opt/org.tianocore/UninstallMemAttrProtocol,string=y
Tested-by: Gerd Hoffmann
Reviewed-by: Gerd Hoffmann
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this gr
Hi,
> The general idea is, once we don't trust the varstore, there cannot be
> a *single* unchecked addition in the code. (Unless we can *prove* that
> overflow is impossible.)
There are some cases where we add a small, constant number to a value we
know is smaller than VariableStoreHeader->Si
Extend the ValidateFvHeader function, additionally to the header checks
walk over the list of variables and sanity check them.
In case we find inconsistencies indicating variable store corruption
return EFI_NOT_FOUND so the variable store will be re-initialized.
Signed-off-by: Gerd Hoffmann
Hi,
> Second (and worse): the bug. In "OvmfPkg/RiscVVirt/VarStore.fdf.inc", it
> turns out that we *still* generate the gEfiVariableGuid varstore header
> signature, in case SECURE_BOOT_ENABLE is FALSE. For some reason, commit
> 92b27c2e6ada ("OvmfPkg/RiscVVirt: Add build files for Qemu Virt
> p
Hi,
> >> - if the StartId is 0x55aa, then we need to look further, beause we
> >> can't decide yet. For example, if State is VAR_HEADER_VALID_ONLY (0x7f),
> >> then it might be fine for the variable header (at the very end of the
> >> varstore) *not* to be followed by payload bytes (name, data).
v4:
- turn into a little patch series.
- stop using gEfiVariableGuid in risc-v.
- stop accepting gEfiVariableGuid in VirtNorFlashDxe.
- refine variable checking.
Gerd Hoffmann (3):
OvmfPkg/RiscVVirt: use gEfiAuthenticatedVariableGuid unconditionally
OvmfPkg/VirtNorFlashDxe: stop accepting
ArmVirt and OVMF are doing the same.
See commit d92eaabefbe0 ("OvmfPkg: simplify VARIABLE_STORE_HEADER
generation") for details.
Suggested-by: László Érsek
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/RiscVVirt/VarStore.fdf.inc | 9 +
1 file changed, 1 insertion(+), 8 deletion
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
index 5ee98e9b595a..9a614ae4b24d 100644
--- a/OvmfPkg
Extend the ValidateFvHeader function, additionally to the header checks
walk over the list of variables and sanity check them.
In case we find inconsistencies indicating variable store corruption
return EFI_NOT_FOUND so the variable store will be re-initialized.
Signed-off-by: Gerd Hoffmann
Extend the ValidateFvHeader function, additionally to the header checks
walk over the list of variables and sanity check them.
In case we find inconsistencies indicating variable store corruption
return EFI_NOT_FOUND so the variable store will be re-initialized.
Signed-off-by: Gerd Hoffmann
ArmVirt and OVMF are doing the same.
See commit d92eaabefbe0 ("OvmfPkg: simplify VARIABLE_STORE_HEADER
generation") for details.
Suggested-by: László Érsek
Signed-off-by: Gerd Hoffmann
Reviewed-by: Sunil V L
Reviewed-by: Laszlo Ersek
---
OvmfPkg/RiscVVirt/VarStore.fdf.inc | 9 +-
v5:
- pick up review tags
- more variable check fine tuning.
v4:
- turn into a little patch series.
- stop using gEfiVariableGuid in risc-v.
- stop accepting gEfiVariableGuid in VirtNorFlashDxe.
- refine variable checking.
Gerd Hoffmann (3):
OvmfPkg/RiscVVirt: use
Signed-off-by: Gerd Hoffmann
Reviewed-by: Laszlo Ersek
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
index 5ee98e9b595a..9a614ae4b24d
Hi,
> Nit: to my knowledge, the coding style forbids initialization of "auto"
> storage class variables (more commonly put, "non-static local
> variables"). IOW, we should spell the above as:
>
> | diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
> b/OvmfPkg/VirtNorFlashDxe/VirtNorFlashF
On Wed, Jan 10, 2024 at 04:05:44PM +0800, Dun Tan wrote:
> When creating smm page table, limit maximum
> supported physical address bits returned by
> CalculateMaximumSupportAddress() to 48 if
> 5-Level Paging is disabled.
> When 5-Level Paging is disabled and the
> PhysicalAddressBits retrived fro
On Thu, Jan 11, 2024 at 04:59:47PM +0800, Dun Tan wrote:
> When creating smm page table, limit maximum
> supported physical address bits returned by
> CalculateMaximumSupportAddress() to 47 if
> 5-Level Paging is disabled.
> When 5-Level Paging is disabled and the
> PhysicalAddressBits retrived fro
odulePkg/Hob: Integer Overflow in CreateHob()
Series:
Acked-by: Gerd Hoffmann
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113614): https://edk2.groups.io/g/devel/message/113614
Mute This Topic: https://groups.io/mt/103658961/21656
,
which in turn can corrupt both the variable store and the
FTW work space.
This patch fixes the calculation.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
b
On Fri, Jan 12, 2024 at 10:47:43AM +0100, Laszlo Ersek wrote:
> On 1/11/24 14:36, Gerd Hoffmann wrote:
> > In some cases (specifically when the flash update region is
> > small but crosses a multiple of P30_MAX_BUFFER_SIZE_IN_BYTES)
> > NorFlashWriteSingleBlock reads on
This is a little series containing the flash corruption fix sent
yesterday with an slightly improved commit message and some small
improvements on top of this.
Gerd Hoffmann (4):
OvmfPkg/VirtNorFlashDxe: fix shadowbuffer reads
OvmfPkg/VirtNorFlashDxe: clarify block write logic
OvmfPkg
,
which in turn can corrupt both the variable store and the
FTW work space. One observed corruption pattern is finding
0xaf (aka PcdDebugClearMemoryValue) right after the last
entry in the FTW log. This should have been 0xff.
This patch fixes the calculation.
Signed-off-by: Gerd Hoffmann
patch
does not actually change the size limit.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 31 +-
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
: Gerd Hoffmann
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
index 90db12716a4c..c631ffd3a62d 100644
--- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
+++ b
It is possible to find variable entries with State being 0xff,
i.e. not updated since flash block erase. This indicates the
header write was not completed (and therefore State was not set
to VAR_HEADER_VALID_ONLY). Treat this as additional "end of
variable list" condition.
Signed-of
Hi,
> diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
> index af594959a9..b522fa1059 100644
> --- a/OvmfPkg/CloudHv/CloudHvX64.dsc
> +++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
> @@ -566,6 +566,8 @@
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
>gEfiMdeMo
PhysicalAddressBits = 47;
> + }
Nice.
Reviewed-by: Gerd Hoffmann
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113723): https://edk2.groups.io/g/devel/message/113723
Mute This Topic: https://groups.io/mt/103679520/2
On Fri, Jan 12, 2024 at 01:16:47PM +0100, Ard Biesheuvel wrote:
> On Fri, 12 Jan 2024 at 12:38, Gerd Hoffmann wrote:
> >
> > It is possible to find variable entries with State being 0xff,
> > i.e. not updated since flash block erase. This indicates the
> > header w
CloudHv guests because the PlatformScanE820
> utility is not currently supported for CloudHv.
>
> My working branch for these changes can be found here:
> https://github.com/thomasbarrett/edk2/tree/cloud-hv-1tb-ram
>
> Cc: Anatol Belski
> Cc: Ard Biesheuvel
> Cc: Gerd Hoffma
This is needed to avoid bit operations being applied to signed integers.
Suggested-by: László Érsek
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.h | 2 +-
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a
patch splitting the DoErase code path into a new function.
- add the diagram sent by Laszlo.
Gerd Hoffmann (6):
OvmfPkg/VirtNorFlashDxe: add casts to UINTN and UINT32
OvmfPkg/VirtNorFlashDxe: clarify block write logic & fix shadowbuffer
reads
OvmfPkg/VirtNorFlashDxe: add a loop
: Gerd Hoffmann
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
index 54251633d0ee..67610d6920f7 100644
--- a/OvmfPkg/VirtNorFlashDxe
: Gerd Hoffmann
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
index 67610d6920f7..d80e9f0a2f3a 100644
--- a/OvmfPkg/VirtNorFlashDxe
Move the DoErase code block into a separate function, call the function
instead of jumping around with goto.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 76 +-
1 file changed, 51 insertions(+), 25 deletions(-)
diff --git a/OvmfPkg
of the variable list, so treat this as
additional "end of variable list" condition.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
b/OvmfPkg/VirtN
l read only one instead of two
P30_MAX_BUFFER_SIZE_IN_BYTES blocks in case '*NumBytes' is smaller than
P30_MAX_BUFFER_SIZE_IN_BYTES but 'Offset + *NumBytes' is not, i.e. the
update range crosses a P30_MAX_BUFFER_SIZE_IN_BYTES boundary.
Signed-off-by: Gerd Hoffmann
Hi,
> Right, I have the same question -- although, admittedly, I've not been
> CC'd on the cover letter (0/6), and the reason could be captured there.
It wasn't.
> On a second thought, I'm (retroactively?) surprised that
> LocalApicTimerDxe was (apparently?) first introduced under OvmfPkg --
>
On Tue, Jan 16, 2024 at 12:31:21PM +0530, Abdul Lateef Attar wrote:
> From: Abdul Lateef Attar
>
> This patch adds support for AMD's new extended topology.
> If processor supports CPUID 8026 leaf then obtain
> the topology information using new method.
> + /// Check if extended toplogy supp
On Thu, Jan 11, 2024 at 10:16:00AM -0800, Doug Flick via groups.io wrote:
> This patch series include the combined / merged security patches
> (as seperate commits) for TCBZ4117 (CVE-2022-36763) and TCBZ4118
> (CVE-2022-36764) for DxeTpm2MeasureBootLib and DxeTpmMeasureBootLib.
> These patches have
On Tue, Jan 16, 2024 at 01:30:43PM +, Yao, Jiewen wrote:
> Gerd
> I have merged this patch set today.
>
> I am fine to remove TPM1.2 in OVMF because of the known security limitation.
I was thinking about the complete edk2 code base not only OVMF.
But I can surely start with OVMF. Maybe it i
Gerd Hoffmann (2):
OvmfPkg: remove TPM1_ENABLE build option
OvmfPkg/Tcg2Config: remove unused TPM 1.2 support
.../Include/Dsc/OvmfTpmComponentsDxe.dsc.inc | 6 --
.../Include/Dsc/OvmfTpmComponentsPei.dsc.inc | 5 --
OvmfPkg/Include/Dsc/OvmfTpmDefines.dsc.inc| 3 -
OvmfPkg/Include
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Tcg/Tcg2Config/Tcg12ConfigPei.inf | 56 ---
OvmfPkg/Tcg/Tcg2Config/Tpm12Support.c | 83 ---
2 files changed, 139 deletions(-)
delete mode 100644 OvmfPkg/Tcg/Tcg2Config/Tcg12ConfigPei.inf
delete mode 100644 OvmfPkg/Tcg
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Include/Dsc/OvmfTpmComponentsDxe.dsc.inc | 6 --
OvmfPkg/Include/Dsc/OvmfTpmComponentsPei.dsc.inc | 5 -
OvmfPkg/Include/Dsc/OvmfTpmDefines.dsc.inc | 3 ---
OvmfPkg/Include/Dsc/OvmfTpmLibs.dsc.inc | 9 -
OvmfPkg/Include/Dsc
+End variables
instead.
- add patch with UINTN and UINT32 casts.
- add patch splitting the DoErase code path into a new function.
- add the diagram sent by Laszlo.
Gerd Hoffmann (6):
OvmfPkg/VirtNorFlashDxe: add casts to UINTN and UINT32
OvmfPkg/VirtNorFlashDxe: clarify block write logic
l read only one instead of two
P30_MAX_BUFFER_SIZE_IN_BYTES blocks in case '*NumBytes' is smaller than
P30_MAX_BUFFER_SIZE_IN_BYTES but 'Offset + *NumBytes' is not, i.e. the
update range crosses a P30_MAX_BUFFER_SIZE_IN_BYTES boundary.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Laszlo Ersek
: Gerd Hoffmann
Reviewed-by: Laszlo Ersek
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
index 3d1343b381bc..3d1d20daa1e5 100644
--- a
of the variable list, so treat this as
additional "end of variable list" condition.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Laszlo Ersek
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlashFvb.c
This is needed to avoid bit operations being applied to signed integers.
Suggested-by: László Érsek
Signed-off-by: Gerd Hoffmann
Reviewed-by: Laszlo Ersek
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.h | 2 +-
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 2 +-
2 files changed, 2 insertions(+), 2
: Gerd Hoffmann
Reviewed-by: Laszlo Ersek
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c
index 88a4d2c23fc0..3d1343b381bc 100644
Move the DoErase code block into a separate function, call the function
instead of jumping around with goto.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 76 ++
1 file changed, 52 insertions(+), 24 deletions(-)
diff --git a/OvmfPkg
On Wed, Jan 17, 2024 at 08:23:19AM +, Yao, Jiewen wrote:
> That is weird.
> It seems we need to merge Gerd's patch soon -
> https://github.com/tianocore/edk2/pull/5265 to unblock CI.
>
> Hi Gerd
> Would you please confirm what test you have done for removing TPM1.2?
> Does TPM2.0 in OvmfPkg s
> This patch is good:
>
> Reviewed-by: Laszlo Ersek
>
> but the series shouldn't stop here. In "OvmfPkg/Tcg/Tcg2Config", we're
> left with an INF file (Tcg2ConfigPei.inf) that still references
> "Tpm12Support.h", and the common C source file "Tcg2ConfigPeim.c" still
> calls the one API -- Intern
On Tue, Jan 16, 2024 at 11:38:12PM +, Yao, Jiewen wrote:
> Gerd
> I am OK with the patch.
>
> Quick question: Have you validated that the TPM2 is still working?
TPM1_ENABLE=FALSE is known to work and this series should give identical
results. See other replies for more details.
take care,
> + /// Check if extended toplogy supported
> + AsmCpuid (CPUID_EXTENDED_FUNCTION, &MaxExtendedCpuIdIndex, NULL, NULL,
> NULL);
> + if (MaxExtendedCpuIdIndex >= AMD_CPUID_EXTENDED_TOPOLOGY) {
> +do {
> + AsmCpuidEx (
> +AMD_CPUID_EXTENDED_TOPOLOGY,
> +TopologyLevel,
> +
On Wed, Jan 17, 2024 at 03:25:37PM +0530, Abdul Lateef Attar via groups.io
wrote:
Hmm? Empty patch. Forgot "git add $file"?
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113955): https://edk2.groups.io/g/devel/mes
On Wed, Jan 10, 2024 at 04:43:47PM +, West, Catharine wrote:
> Disabling cache by default results in violation of BTG protections (if BTG
> enabled).
>
> BIOS cannot assume that cache is disabled before it executes as ACM may be
> required to enable NEM.
>
> Whatever solution needs to be d
Hi,
> I do appreciate that it's difficult to understand the internals of
> NestedInterruptTplLib. It's fundamentally having to solve a very difficult
> problem within the constraints of the UEFI API. I think the solution that
> NestedInterruptTplLib provides is as simple as it's possible to ge
On Mon, Jan 22, 2024 at 01:11:52PM -0600, Brian J. Johnson wrote:
> On 1/18/24 09:46, Gerd Hoffmann wrote:
> > On Wed, Jan 10, 2024 at 04:43:47PM +, West, Catharine wrote:
> > > Disabling cache by default results in violation of BTG protections (if
> > > BTG enabled
On Fri, Jan 12, 2024 at 10:25:16AM +0800, gua@intel.com wrote:
> From: Gua Guo
>
> PR: https://github.com/tianocore/edk2/pull/5252
> Gua Guo (4):
> UefiPayloadPkg/Hob: Integer Overflow in CreateHob()
> StandaloneMmPkg/Hob: Integer Overflow in CreateHob()
> EmbeddedPkg/Hob: Integer Over
ost) commit 879ae1880449 ("KVM: x86: obey
> KVM_X86_QUIRK_CD_NW_CLEARED in kvm_set_cr0()", 2015-11-04)
I actually waded through the source code in both places ;)
Turned out kvm propagates guest MTRR settings to EPT memory types,
but only in case kvm_arch_has_noncoherent_dma() is true,
Hi,
What is the state of affairs wrt. the pixiefail vulnerabilities?
The advisory is published
(https://github.com/tianocore/edk2/security/advisories/GHSA-hc6x-cw6p-gj7h),
it says the plan is to have the fixes included in the next (Feb 2024)
stable tag. I see bugzilla has patches attached, mos
On Tue, Jan 23, 2024 at 07:33:24PM -0800, Doug Flick via groups.io wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4535
>
> SECURITY PATCH - Patch
Not needed, the CVE number below implies that.
> TCBZ4535
Not needed, the link to tianocore bugzilla is above.
> CVE-2023-45230
> CVSS
On Tue, Jan 23, 2024 at 07:33:25PM -0800, Doug Flick via groups.io wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4535
>
> SECURITY PATCH - Unit Tests
>
> TCBZ4535
> CVE-2023-45230
> CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
> CWE-119 Improper Restriction of Operations
On Tue, Jan 23, 2024 at 07:33:26PM -0800, Doug Flick via groups.io wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4534
>
> SECURITY PATCH - Patch
>
> TCBZ4534
> CVE-2023-45229
> CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
> CWE-125 Out-of-bounds Read
>
> Cc: Saloni Kasb
On Tue, Jan 23, 2024 at 07:33:28PM -0800, Doug Flick via groups.io wrote:
> From: Doug Flick
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4536
>
> SECURITY PATCH - Patch
>
> TCBZ4536
> CVE-2023-45231
> CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
> CWE-125 Out-of-bounds Rea
Hi,
> Why isn't this just a
>
> struct Ipv6Option {
> UINT8 OptionType;
> UINT8 OptionLength;
> UINT8 OptionData[];
> };
That makes sense indeed (for dhcpv6 we have that,
see EFI_DHCP6_PACKET_OPTION).
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages
On Tue, Jan 23, 2024 at 07:33:32PM -0800, Doug Flick via groups.io wrote:
> From: Doug Flick
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4539
>
> SECURITY PATCH - Patch
>
> TCBZ4539
> CVE-2023-45234
> CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
> CWE-119 Improper Restrict
On Fri, Jan 12, 2024 at 08:56:02AM +, Ni, Ray wrote:
> It's strange to me that ARM's MM env still allows modifying HOBs.
Yes.
But fixing that is beyond the scope of this patch, which just
fixes the integer overflow in CreateHob().
Can we please move forward and get the remaining CreateHob()
On Tue, Jan 23, 2024 at 03:16:32PM +, Guo, Gua wrote:
> For MdeModulePkg, I think no need to change because no any logic change.
>
> For StandaloneMmPkg and EmbeddedPkg
> - Don't have enough abilities to close Sami Mujawar and Ni Ray open
> currently, so hold on the change until I find how to
Hi,
> So, yesterday I read your status on virt-staff, and I found an entry in
> it that resembled this upstream thread pretty closely. However, your
> status was the *only* mention of "mdev" specifically, and so I wasn't
> sure if *mdev* meant the same thing as the more generic upstream
> expres
kvm uses EPT memory types to apply guest MTRR settings.
In case MTRRs are disabled kvm will use the uncachable memory type
for all mappings.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Library/PlatformInitLib/MemDetect.c | 8 --
OvmfPkg/Sec/SecMain.c | 32
Neat when doing ResetVector coding.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/ResetVector/DebugCon.asm | 43 +++
OvmfPkg/ResetVector/ResetVector.nasmb | 2 +-
2 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644 OvmfPkg/ResetVector/DebugCon.asm
diff
checking PcdUse5LevelPageTable.
The ASSERT is not correct, remove it.
Signed-off-by: Gerd Hoffmann
---
MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
b/MdeModulePkg/Core/DxeIplPeim/X64
- Create include files to reduce duplication.
- Fix varpolicy command.
- Little CI tweak.
Gerd Hoffmann (11):
OvmfPkg: add ShellComponents.dsc.inc
OvmfPkg: add ShellLibs.dsc.inc
OvmfPkg: add ShellDxe.fdf.inc
OvmfPkg: Shell*.inc: allow building without network support
OvmfPkg
Move EFI Shell firmware volume files to
the new ShellDxe.fdf.inc file.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/OvmfPkgX64.fdf | 11 ++-
OvmfPkg/Include/Fdf/ShellDxe.fdf.inc | 14 ++
2 files changed, 16 insertions(+), 9 deletions(-)
create mode 100644 OvmfPkg
Move EFI Shell libraries from OvmfPkgX64.dsc to
the new ShellComponents.dsc.inc include file.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Include/Dsc/ShellLibs.dsc.inc | 11 +++
OvmfPkg/OvmfPkgX64.dsc| 11 +--
2 files changed, 16 insertions(+), 6 deletions
Add NETWORK_ENABLE conditionals for the components
which need network support.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Include/Dsc/ShellComponents.dsc.inc | 4
OvmfPkg/Include/Fdf/ShellDxe.fdf.inc| 2 ++
2 files changed, 6 insertions(+)
diff --git a/OvmfPkg/Include/Dsc
Move EFI Shell components from OvmfPkgX64.dsc to
the new ShellComponents.dsc.inc include file.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Include/Dsc/ShellComponents.dsc.inc | 49 +
OvmfPkg/OvmfPkgX64.dsc | 43 +-
2 files changed, 50
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/OvmfPkgIa32X64.dsc | 54 +-
OvmfPkg/OvmfPkgIa32X64.fdf | 11 ++--
2 files changed, 8 insertions(+), 57 deletions(-)
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 5e9eee628aea
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/IntelTdx/IntelTdxX64.dsc | 33 +++-
OvmfPkg/IntelTdx/IntelTdxX64.fdf | 9 ++---
2 files changed, 5 insertions(+), 37 deletions(-)
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index
Place the EFI shell as EFI/BOOT/BOOT{ARCH}.EFI on the virtual drive.
This allows the "run to shell" CI test case to work even in case the
shell is not included in the firmware image.
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/PlatformCI/PlatformBuildLib.py | 12 +++-
1 file c
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/AmdSev/AmdSevX64.dsc | 32 ++--
OvmfPkg/AmdSev/AmdSevX64.fdf | 8 ++--
2 files changed, 4 insertions(+), 36 deletions(-)
diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index a31a89344a60
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Microvm/MicrovmX64.dsc | 55 --
OvmfPkg/Microvm/MicrovmX64.fdf | 9 ++
2 files changed, 14 insertions(+), 50 deletions(-)
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 063324cd0572
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/OvmfPkgIa32.dsc | 49 ++---
OvmfPkg/OvmfPkgIa32.fdf | 11 ++---
2 files changed, 4 insertions(+), 56 deletions(-)
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 28379961a78e..23f949fd9845
Needed to make the new 'varpolicy' EFI shell command
actually available in the OVMF firmware builds.
Fixes: fe6cd1c18721 ("OvmfPkg: Add varpolicy shell command")
Signed-off-by: Gerd Hoffmann
---
OvmfPkg/Include/Fdf/ShellDxe.fdf.inc | 1 +
1 file changed, 1 insertion(+)
On Wed, Jan 24, 2024 at 07:20:34AM -0800, Vincent Zimmer wrote:
> I agree on your sentiment about Bugzilla (bz) not being ideal for this.
> This space has been a multi-year journey from usrt-based tickets, bespoke
> advisories, bz, etc into today's world of tianocore infosec, tianocore as
> its own
Hi,
> > static u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
> > {
> > [ ... ]
> > * When there is no need to deal with noncoherent DMA (e.g., no VT-d
> > * or VT-d has snoop control), guest CD/MTRR/PAT are all ignored.
> > The
> > * EPT memory t
On Wed, Jan 24, 2024 at 05:14:10PM +0100, Laszlo Ersek wrote:
> On 1/24/24 16:15, Gerd Hoffmann wrote:
> > Specifically before running lzma uncompress of the main firmware volume.
> > This is needed to make sure caching is enabled, otherwise the uncompress
> > can be extremely
On Wed, Jan 24, 2024 at 05:43:29PM -0800, Erdem Aktas wrote:
> Same for TDX, I did not run it but it should cause failure
> as debugShowPostCode is called OvmfPkg/ResetVector/Ia32/IntelTdx.asm before
> actually the #VE handlers are installed.
>
> > Had a meeting get canceled and so got a chance to
1 - 100 of 2201 matches
Mail list logo
