Re: [PATCH] efi: arm/arm64: allow SetVirtualAddressMap() to be omitted

On Mon, 28 Jan 2019 at 19:04, Jeffrey Hugo wrote: > > On 1/26/2019 3:22 AM, Ard Biesheuvel wrote: > > The UEFI spec revision 2.7 errata A section 8.4 has the following to > > say about the virtual memory runtime services: > > > >"This section contains function definitions for the virtual

Re: [PATCH] efi: arm/arm64: allow SetVirtualAddressMap() to be omitted

On 1/26/2019 3:22 AM, Ard Biesheuvel wrote: The UEFI spec revision 2.7 errata A section 8.4 has the following to say about the virtual memory runtime services: "This section contains function definitions for the virtual memory support that may be optionally used by an operating system at

[PATCH AUTOSEL 4.20 102/304] firmware/efi: Add NULL pointer checks in efivars API functions

From: Arend van Spriel [ Upstream commit ab2180a15ce54739fed381efb4cb12e78dfb1561 ] Since commit: ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI variables") we have a device driver accessing the efivars API. Several functions in the efivars API assume __efivars

[PATCH AUTOSEL 4.19 088/258] firmware/efi: Add NULL pointer checks in efivars API functions

From: Arend van Spriel [ Upstream commit ab2180a15ce54739fed381efb4cb12e78dfb1561 ] Since commit: ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI variables") we have a device driver accessing the efivars API. Several functions in the efivars API assume __efivars

[PATCH AUTOSEL 4.14 057/170] firmware/efi: Add NULL pointer checks in efivars API functions

From: Arend van Spriel [ Upstream commit ab2180a15ce54739fed381efb4cb12e78dfb1561 ] Since commit: ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI variables") we have a device driver accessing the efivars API. Several functions in the efivars API assume __efivars

[PATCH AUTOSEL 4.9 033/107] firmware/efi: Add NULL pointer checks in efivars API functions

From: Arend van Spriel [ Upstream commit ab2180a15ce54739fed381efb4cb12e78dfb1561 ] Since commit: ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI variables") we have a device driver accessing the efivars API. Several functions in the efivars API assume __efivars

Re: [PATCH 2/2] efi/cper: Avoid possible OOB when checking generic data block

On 1/23/19 11:54 AM, Borislav Petkov wrote: On Tue, Jan 22, 2019 at 04:09:12PM +, Ross Lagerwall wrote: When checking a generic status block, we iterate over all the generic data blocks. The loop condition only checks that the start of the generic data block is valid (within

[PATCH v2 2/2] efi/cper: Fix possible out-of-bounds access

When checking a generic status block, we iterate over all the generic data blocks. The loop condition only checks that the start of the generic data block is valid (within estatus->data_length) but not the whole block. Because the size of data blocks (excluding error data) may vary depending on

[PATCH v2 0/2] Fix crash in cper_estatus_check()

v2 changes: - Address Boris's comments. --- I recently encountered a crash in cper_estatus_check() when called by bert_init(). Patches follow to fix the problem. Note that I cannot fully test the patches since the hardware error record on that machine has been cleared. The crash log: [

[PATCH v2 1/2] acpi/apei: Fix possible out-of-bounds access to BERT region

Check that the length recorded in the generic error status block is within the region before checking the contents of the region itself. Otherwise it may result in an out-of-bounds access if the system firmware has generated a status block with an invalid length (larger than the mapped region).

Re: [PATCH v9 11/26] efi: Let architectures decide the flags that should be saved/restored

On Mon, 21 Jan 2019 15:33:30 +, Julien Thierry wrote: > > Currently, irqflags are saved before calling runtime services and > checked for mismatch on return. > > Provide a pair of overridable macros to save and restore (if needed) the > state that need to be preserved on return from a