Some functions across OVMF don't check pointer arguments for validity, which causes null pointer dereferences and crashes in the SCT test suite. This series adds checks to return

The current implementation does not check if Progress or Results pointers in ExtractConfig are NULL, or if Progress pointer in RouteConfig is NULL. This causes the SCT test suite to crash. Add a

The current implementation does not check if Language or DriverName are NULL. This causes the SCT test suite to crash. Add a check to return EFI_INVALID_PARAMETER if any of these pointers are

The current implementation does not check if Info or SizeInfo pointers are NULL. This causes the SCT test suite to crash. Add a check to return EFI_INVALID_PARAMETER if any of these pointers are

Hi Ray, How do you envision this library working with SEV and/or TDX which use the one of the bits in PageTableBaseAddress to indicate whether the page is encrypted or shared? For SEV, the encryption

Hello Dimitrije, These patches look corrupted again. Can you please double check your setup, and maybe compare notes with colleagues how to send patches to the list in a way that doesn't corrupt

The current implementation does not check if Progress or Results pointers in ExtractConfig are NULL, or if Progress pointer in RouteConfig is NULL. This causes the SCT test suite to crash. Add a

The current implementation does not check if Info or SizeInfo pointers are NULL. This causes the SCT test suite to crash. Add a check to return EFI_INVALID_PARAMETER if any of these pointers are

Acked-by: Gerd Hoffmann <kraxel@...>

The current implementation does not check if Language or DriverName are NULL. This causes the SCT test suite to crash. Add a check to return EFI_INVALID_PARAMETER if any of these pointers are

Acked-by: Gerd Hoffmann <kraxel@...> take care, Gerd

<jbrasen@...> wrote: What I was wondering is whether such allocations are themselves multiples of 64k. This is perhaps orthogonal to the issue this patch addresses, as we'' still need

Thanks for the fix Reviewed-by: Ard Biesheuvel <ardb@...> Pushed as 01e3a8877180..9675047d7245

Thanks for the fix Reviewed-by: Ard Biesheuvel <ardb@...> Pushed as 01e3a8877180..9675047d7245

The edk2 patch at: "6eb407947592 SecurityPkg: SecureBootVariableLib: Added newly supported interfaces" introduced a new dependency of PlatformPKProtectionLib to SecureBootVariableLib. This causes the

Hmm. Not a comment to this specifically, but more to the OVMF *.dsc and *.fdf files in general. We have a lot of duplication here. I've already moved some bits to include files

Can this be detected by the guest somehow, so the firmware can work with both old+new cloudhv? Requiring lockstep updates tends to be painful, so we try avoid that with qemu ... (just a suggestion,

Hello everyone. I wanted to ask if there was a device/parameter to have `EFI_TIMESTAMP_PROTOCOL` in OVMF. I would like to use this protocol to provide monotonic time in Rust (and fall back to

Main Changes since v1 : 1.treate overflow as overlap Wenyi Xie (1): MdeModulePkg/PiSmmCore:Avoid overflow risk MdeModulePkg/Core/PiSmmCore/PiSmmCore.c | 5 ++++-

As the CommunicationBuffer plus BufferSize may overflow, check the value first before using. Cc: Liming Gao <gaoliming@...> Cc: Eric Dong <eric.dong@...> Cc: Ray Ni