Linux EFI/UEFI Development

• Thread Index

• Re: [PATCH v2 0/8] Decode IA32/X64 CPER
  • From: Borislav Petkov <bp@xxxxxxx>
• [PATCH 3.16 061/254] efi: Move some sysfs files to be read-only by root
  • From: Ben Hutchings <ben@xxxxxxxxxxxxxxx>
• Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel
  • From: Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx>
• RE: [PATCH v2 0/8] Decode IA32/X64 CPER
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• Re: [PATCH v2 0/8] Decode IA32/X64 CPER
  • From: Borislav Petkov <bp@xxxxxxx>
• Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: [PATCH V1 1/3] x86/efi: Call efi_delete_dummy_variable() during efi subsystem initialization
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH v1] efi/apple-properties: Use memremap() instead of ioremap()
  • From: Lukas Wunner <lukas@xxxxxxxxx>
• Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: Borislav Petkov <bp@xxxxxxx>
• RE: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: Borislav Petkov <bp@xxxxxxx>
• RE: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• Re: [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section
  • From: Borislav Petkov <bp@xxxxxxx>
• RE: [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: Borislav Petkov <bp@xxxxxxx>
• RE: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• Re: [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section
  • From: Borislav Petkov <bp@xxxxxxx>
• Re: [PATCH v1] efi/apple-properties: Use memremap() instead of ioremap()
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• RE: [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• [PATCH v1] efi/apple-properties: Use memremap() instead of ioremap()
  • From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
• Re: [PATCH v2 5/8] efi: Decode IA32/X64 Cache, TLB, and Bus Check structures
  • From: Borislav Petkov <bp@xxxxxxx>
• Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: Borislav Petkov <bp@xxxxxxx>
• Re: [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section
  • From: Borislav Petkov <bp@xxxxxxx>
• RE: [PATCH v2 5/8] efi: Decode IA32/X64 Cache, TLB, and Bus Check structures
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• Re: [PATCH v2 4/8] efi: Decode UEFI-defined IA32/X64 Error Structure GUIDs
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• RE: [PATCH v2 4/8] efi: Decode UEFI-defined IA32/X64 Error Structure GUIDs
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• RE: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• RE: [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• RE: [PATCH v2 1/8] efi: Fix IA32/X64 Processor Error Record definition
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• Re: [PATCH v2 5/8] efi: Decode IA32/X64 Cache, TLB, and Bus Check structures
  • From: Borislav Petkov <bp@xxxxxxx>
• Re: [PATCH v2 4/8] efi: Decode UEFI-defined IA32/X64 Error Structure GUIDs
  • From: Borislav Petkov <bp@xxxxxxx>
• Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: Borislav Petkov <bp@xxxxxxx>
• Re: [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section
  • From: Borislav Petkov <bp@xxxxxxx>
• Re: [RFC PATCH v1] efi/apple-properties: Assume 32-bit values only for now
  • From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
• Re: [RFC PATCH v1] efi/apple-properties: Assume 32-bit values only for now
  • From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
• Re: [PATCH v2 1/8] efi: Fix IA32/X64 Processor Error Record definition
  • From: Borislav Petkov <bp@xxxxxxx>
• Re: 91f606a8fa ("x86/mm: Replace compile-time checks for 5-level .."): BUG: kernel reboot-without-warning in boot stage
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [RFC PATCH v1] efi/apple-properties: Assume 32-bit values only for now
  • From: Lukas Wunner <lukas@xxxxxxxxx>
• [RFC PATCH v1] efi/apple-properties: Assume 32-bit values only for now
  • From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
• [PATCH v2 1/8] efi: Fix IA32/X64 Processor Error Record definition
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH v2 5/8] efi: Decode IA32/X64 Cache, TLB, and Bus Check structures
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH v2 8/8] efi: Decode IA32/X64 Context Info structure
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH v2 4/8] efi: Decode UEFI-defined IA32/X64 Error Structure GUIDs
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH v2 6/8] efi: Decode additional IA32/X64 Bus Check fields
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH v2 7/8] efi: Decode IA32/X64 MS Check structure
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH v2 0/8] Decode IA32/X64 CPER
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• Re: [PATCH 8/8] efi: Decode IA32/X64 Context Info structure
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• RE: [PATCH 8/8] efi: Decode IA32/X64 Context Info structure
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• Re: [PATCH 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• RE: [PATCH 4/8] efi: Decode UEFI-defined IA32/X64 Error Structure GUIDs
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• RE: [PATCH 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• RE: [PATCH 2/8] efi: Decode IA32/X64 Processor Error Section
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• RE: [PATCH 0/8] Decode IA32/X64 CPER
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• Re: [PATCH 2/2] efi/esrt: mark ESRT memory region as nomap
  • From: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
• Re: [PATCH 2/2] efi/esrt: mark ESRT memory region as nomap
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• RE: [PATCH V1 2/3] efi: Introduce efi_rts_workqueue and necessary infrastructure to invoke all efi_runtime_services()
  • From: "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@xxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH V1 2/3] efi: Introduce efi_rts_workqueue and necessary infrastructure to invoke all efi_runtime_services()
  • From: Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx>
• [PATCH V1 1/3] x86/efi: Call efi_delete_dummy_variable() during efi subsystem initialization
  • From: Sai Praneeth Prakhya <sai.praneeth.prakhya@xxxxxxxxx>
• [PATCH V1 3/3] efi: Use efi_rts_workqueue to invoke EFI Runtime Services
  • From: Sai Praneeth Prakhya <sai.praneeth.prakhya@xxxxxxxxx>
• [PATCH V1 2/3] efi: Introduce efi_rts_workqueue and necessary infrastructure to invoke all efi_runtime_services()
  • From: Sai Praneeth Prakhya <sai.praneeth.prakhya@xxxxxxxxx>
• [PATCH V1 0/3] Use efi_rts_workqueue to invoke EFI Runtime Services
  • From: Sai Praneeth Prakhya <sai.praneeth.prakhya@xxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Alan Cox <gnomes@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/8] Decode IA32/X64 CPER
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 8/8] efi: Decode IA32/X64 Context Info structure
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 7/8] efi: Decode IA32/X64 MS Check structure
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 6/8] efi: Decode additional IA32/X64 Bus Check fields
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 5/8] efi: Decode IA32/X64 Cache, TLB, and Bus Check structures
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 4/8] efi: Decode UEFI-defined IA32/X64 Error Structure GUIDs
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 2/8] efi: Decode IA32/X64 Processor Error Section
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 2/2] efi/esrt: mark ESRT memory region as nomap
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 2/2] efi/esrt: mark ESRT memory region as nomap
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [PATCH 1/2] efi/esrt: fix unsupported version initialization failure
  • From: Dave Young <dyoung@xxxxxxxxxx>
• [PATCH 3.18 53/58] mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2] efivarfs: Limit the rate for non-root to read files
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH 4.4 058/193] mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 2/8] efi: Decode IA32/X64 Processor Error Section
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH 1/8] efi: Fix IA32/X64 Processor Error Record definition
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH 3/8] efi: Decode IA32/X64 Processor Error Info Structure
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH 6/8] efi: Decode additional IA32/X64 Bus Check fields
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH 4/8] efi: Decode UEFI-defined IA32/X64 Error Structure GUIDs
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH 7/8] efi: Decode IA32/X64 MS Check structure
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH 5/8] efi: Decode IA32/X64 Cache, TLB, and Bus Check structures
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH 8/8] efi: Decode IA32/X64 Context Info structure
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• [PATCH 0/8] Decode IA32/X64 CPER
  • From: Yazen Ghannam <Yazen.Ghannam@xxxxxxx>
• Re: [PATCH] efivarfs: Limit the rate for non-root to read files
  • From: Peter Jones <pjones@xxxxxxxxxx>
• [PATCH 4.9 082/145] mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 1/2] efi/esrt: fix unsupported version initialization failure
  • From: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
• [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel
  • From: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
• [PATCH 2/2] efi/esrt: mark ESRT memory region as nomap
  • From: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
• [PATCH 4.14 147/159] mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down
  • From: Jiri Bohac <jbohac@xxxxxxx>
• Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down
  • From: Jiri Bohac <jbohac@xxxxxxx>
• Re: [PATCH 04/30] Enforce module signatures if the kernel is locked down
  • From: Jiri Bohac <jbohac@xxxxxxx>
• Re: [PATCH v2] efivarfs: Limit the rate for non-root to read files
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2] efivarfs: Limit the rate for non-root to read files
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH v2] efivarfs: Limit the rate for non-root to read files
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• [PATCH v2] efivarfs: Limit the rate for non-root to read files
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH v2] efivarfs: Limit the rate for non-root to read files
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH] efivarfs: Limit the rate for non-root to read files
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• RE: [PATCH] efivarfs: Limit the rate for non-root to read files
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH] efivarfs: Limit the rate for non-root to read files
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• [PATCH] efivarfs: Limit the rate for non-root to read files
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH 04/30] Enforce module signatures if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• RE: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• RE: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Peter Jones <pjones@xxxxxxxxxx>
• RE: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Matthew Garrett <mjg59@xxxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Matthew Garrett <mjg59@xxxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Matthew Garrett <mjg59@xxxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: Read-protected UEFI variables
  • From: Alan Cox <gnomes@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Peter Jones <pjones@xxxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Matthew Garrett <mjg59@xxxxxxxxxx>
• RE: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Matthew Garrett <mjg59@xxxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• RE: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Peter Jones <pjones@xxxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Matthew Garrett <mjg59@xxxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• RE: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Peter Jones <pjones@xxxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Joe Konno <joe.konno@xxxxxxxxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: Read-protected UEFI variables
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 1/2] fs/efivarfs: restrict inode permissions
  • From: Joe Konno <joe.konno@xxxxxxxxxxxxxxx>
• [PATCH 2/2] efi: restrict top-level attribute permissions
  • From: Joe Konno <joe.konno@xxxxxxxxxxxxxxx>
• [PATCH 0/2] efivars: reading variables can generate SMIs
  • From: Joe Konno <joe.konno@xxxxxxxxxxxxxxx>
• Re: Read-protected UEFI variables
  • From: "Austin S. Hemmelgarn" <ahferroin7@xxxxxxxxx>
• Re: Read-protected UEFI variables
  • From: Benjamin Drung <benjamin.drung@xxxxxxxxxxxxxxxx>
• Re: Read-protected UEFI variables
  • From: Môshe van der Sterre <me@xxxxxxxx>
• Re: Read-protected UEFI variables
  • From: Benjamin Drung <benjamin.drung@xxxxxxxxxxxxxxxx>
• Re: Read-protected UEFI variables
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Read-protected UEFI variables
  • From: Benjamin Drung <benjamin.drung@xxxxxxxxxxxxxxxx>
• Re: efi/apple-properties: Checking error handling in unmarshal_devices()
  • From: SF Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] efi/apple-properties: Delete an error message for a failed memory allocation in unmarshal_devices()
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH] efi/apple-properties: Delete an error message for a failed memory allocation in unmarshal_devices()
  • From: Lukas Wunner <lukas@xxxxxxxxx>
• Re: [PATCH] x86: efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH] x86: efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• [PATCH] efi/apple-properties: Delete an error message for a failed memory allocation in unmarshal_devices()
  • From: SF Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx>
• [PATCH] efi: Delete an error message for a failed memory allocation in efivar_init()
  • From: SF Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx>
• [PATCH AUTOSEL for 4.14 082/110] x86/efi: Fix kernel param add_efi_memmap regression
  • From: Sasha Levin <Alexander.Levin@xxxxxxxxxxxxx>
• [PATCH 4.14 156/156] x86/efi: Clarify that reset attack mitigation needs appropriate userspace
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.15 55/55] x86/efi: Clarify that reset attack mitigation needs appropriate userspace
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] x86/debugfs: Add the EFI pagetable to the debugfs 'page_tables' directory
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH] x86/debugfs: Add the EFI pagetable to the debugfs 'page_tables' directory
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH 0/4] efi/arm64: unmap the kernel during runtime service calls
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 0/4] efi/arm64: unmap the kernel during runtime service calls
  • From: Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx>
• Re: [PATCH V4 0/3] Use mm_struct and switch_mm() instead of manually
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [GIT PULL] EFI changes for v4.16
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• [PATCH AUTOSEL for 4.14 094/100] mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep
  • From: Sasha Levin <Alexander.Levin@xxxxxxxxxxxxx>
• [PATCH AUTOSEL for 4.9 45/49] mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep
  • From: Sasha Levin <Alexander.Levin@xxxxxxxxxxxxx>
• [PATCH AUTOSEL for 4.4 33/36] mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep
  • From: Sasha Levin <Alexander.Levin@xxxxxxxxxxxxx>
• [PATCH AUTOSEL for 3.18 22/25] mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep
  • From: Sasha Levin <Alexander.Levin@xxxxxxxxxxxxx>
• Re: [PATCH V4 0/3] Use mm_struct and switch_mm() instead of manually
  • From: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 4/4] efi/arm64: unmap the kernel while executing UEFI services
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH 2/4] efi/arm64: map the stack and entry wrapper into the UEFI page tables
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH 4/4] efi/arm64: unmap the kernel while executing UEFI services
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 4/4] efi/arm64: unmap the kernel while executing UEFI services
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH 2/4] efi/arm64: map the stack and entry wrapper into the UEFI page tables
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 2/4] efi/arm64: map the stack and entry wrapper into the UEFI page tables
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH 1/4] efi: arm64: Check whether x18 is preserved by runtime services calls
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH 4/4] efi/arm64: unmap the kernel while executing UEFI services
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 3/4] efi/arm64: marshall runtime services arguments via buffer in TTBR0
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 2/4] efi/arm64: map the stack and entry wrapper into the UEFI page tables
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 1/4] efi: arm64: Check whether x18 is preserved by runtime services calls
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 0/4] efi/arm64: unmap the kernel during runtime service calls
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH] x86: efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH] x86: efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store
  • From: Jia-Ju Bai <baijiaju1990@xxxxxxxxx>
• Re: [PATCH 0/4] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH] efi/arm*: Only register page tables when they exist
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH v1] efi/apple-properties: Device core takes care of empty properties
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH] x86/efi: Fix trailing semicolons
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH] x86/efi: Fix trailing semicolons
  • From: Luis de Bethencourt <luisbg@xxxxxxxxxx>
• Re: [PATCH v1] efi/apple-properties: Device core takes care of empty properties
  • From: Lukas Wunner <lukas@xxxxxxxxx>
• [PATCH v1] efi/apple-properties: Device core takes care of empty properties
  • From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
• Re: [PATCH] efi: arm: stop printing addresses of virtual mappings
  • From: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
• Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE
  • From: Jiri Bohac <jbohac@xxxxxxx>
• [PATCH] efi: arm: stop printing addresses of virtual mappings
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH V4 1/3] efi: Use efi_mm in x86 as well as ARM
  • From: Sai Praneeth Prakhya <sai.praneeth.prakhya@xxxxxxxxx>
• [PATCH V4 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3
  • From: Sai Praneeth Prakhya <sai.praneeth.prakhya@xxxxxxxxx>
• [PATCH V4 2/3] x86/efi: Replace efi_pgd with efi_mm.pgd
  • From: Sai Praneeth Prakhya <sai.praneeth.prakhya@xxxxxxxxx>
• [PATCH V4 0/3] Use mm_struct and switch_mm() instead of manually
  • From: Sai Praneeth Prakhya <sai.praneeth.prakhya@xxxxxxxxx>
• [PATCH] efi: arm64: Check whether x18 is preserved by runtime services calls
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH] efi/arm*: Only register page tables when they exist
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH] efi/arm*: Only register page tables when they exist
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE
  • From: Jiri Bohac <jbohac@xxxxxxx>
• Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH] efi/arm*: Only register page tables when they exist
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• [PATCH 4.14 090/118] x86/pti: Unbreak EFI old_memmap
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] efi: Clarify that reset attack mitigation needs appropriate userspace
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 0/4] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot
  • From: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
• Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down
  • From: Jiri Bohac <jbohac@xxxxxxx>
• Re: [PATCH 1/2] kconfig: use bool instead of boolean for type definition attributes, again
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• Re: [PATCH 0/4] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 08b/30] kexec_file: Restrict at runtime if the kernel is locked down
  • From: Jiri Bohac <jbohac@xxxxxxx>
• [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE
  • From: Jiri Bohac <jbohac@xxxxxxx>
• Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down
  • From: Jiri Bohac <jbohac@xxxxxxx>
• [PATCH 0/4] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot
  • From: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
• [PATCH 2/4] x86/xen/efi: Initialize boot_params.secure_boot in xen_efi_init()
  • From: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
• [PATCH 4/4] efi: Rename efi_get_secureboot() to __efi_get_secureboot() and make it static
  • From: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
• [PATCH 3/4] efi: Tweak efi_get_secureboot() and its data section assignment
  • From: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
• [PATCH 1/4] efi/stub: Extract efi_get_secureboot() to separate file
  • From: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• [PATCH] efi: Clarify that reset attack mitigation needs appropriate userspace
  • From: Matthew Garrett <mjg59@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• [PATCH 4.14 13/38] efi/capsule-loader: Reinstate virtual capsule mapping
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH] PTI: unbreak EFI old_memmap
  • From: Jiri Kosina <jikos@xxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH] MAINTAINERS: Add Ard Biesheuvel to EFI test driver and efivarfs
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer
  • From: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer
  • From: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>
• [PATCH 2/5] arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 5/5] efi: parse ARM error information value
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 4/5] efi: move ARM CPER code to new file
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 3/5] efi: Use PTR_ERR_OR_ZERO()
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 1/5] efi/capsule-loader: pr_err() strings should end with newlines
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [GIT PULL 0/5] EFI updates for v4.16
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 2/2] efi: capsule-loader: reinstate virtual capsule mapping
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 1/2] x86/efi: Fix kernel param add_efi_memmap regression
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [GIT PULL 0/2] EFI fixes for v4.15
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• RE: [RFT PATCH] efi: capsule-loader: reinstate virtual capsule mapping
  • From: "Song, Ge" <ge.song@xxxxxxxxxxxxxxxx>
• Re: [RFT PATCH] efi: capsule-loader: reinstate virtual capsule mapping
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [RFT PATCH] efi: capsule-loader: reinstate virtual capsule mapping
  • From: "Bryan O'Donoghue" <pure.logic@xxxxxxxxxxxxxxxxx>
• Re: [GIT PULL 0/2] EFI updates for v4.15
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH] module: allow symbol exports to be disabled
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [GIT PULL 0/2] EFI updates for v4.15
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• [RFT PATCH] efi: capsule-loader: reinstate virtual capsule mapping
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [GIT PULL 0/2] EFI updates for v4.15
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• Re: [PATCH 0/2] Make capsules in a contiguous virtual space
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: [PATCH 0/2] Make capsules in a contiguous virtual space
  • From: Richard Ruigrok <rruigrok@xxxxxxxxxxxxxx>
• BUG: EFI capsule loader fails as of 4.13, the capsule is not passed in contiguous virtual memory
  • From: Richard Ruigrok <rruigrok@xxxxxxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• Re: EFI crash with PCID on
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: EFI crash with PCID on
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• EFI crash with PCID on
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 0/2] Make capsules in a contiguous virtual space
  • From: Ge Song <ge.song@xxxxxxxxxxxxxxxx>
• [PATCH 1/2] Revert "efi/capsule-loader: Use page addresses rather than struct page pointers"
  • From: Ge Song <ge.song@xxxxxxxxxxxxxxxx>
• [PATCH 2/2] efi/capsule-loader: Request a contiguous virtual space for capsules
  • From: Ge Song <ge.song@xxxxxxxxxxxxxxxx>
• RE: [PATCH 0/3] Use mm_struct and switch_mm() instead of manually
  • From: "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@xxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• Re: [PATCH V3 0/2] CPER ARM error information parsing
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH V2] x86/efi: fix kernel param add_efi_memmap regression
  • From: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap
  • From: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh SHARMA <bhupesh.linux@xxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [PATCH 0/3] Use mm_struct and switch_mm() instead of manually
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• [PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3
  • From: Sai Praneeth Prakhya <sai.praneeth.prakhya@xxxxxxxxx>
• [PATCH 2/3] x86/efi: Replace efi_pgd with efi_mm.pgd
  • From: Sai Praneeth Prakhya <sai.praneeth.prakhya@xxxxxxxxx>
• [PATCH 1/3] efi: Use efi_mm in x86 as well as ARM
  • From: Sai Praneeth Prakhya <sai.praneeth.prakhya@xxxxxxxxx>
• [PATCH 0/3] Use mm_struct and switch_mm() instead of manually
  • From: Sai Praneeth Prakhya <sai.praneeth.prakhya@xxxxxxxxx>
• Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• [PATCH] efi: make EFI a menuconfig to ease disabling it all
  • From: Vincent Legoll <vincent.legoll@xxxxxxxxx>
• [PATCH,v2] efi: make EFI a menuconfig to ease disabling it all
  • From: Vincent Legoll <vincent.legoll@xxxxxxxxx>
• [PATCH V2] x86/efi: fix kernel param add_efi_memmap regression
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [PATCH 1/2] kconfig: use bool instead of boolean for type definition attributes, again
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] efi: make EFI a menuconfig to ease disabling it all
  • From: "Austin S. Hemmelgarn" <ahferroin7@xxxxxxxxx>
• Re: [PATCH] efi: make EFI a menuconfig to ease disabling it all
  • From: Vincent Legoll <vincent.legoll@xxxxxxxxx>
• Re: [PATCH] efi: make EFI a menuconfig to ease disabling it all
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 1/2] kconfig: use bool instead of boolean for type definition attributes, again
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• Re: [PATCH] efi: make EFI a menuconfig to ease disabling it all
  • From: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap
  • From: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] efi: Use PTR_ERR_OR_ZERO()
  • From: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.4 013/105] efi: Move some sysfs files to be read-only by root
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.4 103/105] Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.4 102/105] Revert "x86/efi: Hoist page table switching code into efi_call_virt()"
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.4 101/105] Revert "x86/efi: Build our own page table structures"
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 3.18 11/64] efi: Move some sysfs files to be read-only by root
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Booting LiveCD image from EFI PXE?
  • From: Locane <locane@xxxxxxxxx>
• Re: [PATCH 4.4 05/27] x86/efi: Build our own page table structures
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh SHARMA <bhupesh.linux@xxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• RE: [PATCH 4.4 05/27] x86/efi: Build our own page table structures
  • From: "Ghannam, Yazen" <Yazen.Ghannam@xxxxxxx>
• [PATCH V3 2/2] efi: parse ARM error information value
  • From: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
• [PATCH V3 1/2] efi: move ARM CPER code to new file
  • From: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
• [PATCH V3 0/2] CPER ARM error information parsing
  • From: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
• [PATCH 4.14 038/164] efi: Move some sysfs files to be read-only by root
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.14 039/164] efi/esrt: Use memunmap() instead of kfree() to free the remapping
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.9 017/148] efi/esrt: Use memunmap() instead of kfree() to free the remapping
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.9 016/148] efi: Move some sysfs files to be read-only by root
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 41/45] arch/x86: remove duplicate includes
  • From: Juergen Gross <jgross@xxxxxxxx>
• Re: [PATCH V2 1/2] efi: move ARM CPER code to new file
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH v5 2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• [PATCH v5 1/2] arm64: Define cputype macros for Falkor CPU
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• Re: [RESEND PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• Re: [PATCH V2 1/2] efi: move ARM CPER code to new file
  • From: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
• Re: [PATCH V2 1/2] efi: move ARM CPER code to new file
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH V2 1/2] efi: move ARM CPER code to new file
  • From: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
• [PATCH 41/45] arch/x86: remove duplicate includes
  • From: Pravin Shedge <pravin.shedge4linux@xxxxxxxxx>
• Re: [RESEND PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• [RESEND PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• [RESEND PATCH v4 1/2] arm64: Define cputype macros for Falkor CPU
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• Re: [PATCH 4.4 05/27] x86/efi: Build our own page table structures
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH] efi: make EFI a menuconfig to ease disabling it all
  • From: Vincent Legoll <vincent.legoll@xxxxxxxxx>
• [PATCH resend] fix boot hang with earlyprintk=efi,keep
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Alan Cox <gnomes@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
  • From: Gary Lin <glin@xxxxxxxx>
• Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
  • From: Gary Lin <glin@xxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
• Re: [PATCH 4.4 05/27] x86/efi: Build our own page table structures
  • From: Ben Hutchings <ben.hutchings@xxxxxxxxxxxxxxx>
• Re: [PATCH V2 1/2] efi: move ARM CPER code to new file
  • From: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
• Re: [PATCH V2 1/2] efi: move ARM CPER code to new file
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH V2 2/2] efi: parse ARM error information value
  • From: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
• [PATCH V2 1/2] efi: move ARM CPER code to new file
  • From: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
• [PATCH V2 0/2] CPER ARM error information parsing
  • From: Tyler Baicar <tbaicar@xxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Alan Cox <gnomes@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
  • From: Alan Cox <gnomes@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
  • From: Gary Lin <glin@xxxxxxxx>
• Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
  • From: Gary Lin <glin@xxxxxxxx>
• Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
  • From: Gary Lin <glin@xxxxxxxx>
• Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [GIT PULL 0/3] EFI fixes for v4.15
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• [PATCH 1/3] efi: move some sysfs files to be read-only by root
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 2/3] efi/esrt: use memunmap rather kfree to free the remapping
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 3/3] efi: add comment to avoid future expanding of sysfs systab
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [GIT PULL 0/3] EFI fixes for v4.15
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH] efi: move some sysfs files to be read-only by root
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
  • From: Gary Lin <glin@xxxxxxxx>
• Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
  • From: Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx>
• Re: [PATCH] efi: move some sysfs files to be read-only by root
  • From: "Tobin C. Harding" <me@xxxxxxxx>
• Re: [PATCH v2] efi: move some sysfs files to be read-only by root
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: efi/esrt: use memunmap rather kfree to free the remapping
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH v2] efi: move some sysfs files to be read-only by root
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] efi: move some sysfs files to be read-only by root
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Pavel Machek <pavel@xxxxxx>
• Re: [PATCH] efi: move some sysfs files to be read-only by root
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH] efi: add comment to avoid future expanding of sysfs systab
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH] efi: move some sysfs files to be read-only by root
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [RFC v3 PATCH 2/2] arm64/efi: Introduce Security Version to ARM64
  • From: Gary Lin <glin@xxxxxxxx>
• [RFC v3 PATCH 1/2] x86/efi: Introduce Security Version to x86
  • From: Gary Lin <glin@xxxxxxxx>
• [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub
  • From: Gary Lin <glin@xxxxxxxx>
• [PATCH] efi: add comment to avoid future expanding of sysfs systab
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
• [PATCH 4.4 03/27] x86/mm/pat: Ensure cpa->pfn only contains page frame numbers
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.4 05/27] x86/efi: Build our own page table structures
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.4 04/27] x86/efi: Hoist page table switching code into efi_call_virt()
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• RE: [GIT PULL] hash addresses printed with %p
  • From: David Laight <David.Laight@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [PATCH] fix system_state checking in early_ioremap
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH] fix system_state checking in early_ioremap
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/4] MODSIGN: do not load mok when secure boot disabled
  • From: joeyli <jlee@xxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/4] MODSIGN: do not load mok when secure boot disabled
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• [PATCH v5 19/27] x86: assembly, make some functions local
  • From: Jiri Slaby <jslaby@xxxxxxx>
• [PATCH v5 26/27] x86_32: assembly, change all ENTRY+ENDPROC to SYM_FUNC_*
  • From: Jiri Slaby <jslaby@xxxxxxx>
• [PATCH v5 23/27] x86_64: assembly, change all ENTRY+ENDPROC to SYM_FUNC_*
  • From: Jiri Slaby <jslaby@xxxxxxx>
• [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: [GIT PULL] hash addresses printed with %p
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• [PATCH 2/4] MODSIGN: print appropriate status message when getting UEFI certificates list
  • From: "Lee, Chun-Yi" <joeyli.kernel@xxxxxxxxx>
• [PATCH 4/4] MODSIGN: checking the blacklisted hash before loading a kernel module
  • From: "Lee, Chun-Yi" <joeyli.kernel@xxxxxxxxx>
• [PATCH 3/4] MODSIGN: load blacklist from MOKx
  • From: "Lee, Chun-Yi" <joeyli.kernel@xxxxxxxxx>
• [PATCH 1/4] MODSIGN: do not load mok when secure boot disabled
  • From: "Lee, Chun-Yi" <joeyli.kernel@xxxxxxxxx>
• [PATCH 0/4] Using the hash in MOKx to blacklist kernel module
  • From: "Lee, Chun-Yi" <joeyli.kernel@xxxxxxxxx>
• [PATCH 0/4] Using the hash in MOKx to blacklist kernel module
  • From: "Lee, Chun-Yi" <joeyli.kernel@xxxxxxxxx>
• [PATCH] efi: Use PTR_ERR_OR_ZERO()
  • From: Vasyl Gomonovych <gomonovych@xxxxxxxxx>
• [PATCH v4 1/2] arm64: Define cputype macros for Falkor CPU
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• [PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• [PATCH v4 0/2] Implement a software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh SHARMA <bhupesh.linux@xxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Dave Young <dyoung@xxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v3 2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Timur Tabi <timur@xxxxxxxxxxxxxx>
• Re: Draft manpage explaining kernel lockdown
  • From: Pavel Machek <pavel@xxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
• Re: [v3,2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Manoj Iyer <manoj.iyer@xxxxxxxxxxxxx>
• Re: [3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: Manoj Iyer <manoj.iyer@xxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• Re: [PATCH v3 2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Stephen Boyd <sboyd@xxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Matthew Garrett <mjg59@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Matthew Garrett <mjg59@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Matthew Garrett <mjg59@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Matthew Garrett <mjg59@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Matthew Garrett <mjg59@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Matthew Garrett <mjg59@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Alan Cox <gnomes@xxxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Alan Cox <gnomes@xxxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• Re: [PATCH v2 2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• [PATCH v3 1/2] arm64: Define cputype macros for Falkor CPU
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• [PATCH v3 2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• [PATCH v3 0/2] Implement a software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• [PATCH v2 1/2] arm64: Define cputype macros for Falkor CPU
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• [PATCH v2 2/2] arm64: Add software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• [PATCH v2 0/2] Implement a software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Alan Cox <gnomes@xxxxxxxxxxxxxxxxxxx>
• Re: [3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: Manoj Iyer <manoj.iyer@xxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
  • From: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
• Re: [PATCH 26/30] Lock down ftrace
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: James Morse <james.morse@xxxxxxx>
• Re: [PATCH 26/30] Lock down ftrace
  • From: Jiri Kosina <jikos@xxxxxxxxxx>
• Re: [PATCH 26/30] Lock down ftrace
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 26/30] Lock down ftrace
  • From: Jiri Kosina <jikos@xxxxxxxxxx>
• Re: [PATCH 26/30] Lock down ftrace
  • From: Jiri Kosina <jikos@xxxxxxxxxx>
• Re: [PATCH 26/30] Lock down ftrace
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
• [PATCH 00/30] security, efi: Add kernel lockdown
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 01/30] Add the ability to lock down access to the running kernel image
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 06/30] kexec: Disable at runtime if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 05/30] Restrict /dev/{mem, kmem, port} when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 03/30] ima: require secure_boot rules in lockdown mode
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 07/30] Copy secure_boot flag in boot params across kexec reboot
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 11/30] PCI: Lock down BAR access when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 10/30] uswsusp: Disable when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 13/30] x86/msr: Restrict MSR access when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 12/30] x86: Lock down IO port access when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 15/30] ACPI: Limit access to custom_method when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 14/30] asus-wmi: Restrict debugfs interface when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 16/30] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 17/30] acpi: Disable ACPI table override if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 19/30] scsi: Lock down the eata driver
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 18/30] acpi: Disable APEI error injection if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 21/30] Lock down TIOCSSERIAL
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 20/30] Prohibit PCMCIA CIS storage when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 22/30] Lock down module params that specify hardware parameters (eg. ioport)
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 24/30] debugfs: Disallow use of debugfs files when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 23/30] x86/mmiotrace: Lock down the testmmiotrace module
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 25/30] Lock down /proc/kcore
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 26/30] Lock down ftrace
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 27/30] Lock down kprobes
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 28/30] bpf: Restrict kernel image access functions when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 29/30] efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 30/30] efi: Lock down the kernel if booted in secure boot mode
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 09/30] hibernate: Disable when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 04/30] Enforce module signatures if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 02/30] Add a SysRq option to lift kernel lockdown
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: Manoj Iyer <manoj.iyer@xxxxxxxxxxxxx>
• Re: [3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: Manoj Iyer <manoj.iyer@xxxxxxxxxxxxx>
• Re: [3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: Manoj Iyer <manoj.iyer@xxxxxxxxxxxxx>
• Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: James Morse <james.morse@xxxxxxx>
• Re: [3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: James Morse <james.morse@xxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "AKASHI, Takahiro" <takahiro.akashi@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "AKASHI, Takahiro" <takahiro.akashi@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
• Re: [3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: Manoj Iyer <manoj.iyer@xxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "AKASHI, Takahiro" <takahiro.akashi@xxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
• Re: [PATCH 02/27] Add a SysRq option to lift kernel lockdown
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 02/27] Add a SysRq option to lift kernel lockdown
  • From: Thiago Jung Bauermann <bauerman@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v10 20/38] x86, mpparse: Use memremap to map the mpf and mpc data
  • From: Tomeu Vizoso <tomeu@xxxxxxxxxxxxxxx>
• Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• Re: [PATCH v10 20/38] x86, mpparse: Use memremap to map the mpf and mpc data
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• Re: [PATCH v2 0/3] Call GetEventLog before ExitBootServices
  • From: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx>
• Re: [PATCH v10 20/38] x86, mpparse: Use memremap to map the mpf and mpc data
  • From: Tomeu Vizoso <tomeu@xxxxxxxxxxxxxxx>
• Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: Robin Murphy <robin.murphy@xxxxxxx>
• [PATCH 1/3] arm64: Define cputype macros for Falkor CPU
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• [PATCH 2/3] arm64: Prepare SCTLR_ELn accesses to handle Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• [PATCH 0/3] Implement a software workaround for Falkor erratum 1041
  • From: Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>
• Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 00/27] security, efi: Add kernel lockdown
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• efi/esrt: use memunmap rather kfree to free the remapping
  • From: Pan Bian <bianpan2016@xxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• [PATCH] efi: setting secure boot flag in EFI stub when the sentinel is tainted.
  • From: "Lee, Chun-Yi" <joeyli.kernel@xxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: joeyli <jlee@xxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• [GIT PULL] EFI fixes
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map
  • From: Matthias Brugger <mbrugger@xxxxxxxx>
• Re: [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map
  • From: Matthias Brugger <mbrugger@xxxxxxxx>
• Re: [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx>
• Re: [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map
  • From: Matthias Brugger <mbrugger@xxxxxxxx>
• Re: [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map
  • From: Gregory CLEMENT <gregory.clement@xxxxxxxxxxxxxxxxxx>
• Re: Multiple Acer laptops hang on ACPI poweroff
  • From: Daniel Drake <drake@xxxxxxxxxxxx>
• Re: Multiple Acer laptops hang on ACPI poweroff
  • From: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>
• Re: Multiple Acer laptops hang on ACPI poweroff
  • From: Daniel Drake <drake@xxxxxxxxxxxx>
• Re: [GIT PULL] Kernel lockdown for secure boot
  • From: James Morris <james.l.morris@xxxxxxxxxx>
• Re: [PATCH v3 4/5] efi: call get_event_log before ExitBootServices
  • From: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx>
• Re: [GIT PULL] Kernel lockdown for secure boot
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• [GIT PULL] Kernel lockdown for secure boot
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: joeyli <jlee@xxxxxxxx>
• Re: [PATCH v4 19/27] x86: assembly, make some functions local
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• Re: [PATCH v4 19/27] x86: assembly, make some functions local
  • From: Jiri Slaby <jslaby@xxxxxxx>
• Re: [PATCH v4 19/27] x86: assembly, make some functions local
  • From: Jiri Slaby <jslaby@xxxxxxx>
• Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down
  • From: joeyli <jlee@xxxxxxxx>
• [PATCH 2/2] arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 1/2] efi/capsule-loader: pr_err() strings should end with newlines
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [GIT PULL 0/2] EFI updates for v4.15
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 1/2] efi/efi_test: Prevent an Oops in efi_runtime_query_capsulecaps()
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [PATCH 2/2] efi/libstub: arm: don't randomize runtime regions when CONFIG_HIBERNATION=y
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• [GIT PULL 0/2] EFI fixes for v4.14
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down
  • From: joeyli <jlee@xxxxxxxx>
• Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx>
• Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down
  • From: Ethan Zhao <ethan.kernel@xxxxxxxxx>
• Re: [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map
  • From: Matthias Brugger <matthias.bgg@xxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 26/27] efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 25/27] Lock down /proc/kcore
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH] efi/libstub: arm: don't randomize runtime regions when CONFIG_HIBERNATION=y
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map
  • From: jeffy <jeffy.chen@xxxxxxxxxxxxxx>
• [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down
  • From: joeyli <jlee@xxxxxxxx>
• Re: [PATCH 26/27] efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode
  • From: James Morris <james.l.morris@xxxxxxxxxx>
• Re: [PATCH 25/27] Lock down /proc/kcore
  • From: James Morris <james.l.morris@xxxxxxxxxx>
• Re: [PATCH 09/27] uswsusp: Disable when the kernel is locked down
  • From: James Morris <james.l.morris@xxxxxxxxxx>
• Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set
  • From: James Morris <james.l.morris@xxxxxxxxxx>
• Re: [PATCH 05/27] kexec: Disable at runtime if the kernel is locked down
  • From: James Morris <james.l.morris@xxxxxxxxxx>
• Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down
  • From: James Morris <james.l.morris@xxxxxxxxxx>
• Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down
  • From: James Morris <james.l.morris@xxxxxxxxxx>
• Re: [PATCH 01/27] Add the ability to lock down access to the running kernel image
  • From: James Morris <james.l.morris@xxxxxxxxxx>
• Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down
  • From: Alan Cox <gnomes@xxxxxxxxxxxxxxxxxxx>