[GIT PULL] EFI fixes

Linus, Please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus # HEAD: be59d57f98065af0b8472f66a0a969207b168680 efi/tpm: Fix sanity check of unsigned tbl_size being less than zero Misc EFI fixes all

[GIT PULL] EFI changes for v5.4

Linus, Please pull the latest efi-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-core-for-linus # HEAD: d3dc0168e93233ba4d4ed9a2c506c9d2b8d8cd33 Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/core The

[GIT PULL] EFI fixes

Linus, Please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus # HEAD: 48c7d73b2362ce61503551ad70052617b3e8857d Merge tag 'efi-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into

[GIT PULL] EFI fixes

Linus, Please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus # HEAD: 88447c5b93d98be847f428c39ba589779a59eb83 efi: Allow the number of EFI configuration tables entries to be zero Two EFI fixes: a quirk

Re: [PATCH V5 2/4] tpm: Reserve the TPM final events table

to ensure you picked it up rather than Jarkko? That's not the workflow rule the Linux kernel is using, if Cc:-ing a patchset was the only condition for upstream inclusion then we'd have a *LOT* of crap in the Linux kernel. Just applying those EFI changes without even as much as an Acked-by fr

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

* Ard Biesheuvel wrote: > On Wed, 17 Apr 2019 at 11:23, Ingo Molnar wrote: > > > > > > * Prakhya, Sai Praneeth wrote: > > > > > I will ask around internally to check if it is a good idea to make EFI > > > reboot the default method when the mach

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

* Prakhya, Sai Praneeth wrote: > I will ask around internally to check if it is a good idea to make EFI > reboot the default method when the machine is booted in EFI mode. Or whether there's some robust signature that indicates "modern EFI system where EFI reboot is the primary method"?

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

* h...@zytor.com wrote: > > Just to check, you mean: EFI reboot (and shutdown) become the default > > methods when the machine is booted in EFI mode, and EFI stuff has not > > been disabled with a kernel parameter? > > Even when running in full hardware ACPI mode. No, I still think "early"

Re: EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

* Daniel Drake wrote: > On Tue, Apr 16, 2019 at 4:20 PM Ingo Molnar wrote: > > I wanted to get a second opinion from the EFI folks for this whole > > concept. On x86 we default to ACPI reboot on modern systems, and we > > default to EFI reboot on mo

EFI reboot vs. ACPI reboot (was: Re: [tip:x86/urgent] x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T)

800 > Committer: Ingo Molnar > CommitDate: Tue, 16 Apr 2019 10:01:24 +0200 > > x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T > > Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the > shutdown process, but then it hangs in BIOS POST w

Re: [GIT PULL 0/5] EFI changes for v5.2

* Ard Biesheuvel wrote: > The following changes since commit 8c2ffd9174779014c3fe1f96d9dc3641d9175f00: > > Linux 5.1-rc2 (2019-03-24 14:02:26 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next > > for you to

Re: [GIT PULL] EFI changes for v5.1

* Ard Biesheuvel wrote: > Hi ingo, > > On Tue, 5 Mar 2019 at 13:20, Ingo Molnar wrote: > > > > Linus, > > > > Please pull the latest efi-core-for-linus git tree from: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.

[GIT PULL] EFI changes for v5.1

ace GPL license boilerplate with SPDX headers efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted x86: Make ARCH_USE_MEMREMAP_PROT a generic Kconfig symbol efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation Ingo Molnar (1): efi/fdt: Apply m

Re: x86 kernel does not boot with this commit 4543fea0423b221d6

* Ard Biesheuvel wrote: > On Mon, 11 Feb 2019 at 08:12, Ingo Molnar wrote: > > > > > > * Ard Biesheuvel wrote: > > > > > The reason I did not spot this is because I failed to realise that the > > > x86 defconfig does not enable CONFIG_ACPI_BGRT

Re: x86 kernel does not boot with this commit 4543fea0423b221d6

* Ard Biesheuvel wrote: > The reason I did not spot this is because I failed to realise that the > x86 defconfig does not enable CONFIG_ACPI_BGRT, and so the automated > boot tests I did never invoked this code path. Could you please send a patch that updates the x86 defconfig to add this

Re: x86 kernel does not boot with this commit 4543fea0423b221d6

* Ard Biesheuvel wrote: > On Mon, 4 Feb 2019 at 21:07, Kammela, Gayatri > wrote: > > > > Hi Ard, > > > > > > I have come across an issue where i could not boot kernel on x86_64 qemu > > when applied this commit 4543fea0423b221d6 ("acpi: bgrt: parse BGRT to > > obtain BMP address before it

Re: [PATCH 02/10] x86/efi: Return error status if mapping EFI regions fail

* Ingo Molnar wrote: > Note that I also fixed up the grammar and readability of the changelog - > see the updated version below. > > Thanks, > > Ingo > > => > Subject: x86/efi: Return error status if mapping of EFI regions fails > From: A

Re: [PATCH 02/10] x86/efi: Return error status if mapping EFI regions fail

e kernel cannot > prioritize among EFI regions. > > This also fixes the comment "FIXME: add error handling" in > kexec_enter_virtual_mode(). > > Signed-off-by: Sai Praneeth Prakhya > Cc: Borislav Petkov > Cc: Ingo Molnar > Signed-off-by: A

Re: [GIT PULL] EFI fix

* Linus Torvalds wrote: > On Thu, Jan 10, 2019 at 11:46 PM Ingo Molnar wrote: > > > > A single fix that adds an annotation to resolve a kmemleak false > > positive. > > This one is apparently obviated by commit 80424b02d42b ("efi: Reduce > the amount of m

Re: [GIT PULL] EFI fix

* Linus Torvalds wrote: > On Fri, Jan 11, 2019 at 6:22 AM Ard Biesheuvel > wrote: > > > > I was hoping we could merge this patch (so we can backport it), but > > resolve the conflict by dropping the kmemleak_ignore() again [..] > > Well, we'd drop the new #include line also, since it would

[GIT PULL] EFI fix

Linus, Please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus # HEAD: b12f5440d8ca02e8f9ab4f1461f9214295cc4f66 Merge branch 'linus' into efi/urgent, to resolve conflict A single fix that adds an

Re: [PATCH] x86/efi: Don't unmap EFI boot services code/data regions for EFI_OLD_MEMMAP and EFI_MIXED_MODE

* Prakhya, Sai Praneeth wrote: > > > > + /* > > > > + * To Do: Remove this check after adding functionality to unmap > > > > EFI > > boot > > > > + * services code/data regions from direct mapping area because > > > > + * "efi=old_map" maps EFI regions in swapper_pg_dir. >

[GIT PULL] EFI changes for v4.21

Linus, Please pull the latest efi-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-core-for-linus # HEAD: 1debf0958fa27b7c469dbf22754929ec59a7c0e7 x86/efi: Don't unmap EFI boot services code/data regions for EFI_OLD_MEMMAP and EFI_MIXED_MODE

Re: [PATCH] x86/efi: Don't unmap EFI boot services code/data regions for EFI_OLD_MEMMAP and EFI_MIXED_MODE

DER_, EFI_BOOT_SERVICES_ and > EFI_RUNTIME_CODE/DATA regions) is mapped into efi_pgd all the time to > facilitate EFI runtime calls access it's arguments in 1:1 mode. Hence, > don't unmap EFI boot services code/data regions when booted in mixed mode. > > Signed-off-by: Sai Praneeth Prakh

[GIT PULL] EFI fixes

Linus, Please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus # HEAD: 79c2206d369b87b19ac29cb47601059b6bf5c291 x86/earlyprintk/efi: Fix infinite loop on some screen widths Two fixes: a large-system fix

Re: [PATCH V2 0/3] Fix EFI memory map leaks

* Ard Biesheuvel wrote: > So if we are going to rename these things wholesale (which is fine > with me), I'd prefer it if we can drop the 'map' entirely. > > EFI memory table > EFI memory table entry > EFI memory table descriptor So if you don't actively hate the idea (which you don't seem

Re: [PATCH V2 0/3] Fix EFI memory map leaks

* Sai Praneeth Prakhya wrote: > Presently, in EFI subsystem of kernel, every time kernel allocates memory for > a > new EFI memory map, it forgets to free the memory occupied by old EFI memory > map. > It does clear the mappings though (using efi_memmap_unmap()), but forgets to > free up the

Re: [PATCH V2 2/3] x86/efi: Fix EFI memory map leaks

* Sai Praneeth Prakhya wrote: > if (efi_enabled(EFI_MEMMAP)) { > + /* > + * efi_clean_memmap() uses memblock_phys_alloc() to allocate > + * memory for new EFI memmap and hence will work only after > + * e820__memblock_setup() > +

Re: [PATCH V2 1/3] efi: Introduce efi_memmap_free() and efi_memmap_unmap_and_free()

* Sai Praneeth Prakhya wrote: > +/** > + * efi_memmap_free - Free memory pointed by new_memmap.map > + * @new_memmap: Structure that describes EFI memory map. > + * > + * Memory is freed depending on the type of allocation performed. > + */ > +static void __init efi_memmap_free(struct

Re: [PATCH] efi/fdt: More cleanups

* Ard Biesheuvel wrote: > On Fri, 30 Nov 2018 at 08:57, Ingo Molnar wrote: > > > > > > * Ard Biesheuvel wrote: > > > > > From: Julien Thierry > > > > > > Closing bracket seems to end a for statement when it is actually ending &

Re: [PATCH 10/11] efi: reduce the amount of memblock reservations for persistent allocations

* Ard Biesheuvel wrote: > The current implementation of efi_mem_reserve_persistent() is rather > naive, in the sense that for each invocation, it creates a separate > linked list entry to describe the reservation. Since the linked list > entries themselves need to persist across subsequent

Re: [PATCH 01/11] x86/efi: Allocate e820 buffer before calling efi_exit_boot_service

* Ard Biesheuvel wrote: > On Fri, 30 Nov 2018 at 08:29, Ingo Molnar wrote: > > > > > > * Ard Biesheuvel wrote: > > > > > From: Eric Snowberg > > > > > > Commit d64934019f6c ("x86/efi: Use efi_exit_boot_services()")

Re: [PATCH 08/11] firmware: efi: add NULL pointer checks in efivars api functions

* Ard Biesheuvel wrote: > From: Arend van Spriel > > Since commit: > >ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from > EFI variables") This commit ID is not upstream AFAICS. Which tree is it from? Mentioning non-upstream sha1's is discouraged in

Re: [PATCH 11/11] efi/x86: earlyprintk - Fix infinite loop on some screen widths

* Ard Biesheuvel wrote: > From: YiFei Zhu > > An affected screen resolution is 1366 x 768, which width is not > divisible by 8, the default font width. On such screens, when longer > lines are earlyprintk'ed, overflow-to-next-line can never trigger, > due to the left-most x-coordinate of the

[PATCH] efi/fdt: More cleanups

So if we are doing trivial cleanups, how about the patch below on top? It cleans up this file for good. Only minimally build tested. Thanks, Ingo ==> Subject: efi/fdt: More cleanups From: Ingo Molnar Apply a number of cleanups: - Introduce fdt_setprop_*

Re: [PATCH 01/11] x86/efi: Allocate e820 buffer before calling efi_exit_boot_service

* Ard Biesheuvel wrote: > From: Eric Snowberg > > Commit d64934019f6c ("x86/efi: Use efi_exit_boot_services()") > introduced a regression on systems with large memory maps > causing them to hang on boot. The first "goto get_map" that was removed > from exit_boot insured there was enough room

Re: [PATCH] x86: fix -Wmissing-prototypes warning

* wang.y...@zte.com.cn wrote: > Hi Ingo, > > > * Yi Wang wrote: > > > > > We may get -Wmissing-prototypes warnings when building > > > kernel with W=1, it's better to fix them as global function > > > signature can be changed and caller who use the old unchanged > > > prototypes will be

Re: [PATCH] x86: fix -Wmissing-prototypes warning

* Yi Wang wrote: > We may get -Wmissing-prototypes warnings when building > kernel with W=1, it's better to fix them as global function > signature can be changed and caller who use the old unchanged > prototypes will be hosed. > > This patch fixes most of -Wmissing-prototypes warnings which

[GIT PULL] EFI fixes

Linus, Please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus # HEAD: 63eb322d89c8505af9b4a3d703e85e42281ebaa0 efi: Permit calling efi_mem_reserve_persistent() from atomic context Misc fixes: two warning

Re: [PATCH V2 1/2] x86/efi: Unmap EFI boot services code/data regions from efi_pgd

ESENT bit and it shouldn't bother L1TF cases because it's already > handled by protnone_mask() at arch/x86/include/asm/pgtable-invert.h. > > [1] Please see efi_reserve_boot_services() > [2] Please see efi_map_region() -> __map_region() > [3] Please see efi_free_boot_services() > &

[GIT PULL] EFI changes for v4.20

Greg, Please pull the latest efi-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-core-for-linus # HEAD: fa70f0d2ce96a892b38fbbaa60584af536f21f97 Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/core The

Re: [PATCH 1/2] x86/efi: Unmap efi boot services code/data regions from efi_pgd

-> __map_region() > [3] Please see efi_free_boot_services() > > Signed-off-by: Sai Praneeth Prakhya > Cc: Borislav Petkov > Cc: Ingo Molnar > Cc: Andy Lutomirski > Cc: Dave Hansen > Cc: Bhupesh Sharma > Cc: Thomas Gleixner > Cc: Peter Zijlstra > Cc: Ar

Re: [GIT PULL 00/11] EFI updates for v4.20

* Ingo Molnar wrote: > > * Marc Zyngier wrote: > > > Hi all, > > > > On 27/09/18 09:50, Ard Biesheuvel wrote: > > > Thomas, Ingo, > > > > > > Please pull/cherry-pick the below. Note that the first three patches will > > > b

Re: [GIT PULL 00/11] EFI updates for v4.20

* Marc Zyngier wrote: > Hi all, > > On 27/09/18 09:50, Ard Biesheuvel wrote: > > Thomas, Ingo, > > > > Please pull/cherry-pick the below. Note that the first three patches will > > be depended upon by an irqchip series that Marc Zyngier has sent out last > > week, and that targets the next

Re: [PATCH] x86/efi: earlyprintk - Add 64bit efi fb address support

* Aaron Ma wrote: > if (efi_fb) > return (efi_fb + start); Just noticed this detail unrelated to your patch: return is not a function. Thanks, Ingo

[GIT PULL] EFI fix

Linus, Please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus # HEAD: 9b788f32bee6b0b293a4bdfca4ad4bb0206407fb x86/efi: Access EFI MMIO data as unencrypted when SEV is active An UEFI variables fix for

Re: [PATCH 2/8] efi/x86: Use non-blocking SetVariable() for efi_delete_dummy_variable()

* Prakhya, Sai Praneeth wrote: > > > diff --git a/arch/x86/platform/efi/quirks.c > > > b/arch/x86/platform/efi/quirks.c index 36c1f8b9f7e0..6af39dc40325 > > > 100644 > > > --- a/arch/x86/platform/efi/quirks.c > > > +++ b/arch/x86/platform/efi/quirks.c > > > @@ -105,12 +105,11 @@

Re: [PATCH 2/8] efi/x86: Use non-blocking SetVariable() for efi_delete_dummy_variable()

* Ard Biesheuvel wrote: > From: Sai Praneeth > > Presently, efi_delete_dummy_variable() uses set_variable() which might > block and hence kernel prints stack trace with a warning "bad: > scheduling from the idle thread!". So, make efi_delete_dummy_variable() > use set_variable_nonblocking(),

Re: [PATCH 0/6] efi/x86 mixed mode cleanups

* Lukas Wunner wrote: > --- a/drivers/firmware/efi/libstub/efi-stub-helper.c > +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c > @@ -413,6 +413,32 @@ static efi_status_t efi_file_close(void *handle) > return efi_call_proto(efi_file_handle, close, handle); > } > > +static

Re: [GIT PULL 0/1] EFI mixed mode fix for v4.18

* Ard Biesheuvel wrote: > On 11 July 2018 at 13:14, Ingo Molnar wrote: > > > > * Ard Biesheuvel wrote: > > > >> On 11 July 2018 at 12:13, Ingo Molnar wrote: > >> > > >> > * Ard Biesheuvel wr

Re: [GIT PULL 0/1] EFI mixed mode fix for v4.18

* Ard Biesheuvel wrote: > On 11 July 2018 at 12:13, Ingo Molnar wrote: > > > > * Ard Biesheuvel wrote: > > > >> The following changes since commit > >> 1e4b044d22517cae7047c99038abb23243ca: > >> > >> Linux 4.18-rc4 (2018

Re: [GIT PULL 0/1] EFI mixed mode fix for v4.18

* Ard Biesheuvel wrote: > The following changes since commit 1e4b044d22517cae7047c99038abb23243ca: > > Linux 4.18-rc4 (2018-07-08 16:34:02 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent > > for you to

Re: [PATCH v6 3/3] x86: paravirt: make native_save_fl extern inline

* Nick Desaulniers wrote: > On Thu, Jun 21, 2018 at 7:24 PM Ingo Molnar wrote: > > * Nick Desaulniers wrote: > > > > > native_save_fl() is marked static inline, but by using it as > > > a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined.

Re: [PATCH v6 3/3] x86: paravirt: make native_save_fl extern inline

* Nick Desaulniers wrote: > native_save_fl() is marked static inline, but by using it as > a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined. > --- a/arch/x86/include/asm/irqflags.h > +++ b/arch/x86/include/asm/irqflags.h > @@ -13,7 +13,7 @@ > * Interrupt control: > */

Re: [PATCH v5 2/3] x86/asm: add _ASM_ARG* constants for argument registers to

* Nick Desaulniers wrote: > On Thu, Jun 14, 2018 at 5:17 PM H. Peter Anvin wrote: > > > > On 06/14/18 13:59, Nick Desaulniers wrote: > > > On Thu, Jun 14, 2018 at 1:48 PM H. Peter Anvin wrote: > > >> > > >> On 06/13/18 14:05, Nick Desaulniers wrote: > > >>> From: "H. Peter Anvin" > > >>> >

[GIT PULL] EFI changes for v4.18

Linus, Please pull the latest efi-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-core-for-linus # HEAD: 83f0a7c7b265a56d757f7e3a80622e5b0b7ebc46 efi/capsule-loader: Don't output reset log when reset flags are not set The main EFI changes in

Re: [PATCH 12/17] efi: fix efi_pci_io_protocol32 prototype for mixed mode

* Ard Biesheuvel wrote: > Mixed mode allows a kernel built for x86_64 to interact with 32-bit > EFI firmware, but requires us to define all struct definitions carefully > when it comes to pointer sizes. efi_pci_io_protocol32 currently uses a > void* for the 'romimage'

Re: [PATCH] efi/x86: Clean up the eboot code a bit

* Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 14 May 2018 at 08:43, Ingo Molnar <mi...@kernel.org> wrote: > > > > So I looked at arch/x86/boot/compressed/eboot.c to improve a printk message > > and > > ended up with the cleanups below. &g

Re: [PATCH 17/17] efi/libstub/arm64: handle randomized TEXT_OFFSET

* Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 14 May 2018 at 08:47, Ingo Molnar <mi...@kernel.org> wrote: > > > > * Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > > > >> From: Mark Rutland <mark.rutl...@arm.com> > >>

Re: [PATCH 17/17] efi/libstub/arm64: handle randomized TEXT_OFFSET

* Ard Biesheuvel wrote: > From: Mark Rutland > > When CONFIG_RANDOMIZE_TEXT_OFFSET is selected, TEXT_OFFSET is an > arbitrary multiple of PAGE_SIZE in the interval [0, 2MB). > > The EFI stub does not account for the potential misalignment of >

[PATCH] efi/x86: Clean up the eboot code a bit

So I looked at arch/x86/boot/compressed/eboot.c to improve a printk message and ended up with the cleanups below. Only build tested. Thanks, Ingo => Subject: efi/x86: Clean up the eboot code From: Ingo Molnar <mi...@kernel.org> Date: Mon May 14 08:33:40

Re: [PATCH 15/17] efi/x86: Ignore unrealistically large option roms

* Ard Biesheuvel wrote: > + /* > + * Some firmwares contain EFI function pointers at the place where the > + * romimage and romsize fields are supposed to be. Typically the EFI > + * code is mapped at high addresses, translating to an

Re: [PATCH v3] efi: Ignore unrealistically large option roms

* Hans de Goede wrote: > diff --git a/arch/x86/boot/compressed/eboot.c > b/arch/x86/boot/compressed/eboot.c > index 47d3efff6805..8650ab268ee7 100644 > --- a/arch/x86/boot/compressed/eboot.c > +++ b/arch/x86/boot/compressed/eboot.c > @@ -122,7 +122,14 @@

[GIT PULL] EFI updates for v4.17

efi/esrt: Fix handling of early ESRT table mapping efi: Use string literals for efi_char16_t variable initializers Colin Ian King (1): efi: Make const array 'apple' static Ingo Molnar (1): Merge branch 'x86/mm' into efi/core Jia-Ju Bai (1): x86/efi: Replace GFP_ATOMIC wi

Re: [PATCH 2/5] x86/efi: Replace efi_pgd with efi_mm.pgd

* Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 12 March 2018 at 09:26, Ingo Molnar <mi...@kernel.org> wrote: > > > > * Ingo Molnar <mi...@kernel.org> wrote: > > > >> > -static pgd_t *efi_pgd; > >> > - > >> > >

Re: [PATCH 2/5] x86/efi: Replace efi_pgd with efi_mm.pgd

* Ingo Molnar <mi...@kernel.org> wrote: > > -static pgd_t *efi_pgd; > > - > > Hm, so there's some interaction here with: > > 116fef640859: x86/mm/dump_pagetables: Add the EFI pagetable to the debugfs > 'page_tables' directory > > which is in ti

Re: [PATCH 2/5] x86/efi: Replace efi_pgd with efi_mm.pgd

* Ard Biesheuvel wrote: > From: Sai Praneeth > > Since the previous patch added support for efi_mm, let's handle efi_pgd > through efi_mm and remove global variable efi_pgd. > > Signed-off-by: Sai Praneeth Prakhya

Re: [PATCH 12/12] efi: make const array 'apple' static

* Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 9 March 2018 at 08:04, Ingo Molnar <mi...@kernel.org> wrote: > > > > * Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > > > >> > Also, would it make sense to rename it to someth

Re: [PATCH 12/12] efi: make const array 'apple' static

* Ard Biesheuvel wrote: > > Also, would it make sense to rename it to something more descriptive like > > "apple_unicode_str[]" or so? > > > > Plus an unicode string literal initializer would be pretty descriptive as > > well, > > instead of the weird looking

Re: [PATCH 06/12] x86: efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store

* Ard Biesheuvel wrote: > From: Jia-Ju Bai > > The function kzalloc here is not called in atomic context. > If nonblocking in efi_query_variable_store is true, > namely it is in atomic context, efi_query_variable_store will return before >

Re: [PATCH 12/12] efi: make const array 'apple' static

* Ard Biesheuvel wrote: > From: Colin Ian King > > Don't populate the const read-only array 'buf' on the stack but instead > make it static. Makes the object code smaller by 64 bytes: > > Before: >text data bss dec

Re: [PATCH 07/12] efi: Use efi_mm in x86 as well as ARM

* Ard Biesheuvel wrote: > From: Sai Praneeth > > Presently, only ARM uses mm_struct to manage efi page tables and efi > runtime region mappings. As this is the preferred approach, let's make > this data structure common across

Re: [PATCH] x86: efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store

s_t efi_query_variable_store(u32 attributes, > unsigned long size, >* that by attempting to use more space than is available. >*/ > unsigned long dummy_size = remaining_size + 1024; > - void *dummy = kzalloc(dummy_size, GFP_ATOMIC); > + void *d

[GIT PULL] EFI changes for v4.16

Linus, Please pull the latest efi-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-core-for-linus # HEAD: a5c03c31af2291f13689d11760c0b59fb70c9a5a x86/efi: Clarify that reset attack mitigation needs appropriate userspace The biggest change in

Re: [PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer

* Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 3 January 2018 at 12:50, Ingo Molnar <mi...@kernel.org> wrote: > > > > * Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > >> On Wed, 03 Jan, at 10:13:55AM, Ard Biesheuvel wrote: &g

Re: [PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer

* Matt Fleming wrote: > On Wed, 03 Jan, at 10:13:55AM, Ard Biesheuvel wrote: > > On 3 January 2018 at 09:44, Matt Fleming wrote: > > > Instate Ard Biesheuvel as the sole EFI maintainer and leave other folks > > > as maintainers for the EFI

Re: [GIT PULL 0/2] EFI updates for v4.15

* Ard Biesheuvel wrote: > On 25 October 2017 at 11:14, Ard Biesheuvel wrote: > > The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f: > > > > Linux 4.14-rc4 (2017-10-08 20:53:29 -0700) > > > > are available in the

Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap

* Matt Fleming wrote: > > x86_init.oem.arch_setup(); > > @@ -962,6 +959,8 @@ void __init setup_arch(char **cmdline_p) > > > > parse_early_param(); > > > > + if (efi_enabled(EFI_BOOT)) > > + efi_memblock_x86_reserve_range(); > > #ifdef

Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap

* Dave Young wrote: > Another way is move "efi_memblock_x86_reserve_range" to later code > Maybe below is better? Yeah, that's much lower risk, if the affected EFI code does not mind being called later. We had trouble from trying to move early param parsing wholesale.

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

* Gary Lin <g...@suse.com> wrote: > On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote: > > > > * Gary Lin <g...@suse.com> wrote: > > > > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote: > > > > > > > >

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

* Gary Lin <g...@suse.com> wrote: > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote: > > > > * Gary Lin <g...@suse.com> wrote: > > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote: > > > > > > > > *

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

* Gary Lin <g...@suse.com> wrote: > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote: > > > > * Gary Lin <g...@suse.com> wrote: > > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote: > > > > On Tue,

Re: [GIT PULL 0/3] EFI fixes for v4.15

* Ard Biesheuvel wrote: > The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215: > > Linux 4.15-rc2 (2017-12-03 11:01:47 -0500) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git

[GIT PULL] EFI fixes

Linus, Please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus # HEAD: 38fb6652229c2149e8694d57db442878fdf8a1bd efi/libstub/arm: Don't randomize runtime regions when CONFIG_HIBERNATION=y Two fixes: an ARM

[GIT PULL] EFI changes for v4.14

Linus, Please pull the latest efi-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-core-for-linus # HEAD: 6de47a5e371f75f80544986e6c9636211a2ae8af efi/bgrt: Use efi_mem_type() The main changes in this cycle were: - Transparently fall back to

Re: [GIT PULL 00/14] EFI changes for v4.14

* Ard Biesheuvel wrote: > Hi all, > > These are the changes we have queued up in the EFI tree for v4.14. Please > pull. > > Russell has been cc'ed twice on the patches that touch the linker script > of the ARM decompressor, and has elected not to respond, so I

Re: [PATCH v2] x86/efi: page align EFI ROM image ranges

* Stuart Hayes wrote: > The kernel's EFI stub locates and copies EFI ROM images into memory, which it > allocates using the byte-granular EFI allocate_pool function. These memory > ranges are then added to setup_data, and later to e820 (in >

Re: [PATCH v10 37/38] compiler-gcc.h: Introduce __nostackp function attribute

* Tom Lendacky wrote: > Create a new function attribute, __nostackp, that can used to turn off > stack protection on a per function basis. > > Signed-off-by: Tom Lendacky > --- > include/linux/compiler-gcc.h | 2 ++ > include/linux/compiler.h

Re: [PATCH v9 00/38] x86: Secure Memory Encryption (AMD)

* Tom Lendacky wrote: > This patch series provides support for AMD's new Secure Memory Encryption > (SME) > feature. I'm wondering, what's the typical performance hit to DRAM access latency when SME is enabled? On that same note, if the performance hit is

Re: [PATCH 2/2] x86/xen/efi: Init only efi struct members used by Xen

* Daniel Kiper wrote: > -static const struct efi efi_xen __initconst = { > - .systab = NULL, /* Initialized later. */ > - .runtime_version = 0,/* Initialized later. */ > - .mps = EFI_INVALID_TABLE_ADDR, > -

[GIT PULL] EFI fix

Linus, Please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus # HEAD: 792ef14df5c585c19b2831673a077504a09e5203 efi: Fix boot panic because of invalid BGRT image address A boot crash fix for certain

Re: [PATCH 10/13] efi/capsule: Add support for Quark security header

* Ard Biesheuvel wrote: > >> +config EFI_CAPSULE_QUIRK_QUARK_CSH > >> + boolean "Add support for Quark capsules with non-standard headers" > >> + depends on X86 && !64BIT > >> + select EFI_CAPSULE_LOADER > >> + default y > >> + help > >> +

Re: [GIT PULL 00/13] First batch of EFI updates for v4.13

* Ard Biesheuvel wrote: > > It would be nice to fix your SOB flow: the maintainer who queues up a patch > > should > > add the SOB, and add an Acked-by of the co-maintainer if the co-maintainer > > agrees > > with the patch as well. The tree should typically not be

Re: [PATCH 10/13] efi/capsule: Add support for Quark security header

* Ard Biesheuvel wrote: > From: Jan Kiszka > > The firmware for Quark X102x prepends a security header to the capsule > which is needed to support the mandatory secure boot on this processor. > The header can be detected by checking for the

[GIT PULL] EFI fixes

Linus, Please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus # HEAD: 7425826f4f7ac60f2538b06a7f0a5d1006405159 efi/bgrt: Skip efi_bgrt_init() in case of non-EFI boot Misc fixes: - three boot crash

[GIT PULL] EFI changes for v4.12

Linus, Please pull the latest efi-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-core-for-linus # HEAD: 197decefdb79d6f1350ba0316ce26ba737372d0c efi/libstub/arm: Don't use TASK_SIZE when randomizing the RT space The main changes in this cycle

Re: [GIT PULL 0/2] EFI fixes for v4.11

* Ard Biesheuvel wrote: > On 5 April 2017 at 11:08, Bartlomiej Zolnierkiewicz > wrote: > > > > Hi, > > > > On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote: > >> Hello all, > >> > >> Please pull these fixes for EFI framebuffer

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

* Ard Biesheuvel wrote: > > Turning KASLR off actively degrades that randomization of the kernel > > virtual > > addresses. > > > > Am I missing anything? > > > > No, I think you are right. UEFI runtime services region are likely to consist > of > R+W+X mappings

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

* Ard Biesheuvel wrote: > No. It is the firmware's EFI code, and the virtual translation applied by the > OS > is made known to the firmware by means of a call into the runtime service > SetVirtualAddressMap(). This service can only be called once after each boot,

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

om> > Acked-by: Dave Young <dyo...@redhat.com> > Reviewed-by: Bhupesh Sharma <bhsha...@redhat.com> > Acked-by: Thomas Garnier <thgar...@google.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: "H. Peter

  1   2   >