date:20180109

[PATCH 2/4] x86/xen/efi: Initialize boot_params.secure_boot in xen_efi_init()

2018-01-09 Thread Daniel Kiper

Otherwise the kernel reports incorrect UEFI secure boot state in the Xen dom0.

By the way fix CFLAGS_mmu_pv.o assignment alignment.

Signed-off-by: Daniel Kiper 
---
 arch/x86/xen/Makefile |4 +++-
 arch/x86/xen/efi.c|   11 +++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index d83cb54..1b07664 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -12,7 +12,9 @@ endif
 # Make sure early boot has no stackprotector
 nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_enlighten_pv.o  := $(nostackp)
-CFLAGS_mmu_pv.o:= $(nostackp)
+CFLAGS_mmu_pv.o:= $(nostackp)
+
+CFLAGS_efi.o   += -I$(srctree)/drivers/firmware
 
 obj-y  := enlighten.o multicalls.o mmu.o irq.o \
time.o xen-asm.o xen-asm_$(BITS).o \
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index a18703b..e089fa7 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -28,6 +28,15 @@
 #include 
 #include 
 
+#define pr_efi(sys_table, msg)
+#define pr_efi_err(sys_table, msg)
+
+#define get_efi_var(name, vendor, attr, data_size, data) \
+   xen_efi_get_variable((efi_char16_t *)name, (efi_guid_t 
*)vendor, \
+attr, data_size, data)
+
+#include 
+
 static efi_char16_t vendor[100] __initdata;
 
 static efi_system_table_t efi_systab_xen __initdata = {
@@ -129,6 +138,8 @@ void __init xen_efi_init(void)
boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 
32);
 
+   boot_params.secure_boot = efi_get_secureboot(efi_systab_xen);
+
set_bit(EFI_BOOT, );
set_bit(EFI_PARAVIRT, );
set_bit(EFI_64BIT, );
-- 
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/4] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

2018-01-09 Thread Daniel Kiper

Hi,

Initialize UEFI secure boot state during dom0 boot. Otherwise the kernel
may not even know that it runs on secure boot enabled platform.

Daniel

 arch/x86/xen/Makefile  |4 +++-
 arch/x86/xen/efi.c |   14 +
 drivers/firmware/efi/libstub/secureboot-core.c |   77 
+
 drivers/firmware/efi/libstub/secureboot.c  |   66 
+--
 4 files changed, 99 insertions(+), 62 deletions(-)

Daniel Kiper (4):
  efi/stub: Extract efi_get_secureboot() to separate file
  x86/xen/efi: Initialize boot_params.secure_boot in xen_efi_init()
  efi: Tweak efi_get_secureboot() and its data section assignment
  efi: Rename efi_get_secureboot() to __efi_get_secureboot() and make it 
static

--
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 4/4] efi: Rename efi_get_secureboot() to __efi_get_secureboot() and make it static

2018-01-09 Thread Daniel Kiper

This may help compiler to do some function call optimization.

This is rather cosmetic. If you like this patch apply.
If you do not you may ignore it.

Signed-off-by: Daniel Kiper 
---
 arch/x86/xen/efi.c |2 +-
 drivers/firmware/efi/libstub/secureboot-core.c |2 +-
 drivers/firmware/efi/libstub/secureboot.c  |5 +
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index 5ad2b8f..d45677f 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -141,7 +141,7 @@ void __init xen_efi_init(void)
boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 
32);
 
-   boot_params.secure_boot = efi_get_secureboot(efi_systab_xen);
+   boot_params.secure_boot = __efi_get_secureboot(efi_systab_xen);
 
set_bit(EFI_BOOT, );
set_bit(EFI_PARAVIRT, );
diff --git a/drivers/firmware/efi/libstub/secureboot-core.c 
b/drivers/firmware/efi/libstub/secureboot-core.c
index d503ee4..07526a6 100644
--- a/drivers/firmware/efi/libstub/secureboot-core.c
+++ b/drivers/firmware/efi/libstub/secureboot-core.c
@@ -28,7 +28,7 @@
 /*
  * Determine whether we're in secure boot mode.
  */
-enum __sb_init efi_secureboot_mode efi_get_secureboot(efi_system_table_t 
*sys_table_arg)
+static enum __sb_init efi_secureboot_mode 
__efi_get_secureboot(efi_system_table_t *sys_table_arg)
 {
u32 attr;
u8 secboot, setupmode, moksbstate;
diff --git a/drivers/firmware/efi/libstub/secureboot.c 
b/drivers/firmware/efi/libstub/secureboot.c
index 1142170..f872afd 100644
--- a/drivers/firmware/efi/libstub/secureboot.c
+++ b/drivers/firmware/efi/libstub/secureboot.c
@@ -23,3 +23,8 @@
 __VA_ARGS__);
 
 #include "secureboot-core.c"
+
+enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table_arg)
+{
+   return __efi_get_secureboot(sys_table_arg);
+}
-- 
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 3/4] efi: Tweak efi_get_secureboot() and its data section assignment

2018-01-09 Thread Daniel Kiper

Otherwise they are not freed after the kernel proper init.

Signed-off-by: Daniel Kiper 
---
 arch/x86/xen/efi.c |3 +++
 drivers/firmware/efi/libstub/secureboot-core.c |   12 ++--
 drivers/firmware/efi/libstub/secureboot.c  |3 +++
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index e089fa7..5ad2b8f 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -28,6 +28,9 @@
 #include 
 #include 
 
+#define __sb_init  __init
+#define __sb_initconst __initconst
+
 #define pr_efi(sys_table, msg)
 #define pr_efi_err(sys_table, msg)
 
diff --git a/drivers/firmware/efi/libstub/secureboot-core.c 
b/drivers/firmware/efi/libstub/secureboot-core.c
index 11a4feb..d503ee4 100644
--- a/drivers/firmware/efi/libstub/secureboot-core.c
+++ b/drivers/firmware/efi/libstub/secureboot-core.c
@@ -11,24 +11,24 @@
  */
 
 /* BIOS variables */
-static const efi_guid_t efi_variable_guid = EFI_GLOBAL_VARIABLE_GUID;
-static const efi_char16_t efi_SecureBoot_name[] = {
+static const efi_guid_t efi_variable_guid __sb_initconst = 
EFI_GLOBAL_VARIABLE_GUID;
+static const efi_char16_t efi_SecureBoot_name[] __sb_initconst = {
'S', 'e', 'c', 'u', 'r', 'e', 'B', 'o', 'o', 't', 0
 };
-static const efi_char16_t efi_SetupMode_name[] = {
+static const efi_char16_t efi_SetupMode_name[] __sb_initconst = {
'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
 };
 
 /* SHIM variables */
-static const efi_guid_t shim_guid = EFI_SHIM_LOCK_GUID;
-static const efi_char16_t shim_MokSBState_name[] = {
+static const efi_guid_t shim_guid __sb_initconst = EFI_SHIM_LOCK_GUID;
+static const efi_char16_t shim_MokSBState_name[] __sb_initconst = {
'M', 'o', 'k', 'S', 'B', 'S', 't', 'a', 't', 'e', 0
 };
 
 /*
  * Determine whether we're in secure boot mode.
  */
-enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table_arg)
+enum __sb_init efi_secureboot_mode efi_get_secureboot(efi_system_table_t 
*sys_table_arg)
 {
u32 attr;
u8 secboot, setupmode, moksbstate;
diff --git a/drivers/firmware/efi/libstub/secureboot.c 
b/drivers/firmware/efi/libstub/secureboot.c
index 4a6159f..1142170 100644
--- a/drivers/firmware/efi/libstub/secureboot.c
+++ b/drivers/firmware/efi/libstub/secureboot.c
@@ -14,6 +14,9 @@
 
 #include "efistub.h"
 
+#define __sb_init
+#define __sb_initconst
+
 #define get_efi_var(name, vendor, ...) \
efi_call_runtime(get_variable, \
 (efi_char16_t *)(name), (efi_guid_t *)(vendor), \
-- 
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/4] efi/stub: Extract efi_get_secureboot() to separate file

2018-01-09 Thread Daniel Kiper

We have to call efi_get_secureboot() from early Xen dom0 boot code to properly
initialize boot_params.secure_boot. Sadly it lives in the EFI stub. Hence, it is
not readily reachable from the kernel proper. So, move efi_get_secureboot() to
separate file which can be included from the core kernel code. Subsequent patch
will add efi_get_secureboot() call from Xen dom0 boot code.

There is no functional change.

Signed-off-by: Daniel Kiper 
---
 drivers/firmware/efi/libstub/secureboot-core.c |   77 
 drivers/firmware/efi/libstub/secureboot.c  |   66 +---
 2 files changed, 78 insertions(+), 65 deletions(-)
 create mode 100644 drivers/firmware/efi/libstub/secureboot-core.c

diff --git a/drivers/firmware/efi/libstub/secureboot-core.c 
b/drivers/firmware/efi/libstub/secureboot-core.c
new file mode 100644
index 000..11a4feb
--- /dev/null
+++ b/drivers/firmware/efi/libstub/secureboot-core.c
@@ -0,0 +1,77 @@
+/*
+ * Secure boot handling.
+ *
+ * Copyright (C) 2013,2014 Linaro Limited
+ * Roy Franz 
+ * Copyright (C) 2013 Red Hat, Inc.
+ * Mark Salter 
+ *
+ * This file is part of the Linux kernel, and is made available under the
+ * terms of the GNU General Public License version 2.
+ */
+
+/* BIOS variables */
+static const efi_guid_t efi_variable_guid = EFI_GLOBAL_VARIABLE_GUID;
+static const efi_char16_t efi_SecureBoot_name[] = {
+   'S', 'e', 'c', 'u', 'r', 'e', 'B', 'o', 'o', 't', 0
+};
+static const efi_char16_t efi_SetupMode_name[] = {
+   'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
+};
+
+/* SHIM variables */
+static const efi_guid_t shim_guid = EFI_SHIM_LOCK_GUID;
+static const efi_char16_t shim_MokSBState_name[] = {
+   'M', 'o', 'k', 'S', 'B', 'S', 't', 'a', 't', 'e', 0
+};
+
+/*
+ * Determine whether we're in secure boot mode.
+ */
+enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table_arg)
+{
+   u32 attr;
+   u8 secboot, setupmode, moksbstate;
+   unsigned long size;
+   efi_status_t status;
+
+   size = sizeof(secboot);
+   status = get_efi_var(efi_SecureBoot_name, _variable_guid,
+NULL, , );
+   if (status == EFI_NOT_FOUND)
+   return efi_secureboot_mode_disabled;
+   if (status != EFI_SUCCESS)
+   goto out_efi_err;
+
+   size = sizeof(setupmode);
+   status = get_efi_var(efi_SetupMode_name, _variable_guid,
+NULL, , );
+   if (status != EFI_SUCCESS)
+   goto out_efi_err;
+
+   if (secboot == 0 || setupmode == 1)
+   return efi_secureboot_mode_disabled;
+
+   /*
+* See if a user has put the shim into insecure mode. If so, and if the
+* variable doesn't have the runtime attribute set, we might as well
+* honor that.
+*/
+   size = sizeof(moksbstate);
+   status = get_efi_var(shim_MokSBState_name, _guid,
+, , );
+
+   /* If it fails, we don't care why. Default to secure */
+   if (status != EFI_SUCCESS)
+   goto secure_boot_enabled;
+   if (!(attr & EFI_VARIABLE_RUNTIME_ACCESS) && moksbstate == 1)
+   return efi_secureboot_mode_disabled;
+
+secure_boot_enabled:
+   pr_efi(sys_table_arg, "UEFI Secure Boot is enabled.\n");
+   return efi_secureboot_mode_enabled;
+
+out_efi_err:
+   pr_efi_err(sys_table_arg, "Could not determine UEFI Secure Boot 
status.\n");
+   return efi_secureboot_mode_unknown;
+}
diff --git a/drivers/firmware/efi/libstub/secureboot.c 
b/drivers/firmware/efi/libstub/secureboot.c
index 959777e..4a6159f 100644
--- a/drivers/firmware/efi/libstub/secureboot.c
+++ b/drivers/firmware/efi/libstub/secureboot.c
@@ -14,73 +14,9 @@
 
 #include "efistub.h"
 
-/* BIOS variables */
-static const efi_guid_t efi_variable_guid = EFI_GLOBAL_VARIABLE_GUID;
-static const efi_char16_t efi_SecureBoot_name[] = {
-   'S', 'e', 'c', 'u', 'r', 'e', 'B', 'o', 'o', 't', 0
-};
-static const efi_char16_t efi_SetupMode_name[] = {
-   'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
-};
-
-/* SHIM variables */
-static const efi_guid_t shim_guid = EFI_SHIM_LOCK_GUID;
-static efi_char16_t const shim_MokSBState_name[] = {
-   'M', 'o', 'k', 'S', 'B', 'S', 't', 'a', 't', 'e', 0
-};
-
 #define get_efi_var(name, vendor, ...) \
efi_call_runtime(get_variable, \
 (efi_char16_t *)(name), (efi_guid_t *)(vendor), \
 __VA_ARGS__);
 
-/*
- * Determine whether we're in secure boot mode.
- */
-enum efi_secureboot_mode efi_get_secureboot(efi_system_table_t *sys_table_arg)
-{
-   u32 attr;
-   u8 secboot, setupmode, moksbstate;
-   unsigned long size;
-   efi_status_t status;
-
-   size = sizeof(secboot);
-   status = get_efi_var(efi_SecureBoot_name, _variable_guid,
-NULL, , );
-   if

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

2018-01-09 Thread Bhupesh Sharma

On Tue, Jan 9, 2018 at 10:12 AM, AKASHI Takahiro
 wrote:
> Bhupesh,
>
> On Tue, Jan 09, 2018 at 01:30:07AM +0530, Bhupesh Sharma wrote:
>> Hello Akashi,
>>
>> On Tue, Dec 26, 2017 at 8:26 AM, Bhupesh Sharma  wrote:
>> > On Tue, Dec 26, 2017 at 7:58 AM, AKASHI Takahiro
>> >  wrote:
>> >> On Tue, Dec 26, 2017 at 09:35:17AM +0800, Dave Young wrote:
>> >>> [snip]
>> >>> > > > Well, we may be able to change pr_warn() to pr_warn_once() here, 
>> >>> > > > but
>> >>> > > > I hope that adding "numa=off" to kernel command line should also 
>> >>> > > > work.
>> >>> > >
>> >>> > > Hmm, adding "numa=off" to crashkernel bootargs works, and TBH it was
>> >>> > > my initial thought process as well, but I am not sure if this will
>> >>> > > cause any regressions on aarch64 systems which use crashdump feature.
>> >>> >
>> >>> > It should be fine since we use numa=off by default for all other arches
>> >>> > ie. x86, ppc64 and s390. Actually disabling numa in kdump kernel can 
>> >>> > save
>> >>> > mm component memory usage.
>> >>> >
>> >>>
>> >>> Forgot to say I means in RHEL and Fedora we use numa=off for kdump..
>> >>
>> >> Thank you for the clarification.
>> >> (It might be better to make numa off automatically if maxcpus == 0 (and 
>> >> 1?).)
>> >>
>> >
>> > Not sure if we can leave this to the distribution-specific kdump
>> > scripts (as the crashkernel boot can be held up for sufficient time
>> > and may appear stuck). The distribution scripts may be different (for
>> > e.g. ubuntu and RHEL/fedora) across distributions and may have
>> > different bootarg options.
>> >
>> > So how about considering a kernel fix only which doesn't require
>> > relying on changing the distribution-specific kdump scripts, as we
>> > should avoid introducing a regression while trying to fix a regression
>> > :)
>> >
>> > Just my 2 cents.
>> >
>>
>> Sorry for the delay but I was on holidays in the last week.
>>
>> Are you planning to send a patch to fix this issue or do you want me
>> to send a RFC version instead?
>
> I should have submitted my own patch before my new year holidays,
> but I will do so as soon as possible.

Thanks for the confirmation.
I will look forward to the patches and give them a go on the arm64
boards available with me.

Regards,
Bhupesh

>
>> i think this is a blocking issue for aarch64 kdump support on newer
>> kernels (v4.14) and we are already hearing about this issue from other
>> users as well, so it would be great to get this fixed now that we have
>> root-caused the issue and found a possible way around.
>>
>> Regards,
>> Bhupesh
--
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/4] x86/xen/efi: Initialize boot_params.secure_boot in xen_efi_init()

[PATCH 0/4] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

[PATCH 4/4] efi: Rename efi_get_secureboot() to __efi_get_secureboot() and make it static

[PATCH 3/4] efi: Tweak efi_get_secureboot() and its data section assignment

[PATCH 1/4] efi/stub: Extract efi_get_secureboot() to separate file

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

6 matches

Site Navigation

Mail list logo

Footer information