Re: [PATCH v3 1/2] efi: Add 'nr_config_table' variable in efi structure
On Mon, Jun 19, 2017 at 10:54 AM, Qiuxu Zhuo wrote:
> The 'nr_config_table' and 'config_table' (alreay in efi structure)
> in efi structure provide a way for some driver(e.g. capsule-pstore
> goes through the configuration table to extract crash capsules to
> aid in debugging) iterates over the EFI configuration table array.
>
> Signed-off-by: Qiuxu Zhuo
> ---
> arch/x86/platform/efi/efi.c | 1 +
> drivers/firmware/efi/efi.c | 1 +
> include/linux/efi.h | 1 +
> 3 files changed, 3 insertions(+)
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 7e76a4d..bcda1b9 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -498,6 +498,7 @@ void __init efi_init(void)
> return;
>
> efi.config_table = (unsigned long)efi.systab->tables;
> + efi.nr_config_table = (unsigned long)efi.systab->nr_tables;
> efi.fw_vendor= (unsigned long)efi.systab->fw_vendor;
> efi.runtime = (unsigned long)efi.systab->runtime;
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index b372aad..b511197 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -48,6 +48,7 @@ struct efi __read_mostly efi = {
> .fw_vendor = EFI_INVALID_TABLE_ADDR,
> .runtime= EFI_INVALID_TABLE_ADDR,
> .config_table = EFI_INVALID_TABLE_ADDR,
> + .nr_config_table= EFI_INVALID_TABLE_ADDR,
> .esrt = EFI_INVALID_TABLE_ADDR,
> .properties_table = EFI_INVALID_TABLE_ADDR,
> .mem_attr_table = EFI_INVALID_TABLE_ADDR,
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index ec36f42..bd5ff8f 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -892,6 +892,7 @@ extern struct efi {
> unsigned long fw_vendor;/* fw_vendor */
> unsigned long runtime; /* runtime table */
> unsigned long config_table; /* config tables */
> + unsigned long nr_config_table;
The other fields have (limited) comments. This should probably get one too.
-Kees
> unsigned long esrt; /* ESRT table */
> unsigned long properties_table; /* properties table */
> unsigned long mem_attr_table; /* memory attributes table */
> --
> 2.9.0.GIT
>
--
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] eif/capsule-pstore: Add capsule pstore backend
On Mon, Jun 19, 2017 at 10:54 AM, Qiuxu Zhuo wrote: > The EFI capsule mechanism allows data blobs to be passed to the EFI > firmware. By setting the EFI_CAPSULE_POPULATE_SYSTEM_TABLE and the > EFI_CAPSULE_PERSIST_ACROSS_REBOOT flags, the firmware will place a > pointer to our data blob in the EFI System Table on the next boot. > We can utilise this facility to save crash dumps, call traces, etc > and pick them up to aid in debugging after reboot. > > Initial cut at this driver by Matt Fleming as below links > https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=capsule-pstore&id=99c5f047133555aa0442f64064e85b7da2d4a45f > https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=capsule-pstore&id=8625c776c9b8bbed7fa4aa023e36542615165240 > Extensive cleanup, refactoring, bug fix, and verification by Qiuxu Zhuo > > Patch verified on Intel Kabylake client platform + Intel KBL > BIOS:(10/24/2016): > - modprobe capsule-pstore > - echo "Test pmsg on capsule-pstore" > /dev/pmsg0 > - echo 1 > /sys/module/kernel/parameters/panic > - echo c > /proc/sysrq-trigger > - system reboot... > - ls -l /sys/fs/pstore/ > -r--r--r-- 1 root root 4946 6月 19 14:05 console-capsule-pstore-0 > -r--r--r-- 1 root root 8976 6月 19 14:03 > dmesg-capsule-pstore-6433226157407076353 > -r--r--r-- 1 root root 9043 6月 19 14:03 > dmesg-capsule-pstore-6433226157407076354 > -r--r--r-- 1 root root 9069 6月 19 14:03 > dmesg-capsule-pstore-6433226157407076355 > -r--r--r-- 1 root root 9092 6月 19 14:03 > dmesg-capsule-pstore-6433226157407076356 > -r--r--r-- 1 root root 8976 6月 19 14:03 > dmesg-capsule-pstore-6433226157407076357 > -r--r--r-- 1 root root 9028 6月 19 14:03 > dmesg-capsule-pstore-6433226157407076358 > -r--r--r-- 1 root root 28 6月 19 14:05 pmsg-capsule-pstore-0 > > The above files contain pmsg log and the last console/dmesg logs. > > Signed-off-by: Qiuxu Zhuo > --- > drivers/firmware/efi/Kconfig | 21 ++ > drivers/firmware/efi/Makefile | 1 + > drivers/firmware/efi/capsule-pstore.c | 671 > ++ > 3 files changed, 693 insertions(+) > create mode 100644 drivers/firmware/efi/capsule-pstore.c > > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig > index 2e78b0b..aab78a7 100644 > --- a/drivers/firmware/efi/Kconfig > +++ b/drivers/firmware/efi/Kconfig > @@ -142,6 +142,27 @@ config APPLE_PROPERTIES > > If unsure, say Y if you have a Mac. Otherwise N. > > +config EFI_CAPSULE_PSTORE > + tristate "EFI capsule pstore backend" > + depends on EFI && PSTORE > + help > + Saying Y here enable the EFI capsule mechanism to store crash dumps, > + console log, and function tracing data. > + > + To compile this driver as a module, choose M here. > + > + Not many firmware implementations fully support EFI capsules. > + If you plan to rely on this you should test whether yours works by > + forcing a crash. Most people should not enable this. > + > +config EFI_CAPSULE_PSTORE_DEFAULT_DISABLE > + bool "Disable using efi capsule as a pstore backend by default" > + depends on EFI_CAPSULE_PSTORE > + help > + Saying Y here will disable the use of efi capsule as a storage > + backend for pstore by default. This setting can be overridden > + using the capsule-pstore module's pstore_disable parameter. > + > endmenu > > config UEFI_CPER > diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile > index 0329d31..c06e52f 100644 > --- a/drivers/firmware/efi/Makefile > +++ b/drivers/firmware/efi/Makefile > @@ -15,6 +15,7 @@ obj-$(CONFIG_EFI) += capsule.o memmap.o > obj-$(CONFIG_EFI_VARS) += efivars.o > obj-$(CONFIG_EFI_ESRT) += esrt.o > obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o > +obj-$(CONFIG_EFI_CAPSULE_PSTORE) += capsule-pstore.o > obj-$(CONFIG_UEFI_CPER)+= cper.o > obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o > obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o > diff --git a/drivers/firmware/efi/capsule-pstore.c > b/drivers/firmware/efi/capsule-pstore.c > new file mode 100644 > index 000..c28ad0a > --- /dev/null > +++ b/drivers/firmware/efi/capsule-pstore.c > @@ -0,0 +1,671 @@ > +/* > + * EFI capsule pstore backend support. > + * Copyright (c) 2017, Intel Corporation. > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms and conditions of the GNU General Public License, > + * version 2, as published by the Free Software Foundation. > + * > + * This program is distributed in the hope it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for > + * more details. > + */ > + > +#define pr_fmt
Re: [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active
On Fri, 16 Jun 2017, Tom Lendacky wrote: > Currently there is a check if the address being mapped is in the ISA > range (is_ISA_range()), and if it is then phys_to_virt() is used to > perform the mapping. When SME is active, however, this will result > in the mapping having the encryption bit set when it is expected that > an ioremap() should not have the encryption bit set. So only use the > phys_to_virt() function if SME is not active This does not make sense to me. What the heck has phys_to_virt() to do with the encryption bit. Especially why would the encryption bit be set on that mapping in the first place? I'm probably missing something, but this want's some coherent explanation understandable by mere mortals both in the changelog and the code comment. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 06/36] x86/mm: Add Secure Memory Encryption (SME) support
On Fri, 16 Jun 2017, Tom Lendacky wrote: > > +config ARCH_HAS_MEM_ENCRYPT > + def_bool y > + depends on X86 That one is silly. The config switch is in the x86 KConfig file, so X86 is on. If you intended to move this to some generic place outside of x86/Kconfig then this should be config ARCH_HAS_MEM_ENCRYPT bool and x86/Kconfig should have select ARCH_HAS_MEM_ENCRYPT and that should be selected by AMD_MEM_ENCRYPT > +config AMD_MEM_ENCRYPT > + bool "AMD Secure Memory Encryption (SME) support" > + depends on X86_64 && CPU_SUP_AMD > + ---help--- > + Say yes to enable support for the encryption of system memory. > + This requires an AMD processor that supports Secure Memory > + Encryption (SME). Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 19/36] x86/mm: Add support to access boot related data in the clear
On Fri, Jun 16, 2017 at 01:53:26PM -0500, Tom Lendacky wrote: > Boot data (such as EFI related data) is not encrypted when the system is > booted because UEFI/BIOS does not run with SME active. In order to access > this data properly it needs to be mapped decrypted. > > Update early_memremap() to provide an arch specific routine to modify the > pagetable protection attributes before they are applied to the new > mapping. This is used to remove the encryption mask for boot related data. > > Update memremap() to provide an arch specific routine to determine if RAM > remapping is allowed. RAM remapping will cause an encrypted mapping to be > generated. By preventing RAM remapping, ioremap_cache() will be used > instead, which will provide a decrypted mapping of the boot related data. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/io.h |5 + > arch/x86/mm/ioremap.c | 179 > + > include/linux/io.h|2 + > kernel/memremap.c | 20 - > mm/early_ioremap.c| 18 - > 5 files changed, 217 insertions(+), 7 deletions(-) Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] x86/xen/efi: Init only efi struct members used by Xen
Current approach, wholesale efi struct initialization from efi_xen, is not
good. Usually if new member is defined then it is properly initialized in
drivers/firmware/efi/efi.c but not in arch/x86/xen/efi.c. As I saw it happened
a few times until now. So, let's initialize only efi struct members used by
Xen to avoid such issues in the future.
Signed-off-by: Daniel Kiper
---
arch/x86/xen/efi.c | 45 -
1 file changed, 12 insertions(+), 33 deletions(-)
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index 30bb2e8..01b9faf 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -54,38 +54,6 @@
.tables = EFI_INVALID_TABLE_ADDR /* Initialized later. */
};
-static const struct efi efi_xen __initconst = {
- .systab = NULL, /* Initialized later. */
- .runtime_version = 0,/* Initialized later. */
- .mps = EFI_INVALID_TABLE_ADDR,
- .acpi = EFI_INVALID_TABLE_ADDR,
- .acpi20 = EFI_INVALID_TABLE_ADDR,
- .smbios = EFI_INVALID_TABLE_ADDR,
- .smbios3 = EFI_INVALID_TABLE_ADDR,
- .sal_systab = EFI_INVALID_TABLE_ADDR,
- .boot_info= EFI_INVALID_TABLE_ADDR,
- .hcdp = EFI_INVALID_TABLE_ADDR,
- .uga = EFI_INVALID_TABLE_ADDR,
- .uv_systab= EFI_INVALID_TABLE_ADDR,
- .fw_vendor= EFI_INVALID_TABLE_ADDR,
- .runtime = EFI_INVALID_TABLE_ADDR,
- .config_table = EFI_INVALID_TABLE_ADDR,
- .get_time = xen_efi_get_time,
- .set_time = xen_efi_set_time,
- .get_wakeup_time = xen_efi_get_wakeup_time,
- .set_wakeup_time = xen_efi_set_wakeup_time,
- .get_variable = xen_efi_get_variable,
- .get_next_variable= xen_efi_get_next_variable,
- .set_variable = xen_efi_set_variable,
- .query_variable_info = xen_efi_query_variable_info,
- .update_capsule = xen_efi_update_capsule,
- .query_capsule_caps = xen_efi_query_capsule_caps,
- .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
- .reset_system = xen_efi_reset_system,
- .set_virtual_address_map = NULL, /* Not used under Xen. */
- .flags= 0 /* Initialized later. */
-};
-
static efi_system_table_t __init *xen_efi_probe(void)
{
struct xen_platform_op op = {
@@ -102,7 +70,18 @@ static efi_system_table_t __init *xen_efi_probe(void)
/* Here we know that Xen runs on EFI platform. */
- efi = efi_xen;
+ efi.get_time = xen_efi_get_time;
+ efi.set_time = xen_efi_set_time;
+ efi.get_wakeup_time = xen_efi_get_wakeup_time;
+ efi.set_wakeup_time = xen_efi_set_wakeup_time;
+ efi.get_variable = xen_efi_get_variable;
+ efi.get_next_variable = xen_efi_get_next_variable;
+ efi.set_variable = xen_efi_set_variable;
+ efi.query_variable_info = xen_efi_query_variable_info;
+ efi.update_capsule = xen_efi_update_capsule;
+ efi.query_capsule_caps = xen_efi_query_capsule_caps;
+ efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
+ efi.reset_system = xen_efi_reset_system;
efi_systab_xen.tables = info->cfg.addr;
efi_systab_xen.nr_tables = info->cfg.nent;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] efi: Process MEMATTR table only if EFI_MEMMAP
Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes.
In theory we can check EFI_PARAVIRT too, however,
EFI_MEMMAP looks more generic and covers more cases.
Signed-off-by: Daniel Kiper
---
drivers/firmware/efi/efi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index b372aad..045d6d3 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -528,7 +528,8 @@ int __init efi_config_parse_tables(void *config_tables, int
count, int sz,
}
}
- efi_memattr_init();
+ if (efi_enabled(EFI_MEMMAP))
+ efi_memattr_init();
/* Parse the EFI Properties table if it exists */
if (efi.properties_table != EFI_INVALID_TABLE_ADDR) {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] xen/efi: Fixes
Hey, Two small fixes for Xen dom0 running on x86_64 EFI platforms. I am CC-ing stable maintainers because similar stuff is needed for various stable kernels too. Unfortunately, almost every version needs a bit different set of fixes. So, please treat this email more as head up than real set of patches for your kernel. If you wish to get Xen EFI stuff fixed just drop me a line. Then I will prepare set of patches for your kernel (if needed). Daniel arch/x86/xen/efi.c | 45 - drivers/firmware/efi/efi.c |3 ++- 2 files changed, 14 insertions(+), 34 deletions(-) Daniel Kiper (2): efi: Process MEMATTR table only if EFI_MEMMAP x86/xen/efi: Init only efi struct members used by Xen -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()
On 6/20/2017 11:17 AM, Andy Lutomirski wrote: On Fri, Jun 16, 2017 at 11:51 AM, Tom Lendacky wrote: The cr3 register entry can contain the SME encryption mask that indicates the PGD is encrypted. The encryption mask should not be used when creating a virtual address from the cr3 register, so remove the SME encryption mask in the read_cr3_pa() function. During early boot SME will need to use a native version of read_cr3_pa(), so create native_read_cr3_pa(). Signed-off-by: Tom Lendacky --- arch/x86/include/asm/processor-flags.h |3 ++- arch/x86/include/asm/processor.h |5 + 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/processor-flags.h b/arch/x86/include/asm/processor-flags.h index 79aa2f9..cb6999c 100644 --- a/arch/x86/include/asm/processor-flags.h +++ b/arch/x86/include/asm/processor-flags.h @@ -2,6 +2,7 @@ #define _ASM_X86_PROCESSOR_FLAGS_H #include +#include #ifdef CONFIG_VM86 #define X86_VM_MASKX86_EFLAGS_VM @@ -33,7 +34,7 @@ */ #ifdef CONFIG_X86_64 /* Mask off the address space ID bits. */ -#define CR3_ADDR_MASK 0x7000ull +#define CR3_ADDR_MASK __sme_clr(0x7000ull) Can you update the comment one line above, too? Yup, will do. Thanks, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()
On Fri, Jun 16, 2017 at 11:51 AM, Tom Lendacky wrote: > The cr3 register entry can contain the SME encryption mask that indicates > the PGD is encrypted. The encryption mask should not be used when > creating a virtual address from the cr3 register, so remove the SME > encryption mask in the read_cr3_pa() function. > > During early boot SME will need to use a native version of read_cr3_pa(), > so create native_read_cr3_pa(). > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/processor-flags.h |3 ++- > arch/x86/include/asm/processor.h |5 + > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/processor-flags.h > b/arch/x86/include/asm/processor-flags.h > index 79aa2f9..cb6999c 100644 > --- a/arch/x86/include/asm/processor-flags.h > +++ b/arch/x86/include/asm/processor-flags.h > @@ -2,6 +2,7 @@ > #define _ASM_X86_PROCESSOR_FLAGS_H > > #include > +#include > > #ifdef CONFIG_VM86 > #define X86_VM_MASKX86_EFLAGS_VM > @@ -33,7 +34,7 @@ > */ > #ifdef CONFIG_X86_64 > /* Mask off the address space ID bits. */ > -#define CR3_ADDR_MASK 0x7000ull > +#define CR3_ADDR_MASK __sme_clr(0x7000ull) Can you update the comment one line above, too? -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with new X.509 is_hash_blacklisted() interface
James Bottomley wrote:
> Added by
>
> commit 436529562df2748fd9918f578205b22cf8ced277
> Author: David Howells
> Date: Mon Apr 3 16:07:25 2017 +0100
>
> X.509: Allow X.509 certs to be blacklisted
>
> Ironically it duplicates a UEFI bug we've been struggling with for a
> while in the pkcs11 handlers: namely if you have a blacklist based on
> certificate hashes, an interface which only takes a hash cannot
> definitively tell you if the certificate is on the blacklist or not
> because the hash the cert is blacklisted by may be a different
> algorithm from the hash you feed in to is_hash_blacklisted(). This
> means that the only safe way to use the interface is to construct every
> possible hash of the cert and feed them one at a time into
> is_hash_blacklisted(). This makes it an almost unusable API.
>
> I suggest you deprecate this interface immediately and introduce an
> is_cert_blacklisted() one which takes a pointer to the TBS data. Then
> the implementation can loop over the blacklists, see the hash type and
> construct the hash of the TBS data for comparison (caching the hashes
> for efficiency). That way you'll be assured of a definitive answer and
> an easy API.
>
> It might be reasonable to cc linux-efi on future kernel keyring stuff,
> because some of the other issues may have also come up in the UEFI
> keyrings.
You should also cc keyrings and possibly l-s-m.
How about the attached patch?
David
---
KEYS: Make the blacklisting check all possible types of hash
The blacklisting facility is not limited to hashes of a specific type, so
certificate and message blocks that need to be checked may have to be
checked against hashes of more than one hash type.
Make the blacklisting facility check all the types of hash it has blacklist
entries for.
To this end:
(1) Blacklist type key names now can take an optional type name at the
end:
":[:]"
If the algorithm is omitted, it's assumed to refer to a shaNNN
algorithm, where NNN is defined by the number of bits in the hex hash.
(2) mark_hash_blacklisted() maintains a list of types we've marked. Only
this function can modify the blacklist keyring, so this is an good
place to do it.
Adding to the list in the blacklist key type ops would allow userspace
to add an unlimited number of type names to the list.
(3) is_hash_blacklisted() is given an extra parameter for the hash
algorithm name. It will now check for a matching description with the
algorithm name attached and then, if the algorithm name begins "sha",
it will chop off the algorithm name and try that too.
(4) is_data_blacklisted() is added to iterate through all the known
blacklist hashes, for which it will hash the data it is given and
invoke is_hash_blacklisted() on the digest it obtained.
This can be told to skip a particular algorithm for when the caller
has one precalculated. The precalculated hash can be passed to
is_hash_blacklisted(). This would typically be the case for a signed
X.509 message.
Fixes: 734114f8782f ("KEYS: Add a system blacklist keyring")
Suggested-by: James Bottomley
Signed-off-by: David Howells
cc: sta...@vger.kernel.org
---
certs/blacklist.c| 263 +--
crypto/asymmetric_keys/x509_public_key.c | 24 ++
include/keys/system_keyring.h| 11 +
3 files changed, 279 insertions(+), 19 deletions(-)
diff --git a/certs/blacklist.c b/certs/blacklist.c
index 3a507b9e2568..3be5ae5e5606 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -18,14 +18,42 @@
#include
#include
#include
+#include
#include
#include "blacklist.h"
+struct blacklist_hash {
+ struct blacklist_hash *next;
+ u8 name_len;
+ char name[];
+};
+
static struct key *blacklist_keyring;
+static struct blacklist_hash blacklist_sha256 = { NULL, 6, "sha256" };
+static struct blacklist_hash *blacklist_hash_types = &blacklist_sha256;
+static DEFINE_SPINLOCK(blacklist_hash_types_lock);
+
+static const struct blacklist_hash *blacklist_hash_type(const char *hash_algo,
+ size_t name_len)
+{
+ const struct blacklist_hash *bhash;
+
+ bhash = blacklist_hash_types;
+ smp_rmb(); /* Content after pointer. List tail is immutable */
+ for (; bhash; bhash = bhash->next)
+ if (name_len == bhash->name_len &&
+ memcmp(hash_algo, bhash->name, name_len) == 0)
+ return bhash;
+ return NULL;
+}
/*
* The description must be a type prefix, a colon and then an even number of
- * hex digits. The hash is kept in the description.
+ * hex digits then optionally another colon and the hash type. If the hash
+ * type isn't specified, it's assumed to be SHAnnn where nnn is the number of
+ * bits in the hash.
+ *
+ * The hash data is kept in the description.
*/
static int blacklist_vet_descri
Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing
On 6/20/2017 2:38 AM, Borislav Petkov wrote:
On Fri, Jun 16, 2017 at 01:51:15PM -0500, Tom Lendacky wrote:
Add support to the early boot code to use Secure Memory Encryption (SME).
Since the kernel has been loaded into memory in a decrypted state, encrypt
the kernel in place and update the early pagetables with the memory
encryption mask so that new pagetable entries will use memory encryption.
The routines to set the encryption mask and perform the encryption are
stub routines for now with functionality to be added in a later patch.
Because of the need to have the routines available to head_64.S, the
mem_encrypt.c is always built and #ifdefs in mem_encrypt.c will provide
functionality or stub routines depending on CONFIG_AMD_MEM_ENCRYPT.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/mem_encrypt.h |8 +++
arch/x86/kernel/head64.c | 33 +-
arch/x86/kernel/head_64.S | 39 ++--
arch/x86/mm/Makefile |4 +---
arch/x86/mm/mem_encrypt.c | 24 ++
5 files changed, 93 insertions(+), 15 deletions(-)
...
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index b99d469..9a78277 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -11,6 +11,9 @@
*/
#include
+#include
+
+#ifdef CONFIG_AMD_MEM_ENCRYPT
/*
* Since SME related variables are set early in the boot process they must
@@ -19,3 +22,24 @@
*/
unsigned long sme_me_mask __section(.data) = 0;
EXPORT_SYMBOL_GPL(sme_me_mask);
+
+void __init sme_encrypt_kernel(void)
+{
+}
Just the minor:
void __init sme_encrypt_kernel(void) { }
in case you have to respin.
I have to re-spin for the kbuild test error. But given that this
function will be filled in later it's probably not worth doing the
space savings here.
Thanks,
Tom
Reviewed-by: Borislav Petkov
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 14/36] x86/mm: Insure that boot memory areas are mapped properly
On Fri, Jun 16, 2017 at 01:52:32PM -0500, Tom Lendacky wrote:
> The boot data and command line data are present in memory in a decrypted
> state and are copied early in the boot process. The early page fault
> support will map these areas as encrypted, so before attempting to copy
> them, add decrypted mappings so the data is accessed properly when copied.
>
> For the initrd, encrypt this data in place. Since the future mapping of
> the initrd area will be mapped as encrypted the data will be accessed
> properly.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/mem_encrypt.h |6 +++
> arch/x86/include/asm/pgtable.h |3 ++
> arch/x86/kernel/head64.c | 30 +--
> arch/x86/kernel/setup.c|9 +
> arch/x86/mm/kasan_init_64.c|2 +
> arch/x86/mm/mem_encrypt.c | 70
>
> 6 files changed, 115 insertions(+), 5 deletions(-)
...
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index b7671b9..ea5e3a6 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -19,6 +19,8 @@
>
> #include
> #include
> +#include
> +#include
>
> /*
> * Since SME related variables are set early in the boot process they must
> @@ -101,6 +103,74 @@ void __init sme_early_decrypt(resource_size_t paddr,
> unsigned long size)
> __sme_early_enc_dec(paddr, size, false);
> }
>
> +static void __init __sme_early_map_unmap_mem(void *vaddr, unsigned long size,
> + bool map)
> +{
> + unsigned long paddr = (unsigned long)vaddr - __PAGE_OFFSET;
> + pmdval_t pmd_flags, pmd;
> +
> + /* Use early_pmd_flags but remove the encryption mask */
> + pmd_flags = __sme_clr(early_pmd_flags);
> +
> + do {
> + pmd = map ? (paddr & PMD_MASK) + pmd_flags : 0;
> + __early_make_pgtable((unsigned long)vaddr, pmd);
> +
> + vaddr += PMD_SIZE;
> + paddr += PMD_SIZE;
> + size = (size <= PMD_SIZE) ? 0 : size - PMD_SIZE;
> + } while (size);
> +
> + write_cr3(__read_cr3());
local_flush_tlb() or __native_flush_tlb(). Probably the native variant
since this is early fun.
> +}
> +
> +static void __init __sme_map_unmap_bootdata(char *real_mode_data, bool map)
> +{
> + struct boot_params *boot_data;
> + unsigned long cmdline_paddr;
> +
> + /* If SME is not active, the bootdata is in the correct state */
> + if (!sme_active())
> + return;
> +
> + if (!map) {
> + /*
> + * If unmapping, get the command line address before
> + * unmapping the real_mode_data.
> + */
> + boot_data = (struct boot_params *)real_mode_data;
> + cmdline_paddr = boot_data->hdr.cmd_line_ptr |
> + ((u64)boot_data->ext_cmd_line_ptr << 32);
Let it stick out:
cmdline_paddr = bd->hdr.cmd_line_ptr | ((u64)bd->ext_cmd_line_ptr <<
32);
> + }
> +
> + __sme_early_map_unmap_mem(real_mode_data, sizeof(boot_params), map);
> +
> + if (map) {
> + /*
> + * If mapping, get the command line address after mapping
> + * the real_mode_data.
> + */
> + boot_data = (struct boot_params *)real_mode_data;
> + cmdline_paddr = boot_data->hdr.cmd_line_ptr |
> + ((u64)boot_data->ext_cmd_line_ptr << 32);
> + }
> +
> + if (!cmdline_paddr)
> + return;
> +
> + __sme_early_map_unmap_mem(__va(cmdline_paddr), COMMAND_LINE_SIZE, map);
Ok, so from looking at this function now - it does different things
depending on whether we map or not. So it doesn't look like a worker
function anymore and you can move the stuff back to the original callers
below. Should make the whole flow more readable.
> +}
> +
> +void __init sme_unmap_bootdata(char *real_mode_data)
> +{
> + __sme_map_unmap_bootdata(real_mode_data, false);
> +}
> +
> +void __init sme_map_bootdata(char *real_mode_data)
> +{
> + __sme_map_unmap_bootdata(real_mode_data, true);
> +}
> +
> void __init sme_early_init(void)
> {
> unsigned int i;
>
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V17 00/11] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64
Hi Robert, On Tue, Jun 20, 2017 at 08:34:39AM +0200, Robert Richter wrote: > On 07.06.17 12:50:12, Will Deacon wrote: > > > Thanks, I've pushed this out as: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git > > for-next/ras-apei > > > > which I'll merge into for-next/core (and therefore linux-next) either the > > end of this week or the beginning of next week. Please take a look if you > > get a chance. > > any reason why there was a roll back of for-next/core? > > + 0870f692c2ed...e27c7fa015d6 for-next/core -> arm64/for-next/core (forced > update) > > Is it because for-next/ras-apei goes through tip? No, it's because the RAS stuff ran into horrible conflicts with the UUID tree: https://lkml.org/lkml/2017/6/16/22 Tyler should be rebasing that soon, so hopefully I can requeue that stuff this week. Will -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] eif/capsule-pstore: Add capsule pstore backend
The EFI capsule mechanism allows data blobs to be passed to the EFI firmware. By setting the EFI_CAPSULE_POPULATE_SYSTEM_TABLE and the EFI_CAPSULE_PERSIST_ACROSS_REBOOT flags, the firmware will place a pointer to our data blob in the EFI System Table on the next boot. We can utilise this facility to save crash dumps, call traces, etc and pick them up to aid in debugging after reboot. Initial cut at this driver by Matt Fleming as below links https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=capsule-pstore&id=99c5f047133555aa0442f64064e85b7da2d4a45f https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=capsule-pstore&id=8625c776c9b8bbed7fa4aa023e36542615165240 Extensive cleanup, refactoring, bug fix, and verification by Qiuxu Zhuo Patch verified on Intel Kabylake client platform + Intel KBL BIOS:(10/24/2016): - modprobe capsule-pstore - echo "Test pmsg on capsule-pstore" > /dev/pmsg0 - echo 1 > /sys/module/kernel/parameters/panic - echo c > /proc/sysrq-trigger - system reboot... - ls -l /sys/fs/pstore/ -r--r--r-- 1 root root 4946 6月 19 14:05 console-capsule-pstore-0 -r--r--r-- 1 root root 8976 6月 19 14:03 dmesg-capsule-pstore-6433226157407076353 -r--r--r-- 1 root root 9043 6月 19 14:03 dmesg-capsule-pstore-6433226157407076354 -r--r--r-- 1 root root 9069 6月 19 14:03 dmesg-capsule-pstore-6433226157407076355 -r--r--r-- 1 root root 9092 6月 19 14:03 dmesg-capsule-pstore-6433226157407076356 -r--r--r-- 1 root root 8976 6月 19 14:03 dmesg-capsule-pstore-6433226157407076357 -r--r--r-- 1 root root 9028 6月 19 14:03 dmesg-capsule-pstore-6433226157407076358 -r--r--r-- 1 root root 28 6月 19 14:05 pmsg-capsule-pstore-0 The above files contain pmsg log and the last console/dmesg logs. Signed-off-by: Qiuxu Zhuo --- drivers/firmware/efi/Kconfig | 21 ++ drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/capsule-pstore.c | 671 ++ 3 files changed, 693 insertions(+) create mode 100644 drivers/firmware/efi/capsule-pstore.c diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig index 2e78b0b..aab78a7 100644 --- a/drivers/firmware/efi/Kconfig +++ b/drivers/firmware/efi/Kconfig @@ -142,6 +142,27 @@ config APPLE_PROPERTIES If unsure, say Y if you have a Mac. Otherwise N. +config EFI_CAPSULE_PSTORE + tristate "EFI capsule pstore backend" + depends on EFI && PSTORE + help + Saying Y here enable the EFI capsule mechanism to store crash dumps, + console log, and function tracing data. + + To compile this driver as a module, choose M here. + + Not many firmware implementations fully support EFI capsules. + If you plan to rely on this you should test whether yours works by + forcing a crash. Most people should not enable this. + +config EFI_CAPSULE_PSTORE_DEFAULT_DISABLE + bool "Disable using efi capsule as a pstore backend by default" + depends on EFI_CAPSULE_PSTORE + help + Saying Y here will disable the use of efi capsule as a storage + backend for pstore by default. This setting can be overridden + using the capsule-pstore module's pstore_disable parameter. + endmenu config UEFI_CPER diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile index 0329d31..c06e52f 100644 --- a/drivers/firmware/efi/Makefile +++ b/drivers/firmware/efi/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_EFI) += capsule.o memmap.o obj-$(CONFIG_EFI_VARS) += efivars.o obj-$(CONFIG_EFI_ESRT) += esrt.o obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o +obj-$(CONFIG_EFI_CAPSULE_PSTORE) += capsule-pstore.o obj-$(CONFIG_UEFI_CPER)+= cper.o obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o diff --git a/drivers/firmware/efi/capsule-pstore.c b/drivers/firmware/efi/capsule-pstore.c new file mode 100644 index 000..c28ad0a --- /dev/null +++ b/drivers/firmware/efi/capsule-pstore.c @@ -0,0 +1,671 @@ +/* + * EFI capsule pstore backend support. + * Copyright (c) 2017, Intel Corporation. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + */ + +#define pr_fmt(fmt) "capsule-pstore: " fmt +#include +#include +#include +#include +#include + +#define CAPSULE_SIZE (16 * 1024) +#define CRASH_SIZE 4096 +#define CAPSULE_MAGIC 0x63617073 /* 'caps' */ + +static bool efi_capsule_pstore_disable = + IS_ENABLED(CONFIG_CAPSUL
[PATCH v3 0/2] Add EFI capsule pstore backend support
Change Log v2->v3: - Get rid of 'capsule' in efi structure, and add 'nr_config_table' in efi structure for iterating over configuration table array. - Move efi_capsule_lookup() from capsule.c to capsule-pstore.c, and extract capsule with any GUID by iterating over the configuration table array. - Add PMSG support. - Reduce debug/info message. - Include a file header comment for new file capsuel-pstore.c. - Some bug fix and code cleanup. Qiuxu Zhuo (2): efi: Add 'nr_config_table' variable in efi structure eif/capsule-pstore: Add capsule pstore backend arch/x86/platform/efi/efi.c | 1 + drivers/firmware/efi/Kconfig | 21 ++ drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/capsule-pstore.c | 667 ++ drivers/firmware/efi/efi.c| 1 + include/linux/efi.h | 1 + 6 files changed, 692 insertions(+) create mode 100644 drivers/firmware/efi/capsule-pstore.c -- 2.9.0.GIT -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] efi: Add 'nr_config_table' variable in efi structure
The 'nr_config_table' and 'config_table' (alreay in efi structure)
in efi structure provide a way for some driver(e.g. capsule-pstore
goes through the configuration table to extract crash capsules to
aid in debugging) iterates over the EFI configuration table array.
Signed-off-by: Qiuxu Zhuo
---
arch/x86/platform/efi/efi.c | 1 +
drivers/firmware/efi/efi.c | 1 +
include/linux/efi.h | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 7e76a4d..bcda1b9 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -498,6 +498,7 @@ void __init efi_init(void)
return;
efi.config_table = (unsigned long)efi.systab->tables;
+ efi.nr_config_table = (unsigned long)efi.systab->nr_tables;
efi.fw_vendor= (unsigned long)efi.systab->fw_vendor;
efi.runtime = (unsigned long)efi.systab->runtime;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index b372aad..b511197 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -48,6 +48,7 @@ struct efi __read_mostly efi = {
.fw_vendor = EFI_INVALID_TABLE_ADDR,
.runtime= EFI_INVALID_TABLE_ADDR,
.config_table = EFI_INVALID_TABLE_ADDR,
+ .nr_config_table= EFI_INVALID_TABLE_ADDR,
.esrt = EFI_INVALID_TABLE_ADDR,
.properties_table = EFI_INVALID_TABLE_ADDR,
.mem_attr_table = EFI_INVALID_TABLE_ADDR,
diff --git a/include/linux/efi.h b/include/linux/efi.h
index ec36f42..bd5ff8f 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -892,6 +892,7 @@ extern struct efi {
unsigned long fw_vendor;/* fw_vendor */
unsigned long runtime; /* runtime table */
unsigned long config_table; /* config tables */
+ unsigned long nr_config_table;
unsigned long esrt; /* ESRT table */
unsigned long properties_table; /* properties table */
unsigned long mem_attr_table; /* memory attributes table */
--
2.9.0.GIT
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()
On Fri, Jun 16, 2017 at 01:51:55PM -0500, Tom Lendacky wrote: > The cr3 register entry can contain the SME encryption mask that indicates > the PGD is encrypted. The encryption mask should not be used when > creating a virtual address from the cr3 register, so remove the SME > encryption mask in the read_cr3_pa() function. > > During early boot SME will need to use a native version of read_cr3_pa(), > so create native_read_cr3_pa(). > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/processor-flags.h |3 ++- > arch/x86/include/asm/processor.h |5 + > 2 files changed, 7 insertions(+), 1 deletion(-) Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing
On Fri, Jun 16, 2017 at 01:51:15PM -0500, Tom Lendacky wrote:
> Add support to the early boot code to use Secure Memory Encryption (SME).
> Since the kernel has been loaded into memory in a decrypted state, encrypt
> the kernel in place and update the early pagetables with the memory
> encryption mask so that new pagetable entries will use memory encryption.
>
> The routines to set the encryption mask and perform the encryption are
> stub routines for now with functionality to be added in a later patch.
>
> Because of the need to have the routines available to head_64.S, the
> mem_encrypt.c is always built and #ifdefs in mem_encrypt.c will provide
> functionality or stub routines depending on CONFIG_AMD_MEM_ENCRYPT.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/mem_encrypt.h |8 +++
> arch/x86/kernel/head64.c | 33 +-
> arch/x86/kernel/head_64.S | 39
> ++--
> arch/x86/mm/Makefile |4 +---
> arch/x86/mm/mem_encrypt.c | 24 ++
> 5 files changed, 93 insertions(+), 15 deletions(-)
...
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index b99d469..9a78277 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -11,6 +11,9 @@
> */
>
> #include
> +#include
> +
> +#ifdef CONFIG_AMD_MEM_ENCRYPT
>
> /*
> * Since SME related variables are set early in the boot process they must
> @@ -19,3 +22,24 @@
> */
> unsigned long sme_me_mask __section(.data) = 0;
> EXPORT_SYMBOL_GPL(sme_me_mask);
> +
> +void __init sme_encrypt_kernel(void)
> +{
> +}
Just the minor:
void __init sme_encrypt_kernel(void) { }
in case you have to respin.
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 03/36] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings
On Fri, Jun 16, 2017 at 01:50:23PM -0500, Tom Lendacky wrote: > The ioremap() function is intended for mapping MMIO. For RAM, the > memremap() function should be used. Convert calls from ioremap() to > memremap() when re-mapping RAM. > > This will be used later by SME to control how the encryption mask is > applied to memory mappings, with certain memory locations being mapped > decrypted vs encrypted. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/dmi.h |8 > arch/x86/kernel/acpi/boot.c |6 +++--- > arch/x86/kernel/kdebugfs.c | 34 +++--- > arch/x86/kernel/ksysfs.c | 28 ++-- > arch/x86/kernel/mpparse.c| 10 +- > arch/x86/pci/common.c|4 ++-- > drivers/firmware/dmi-sysfs.c |5 +++-- > drivers/firmware/pcdp.c |4 ++-- > drivers/sfi/sfi_core.c | 22 +++--- > 9 files changed, 55 insertions(+), 66 deletions(-) Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 18/31] efi-stub.txt: standardize document format
On 17 June 2017 at 17:25, Mauro Carvalho Chehab wrote: > Each text file under Documentation follows a different > format. Some doesn't even have titles! > > Change its representation to follow the adopted standard, > using ReST markups for it to be parseable by Sphinx: > > - use proper markups for titles; > - identify literal blocks. > > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Ard Biesheuvel > --- > Documentation/efi-stub.txt | 25 +++-- > 1 file changed, 15 insertions(+), 10 deletions(-) > > diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt > index e15746988261..41df801f9a50 100644 > --- a/Documentation/efi-stub.txt > +++ b/Documentation/efi-stub.txt > @@ -1,5 +1,6 @@ > - The EFI Boot Stub > ---- > += > +The EFI Boot Stub > += > > On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade > as a PE/COFF image, thereby convincing EFI firmware loaders to load > @@ -25,7 +26,8 @@ a certain sense it *IS* the boot loader. > The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option. > > > - How to install bzImage.efi > +How to install bzImage.efi > +-- > > The bzImage located in arch/x86/boot/bzImage must be copied to the EFI > System Partition (ESP) and renamed with the extension ".efi". Without > @@ -37,14 +39,16 @@ may not need to be renamed. Similarly for arm64, > arch/arm64/boot/Image > should be copied but not necessarily renamed. > > > - Passing kernel parameters from the EFI shell > +Passing kernel parameters from the EFI shell > + > > -Arguments to the kernel can be passed after bzImage.efi, e.g. > +Arguments to the kernel can be passed after bzImage.efi, e.g.:: > > fs0:> bzImage.efi console=ttyS0 root=/dev/sda4 > > > - The "initrd=" option > +The "initrd=" option > + > > Like most boot loaders, the EFI stub allows the user to specify > multiple initrd files using the "initrd=" option. This is the only EFI > @@ -54,9 +58,9 @@ kernel when it boots. > The path to the initrd file must be an absolute path from the > beginning of the ESP, relative path names do not work. Also, the path > is an EFI-style path and directory elements must be separated with > -backslashes (\). For example, given the following directory layout, > +backslashes (\). For example, given the following directory layout:: > > -fs0:> > + fs0:> > Kernels\ > bzImage.efi > initrd-large.img > @@ -66,7 +70,7 @@ fs0:> > initrd-medium.img > > to boot with the initrd-large.img file if the current working > -directory is fs0:\Kernels, the following command must be used, > +directory is fs0:\Kernels, the following command must be used:: > > fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img > > @@ -76,7 +80,8 @@ which understands relative paths, whereas the rest of the > command line > is passed to bzImage.efi. > > > - The "dtb=" option > +The "dtb=" option > +- > > For the ARM and arm64 architectures, we also need to be able to provide a > device tree to the kernel. This is done with the "dtb=" command line option, > -- > 2.9.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
