[PATCH 1/3] arm64: Define cputype macros for Falkor CPU

[Shanker Donthineni]

Add cputype definition macros for Qualcomm Datacenter Technologies
Falkor CPU in cputype.h. It's unfortunate that the first revision
of the Falkor CPU used the wrong part number 0x800, got fixed in v2
chip with part number 0xC00, and would be used the same value for
future revisions.

Signed-off-by: Shanker Donthineni 
Signed-off-by: Neil Leeder 
---
 arch/arm64/include/asm/cputype.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 235e77d..cbf08d7 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -91,6 +91,7 @@
 #define BRCM_CPU_PART_VULCAN   0x516
 
 #define QCOM_CPU_PART_FALKOR_V10x800
+#define QCOM_CPU_PART_FALKOR   0xC00
 
 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A57)
@@ -99,6 +100,7 @@
 #define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_81XX)
 #define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_83XX)
 #define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, 
QCOM_CPU_PART_FALKOR_V1)
+#define MIDR_QCOM_FALKOR MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR)
 
 #ifndef __ASSEMBLY__
 
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

--
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/3] arm64: Prepare SCTLR_ELn accesses to handle Falkor erratum 1041

[Shanker Donthineni]

This patch introduces two helper macros read_sctlr and write_sctlr
to access system register SCTLR_ELn. Replace all MSR/MRS references
to sctlr_el1{el2} with macros.

This should cause no behavioral change.

Signed-off-by: Shanker Donthineni 
---
 arch/arm64/include/asm/assembler.h  | 18 ++
 arch/arm64/kernel/cpu-reset.S   |  4 ++--
 arch/arm64/kernel/efi-entry.S   |  8 
 arch/arm64/kernel/head.S| 18 +-
 arch/arm64/kernel/relocate_kernel.S |  4 ++--
 arch/arm64/kvm/hyp-init.S   |  6 +++---
 arch/arm64/mm/proc.S|  6 +++---
 7 files changed, 41 insertions(+), 23 deletions(-)

diff --git a/arch/arm64/include/asm/assembler.h 
b/arch/arm64/include/asm/assembler.h
index d58a625..b6dfb4f 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -499,4 +499,22 @@
 #endif
.endm
 
+/**
+ * Read value of the system control register SCTLR_ELn.
+ *   eln: which system control register.
+ *   reg: contents of the SCTLR_ELn.
+ */
+   .macro  read_sctlr, eln, reg
+   mrs \reg, sctlr_\eln
+   .endm
+
+/**
+ * Write the value to the system control register SCTLR_ELn.
+ *   eln: which system control register.
+ *   reg: the value to be written.
+ */
+   .macro  write_sctlr, eln, reg
+   msr sctlr_\eln, \reg
+   .endm
+
 #endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
index 65f42d2..9224abd 100644
--- a/arch/arm64/kernel/cpu-reset.S
+++ b/arch/arm64/kernel/cpu-reset.S
@@ -34,10 +34,10 @@
  */
 ENTRY(__cpu_soft_restart)
/* Clear sctlr_el1 flags. */
-   mrs x12, sctlr_el1
+   read_sctlr el1, x12
ldr x13, =SCTLR_ELx_FLAGS
bic x12, x12, x13
-   msr sctlr_el1, x12
+   write_sctlr el1, x12
isb
 
cbz x0, 1f  // el2_switch?
diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
index 4e6ad35..acae627 100644
--- a/arch/arm64/kernel/efi-entry.S
+++ b/arch/arm64/kernel/efi-entry.S
@@ -93,17 +93,17 @@ ENTRY(entry)
mrs x0, CurrentEL
cmp x0, #CurrentEL_EL2
b.ne1f
-   mrs x0, sctlr_el2
+   read_sctlr el2, x0
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
-   msr sctlr_el2, x0
+   write_sctlr el2, x0
isb
b   2f
 1:
-   mrs x0, sctlr_el1
+   read_sctlr el1, x0
bic x0, x0, #1 << 0 // clear SCTLR.M
bic x0, x0, #1 << 2 // clear SCTLR.C
-   msr sctlr_el1, x0
+   write_sctlr el1, x0
isb
 2:
/* Jump to kernel entry point */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 0b243ec..b8d5b73 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -388,18 +388,18 @@ ENTRY(el2_setup)
mrs x0, CurrentEL
cmp x0, #CurrentEL_EL2
b.eq1f
-   mrs x0, sctlr_el1
+   read_sctlr el1, x0
 CPU_BE(orr x0, x0, #(3 << 24)  )   // Set the EE and E0E 
bits for EL1
 CPU_LE(bic x0, x0, #(3 << 24)  )   // Clear the EE and E0E 
bits for EL1
-   msr sctlr_el1, x0
+   write_sctlr el1, x0
mov w0, #BOOT_CPU_MODE_EL1  // This cpu booted in EL1
isb
ret
 
-1: mrs x0, sctlr_el2
+1: read_sctlr el2, x0
 CPU_BE(orr x0, x0, #(1 << 25)  )   // Set the EE bit for 
EL2
 CPU_LE(bic x0, x0, #(1 << 25)  )   // Clear the EE bit for 
EL2
-   msr sctlr_el2, x0
+   write_sctlr el2, x0
 
 #ifdef CONFIG_ARM64_VHE
/*
@@ -511,7 +511,7 @@ install_el2_stub:
mov x0, #0x0800 // Set/clear RES{1,0} bits
 CPU_BE(movkx0, #0x33d0, lsl #16)   // Set EE and E0E on BE 
systems
 CPU_LE(movkx0, #0x30d0, lsl #16)   // Clear EE and E0E on 
LE systems
-   msr sctlr_el1, x0
+   write_sctlr el1, x0
 
/* Coprocessor traps. */
mov x0, #0x33ff
@@ -664,7 +664,7 @@ ENTRY(__enable_mmu)
msr ttbr0_el1, x1   // load TTBR0
msr ttbr1_el1, x2   // load TTBR1
isb
-   msr sctlr_el1, x0
+   write_sctlr el1, x0
isb
/*
 * Invalidate the local I-cache so that any instructions fetched
@@ -716,7 +716,7 @@ ENDPROC(__relocate_kernel)
 __primary_switch:
 #ifdef CONFIG_RANDOMIZE_BASE
mov x19, x0 // preserve new SCTLR_EL1 value
-   mrs x20, sctlr_el1  // preserve old SCTLR_EL1 value
+   read_sctlr el1, x20 // preserve old SCTLR_EL1 value
 #endif
 
bl  __enable_mmu
@@ -732,14 +732,14 @@ __primary_switch:
 * to take into account by discarding the current 

[PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041

[Shanker Donthineni]

The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative instruction fetch from
an exception level for which all stages of translation are disabled.
Specifically, the core is permitted to speculatively fetch from the
4KB region containing the current program counter and next 4KB.

When translation is changed from enabled to disabled for the running
exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the
Falkor core may errantly speculatively access memory locations outside
of the 4KB region permitted by the architecture. The errant memory
access may lead to one of the following unexpected behaviors.

1) A System Error Interrupt (SEI) being raised by the Falkor core due
   to the errant memory access attempting to access a region of memory
   that is protected by a slave-side memory protection unit.
2) Unpredictable device behavior due to a speculative read from device
   memory. This behavior may only occur if the instruction cache is
   disabled prior to or coincident with translation being changed from
   enabled to disabled.

To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.

Signed-off-by: Shanker Donthineni 
---
 Documentation/arm64/silicon-errata.txt |  1 +
 arch/arm64/Kconfig | 10 ++
 arch/arm64/include/asm/assembler.h | 17 +
 arch/arm64/include/asm/cpucaps.h   |  3 ++-
 arch/arm64/kernel/cpu_errata.c | 16 
 arch/arm64/kernel/efi-entry.S  |  4 ++--
 arch/arm64/kernel/head.S   |  4 ++--
 7 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/Documentation/arm64/silicon-errata.txt 
b/Documentation/arm64/silicon-errata.txt
index 66e8ce1..704770c0 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -74,3 +74,4 @@ stable kernels.
 | Qualcomm Tech. | Falkor v1   | E1003   | 
QCOM_FALKOR_ERRATUM_1003|
 | Qualcomm Tech. | Falkor v1   | E1009   | 
QCOM_FALKOR_ERRATUM_1009|
 | Qualcomm Tech. | QDF2400 ITS | E0065   | 
QCOM_QDF2400_ERRATUM_0065   |
+| Qualcomm Tech. | Falkor v{1,2}   | E1041   | 
QCOM_FALKOR_ERRATUM_1041|
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0df64a6..7e933fb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -539,6 +539,16 @@ config QCOM_QDF2400_ERRATUM_0065
 
  If unsure, say Y.
 
+config QCOM_FALKOR_ERRATUM_1041
+   bool "Falkor E1041: Speculative instruction fetches might cause errant 
memory access"
+   default y
+   help
+ Falkor CPU may speculatively fetch instructions from an improper
+ memory location when MMU translation is changed from SCTLR_ELn[M]=1
+ to SCTLR_ELn[M]=0. Prefix an ISB instruction to fix the problem.
+
+ If unsure, say Y.
+
 endmenu
 
 
diff --git a/arch/arm64/include/asm/assembler.h 
b/arch/arm64/include/asm/assembler.h
index b6dfb4f..4c91efb 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Enable and disable interrupts.
@@ -514,6 +515,22 @@
  *   reg: the value to be written.
  */
.macro  write_sctlr, eln, reg
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
+alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1041
+   tbnz\reg, #0, 8000f  // enable MMU?
+   isb
+8000:
+alternative_else_nop_endif
+#endif
+   msr sctlr_\eln, \reg
+   .endm
+
+   .macro  early_write_sctlr, eln, reg
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
+   tbnz\reg, #0, 8000f  // enable MMU?
+   isb
+8000:
+#endif
msr sctlr_\eln, \reg
.endm
 
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 8da6216..7f7a59d 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -40,7 +40,8 @@
 #define ARM64_WORKAROUND_85892119
 #define ARM64_WORKAROUND_CAVIUM_30115  20
 #define ARM64_HAS_DCPOP21
+#define ARM64_WORKAROUND_QCOM_FALKOR_E1041 22
 
-#define ARM64_NCAPS22
+#define ARM64_NCAPS23
 
 #endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 0e27f86..27f9a45 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -179,6 +179,22 @@ static int cpu_enable_trap_ctr_access(void *__unused)
   MIDR_CPU_VAR_REV(0, 0)),
},
 #endif
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1041
+   {
+   .desc = "Qualcomm Technologies Falkor erratum 1041",
+   .capability = ARM64_WORKAROUND_QCOM_FALKOR_E1041,
+   MIDR_RANGE(MIDR_QCOM_FALKOR_V1,
+  

[PATCH 0/3] Implement a software workaround for Falkor erratum 1041

[Shanker Donthineni]

On Falkor CPU, we’ve discovered a hardware issue which might lead to a
kernel crash or the unexpected behavior. The Falkor core may errantly
access memory locations on speculative instruction fetches. This may
happen whenever MMU translation state, SCTLR_ELn[M] bit is being changed
from enabled to disabled for the currently running exception level. To
prevent the errant hardware behavior, software must execute an ISB
immediately prior to executing the MSR that changes SCTLR_ELn[M] from a
value of 1 to 0. To simplify the complexity of a workaround, this patch
series issues an ISB whenever SCTLR_ELn[M] is changed to 0 to fix the
Falkor erratum 1041.

Patch1:
  - CPUTYPE definitions for Falkor CPU.

Patch2:
  - Define two ASM helper macros to read/write SCTLR_ELn register.

Patch3:
  - Actual workaround changes for erratum E1041.

Shanker Donthineni (3):
  arm64: Define cputype macros for Falkor CPU
  arm64: Prepare SCTLR_ELn accesses to handle Falkor erratum 1041
  arm64: Add software workaround for Falkor erratum 1041

 Documentation/arm64/silicon-errata.txt |  1 +
 arch/arm64/Kconfig | 10 ++
 arch/arm64/include/asm/assembler.h | 35 ++
 arch/arm64/include/asm/cpucaps.h   |  3 ++-
 arch/arm64/include/asm/cputype.h   |  2 ++
 arch/arm64/kernel/cpu-reset.S  |  4 ++--
 arch/arm64/kernel/cpu_errata.c | 16 
 arch/arm64/kernel/efi-entry.S  |  8 
 arch/arm64/kernel/head.S   | 18 -
 arch/arm64/kernel/relocate_kernel.S|  4 ++--
 arch/arm64/kvm/hyp-init.S  |  6 +++---
 arch/arm64/mm/proc.S   |  6 +++---
 12 files changed, 89 insertions(+), 24 deletions(-)

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

--
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 03/27] Enforce module signatures if the kernel is locked down

[Mimi Zohar]

On Thu, 2017-11-02 at 22:01 +, David Howells wrote:
> Mimi Zohar  wrote:
> 
> > Right, it would never get here if the IMA signature verification
> > fails.  If sig_enforce is not enabled, then it will also work.  So the
> > only case is if sig_enforced is enabled and there is no key.
> > 
> > eg.
> >          else if (can_do_ima_check && is_ima_appraise_enabled())
> >                 err = 0;
> 
> I'm not sure where you want to put that, but I can't just do this:
> 
>   /* Not having a signature is only an error if we're strict. */
>   if (err == -ENOKEY && !sig_enforce &&
>   (!can_do_ima_check || !is_ima_appraise_enabled()) &&

The above IMA checks aren't needed here.

>   !kernel_is_locked_down("Loading of unsigned modules"))
>   err = 0;
>   else if (can_do_ima_check && is_ima_appraise_enabled())
>   err = 0;
> 
> because that'll print out a message in lockdown mode saying that you're not
> allowed to do that and then maybe do it anyway.

Then at least for now, document that even though kernel modules might
be signed and verified by IMA-appraisal, that in lockdown mode they
also require an appended signature.

Mimi

--
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: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

[Mimi Zohar]

On Thu, 2017-11-02 at 22:04 +, David Howells wrote:
> Mimi Zohar  wrote:
> 
> > > Only validly signed device firmware may be loaded.
> > 
> > fw_get_filesystem_firmware() calls kernel_read_file_from_path() to
> > read the firmware, which calls into the security hooks. Is there
> > another place that validates the firmware signatures.  I'm not seeing
> > which patch requires firmware to be signed?
> 
> Luis has a set of patches for this.  However, I'm not sure if that's going
> anywhere at the moment.  Possibly I should remove this from the manpage for
> the moment.

Or reflect that IMA-appraisal, if enabled, will enforce firmware being
validly signed.

Mimi

--
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

Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

[David Howells]

Mimi Zohar  wrote:

> > Only validly signed device firmware may be loaded.
> 
> fw_get_filesystem_firmware() calls kernel_read_file_from_path() to
> read the firmware, which calls into the security hooks. Is there
> another place that validates the firmware signatures.  I'm not seeing
> which patch requires firmware to be signed?

Luis has a set of patches for this.  However, I'm not sure if that's going
anywhere at the moment.  Possibly I should remove this from the manpage for
the moment.

David
--
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 00/27] security, efi: Add kernel lockdown

[Mimi Zohar]

Hi David,

>From the man page:

> Only validly signed modules may be loaded.
> .P
> Only validly signed binaries may be kexec'd.
> .P
> Only validly signed device firmware may be loaded.

fw_get_filesystem_firmware() calls kernel_read_file_from_path() to
read the firmware, which calls into the security hooks. Is there
another place that validates the firmware signatures.  I'm not seeing
which patch requires firmware to be signed?

Mimi

--
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 03/27] Enforce module signatures if the kernel is locked down

[David Howells]

Mimi Zohar  wrote:

> Right, it would never get here if the IMA signature verification
> fails.  If sig_enforce is not enabled, then it will also work.  So the
> only case is if sig_enforced is enabled and there is no key.
> 
> eg.
>          else if (can_do_ima_check && is_ima_appraise_enabled())
>                 err = 0;

I'm not sure where you want to put that, but I can't just do this:

/* Not having a signature is only an error if we're strict. */
if (err == -ENOKEY && !sig_enforce &&
(!can_do_ima_check || !is_ima_appraise_enabled()) &&
!kernel_is_locked_down("Loading of unsigned modules"))
err = 0;
else if (can_do_ima_check && is_ima_appraise_enabled())
err = 0;

because that'll print out a message in lockdown mode saying that you're not
allowed to do that and then maybe do it anyway.

David
--
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 03/27] Enforce module signatures if the kernel is locked down

[Mimi Zohar]

On Thu, 2017-11-02 at 21:30 +, David Howells wrote:
> Mimi Zohar  wrote:
> 
> > By this point, IMA-appraisal has already verified the kernel module
> > signature back in kernel_read_file_from_fd(), if it was required.
> >  Having a key with which to verify the appended signature or requiring
> > an appended signature, should not be required as well.
> 
> I guess I don't need to put in any support for IMA here, then, and you've
> taken care of it in your patchset such that it won't actually go into
> module_sig_check() in that case (or will at least return immediately).

Right, it would never get here if the IMA signature verification
fails.  If sig_enforce is not enabled, then it will also work.  So the
only case is if sig_enforced is enabled and there is no key.

eg.
         else if (can_do_ima_check && is_ima_appraise_enabled())
                err = 0;

Mimi 

--
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 03/27] Enforce module signatures if the kernel is locked down

[David Howells]

Mimi Zohar  wrote:

> By this point, IMA-appraisal has already verified the kernel module
> signature back in kernel_read_file_from_fd(), if it was required.
>  Having a key with which to verify the appended signature or requiring
> an appended signature, should not be required as well.

I guess I don't need to put in any support for IMA here, then, and you've
taken care of it in your patchset such that it won't actually go into
module_sig_check() in that case (or will at least return immediately).

David
--
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 03/27] Enforce module signatures if the kernel is locked down

[Mimi Zohar]

On Thu, 2017-11-02 at 17:22 +, David Howells wrote:

>  #ifdef CONFIG_MODULE_SIG
> -static int module_sig_check(struct load_info *info, int flags)
> +static int module_sig_check(struct load_info *info, int flags,
> + bool can_do_ima_check)
>  {
>   int err = -ENOKEY;
>   const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
> @@ -2781,13 +2783,16 @@ static int module_sig_check(struct load_info *info, 
> int flags)
>   }
>  
>   /* Not having a signature is only an error if we're strict. */
> - if (err == -ENOKEY && !sig_enforce)
> + if (err == -ENOKEY && !sig_enforce &&
> + (!can_do_ima_check || !is_ima_appraise_enabled()) &&
> + !kernel_is_locked_down("Loading of unsigned modules"))

By this point, IMA-appraisal has already verified the kernel module
signature back in kernel_read_file_from_fd(), if it was required.
 Having a key with which to verify the appended signature or requiring
an appended signature, should not be required as well.

Mimi

--
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 07/27] kexec_file: Disable at runtime if securelevel has been set

[David Howells]

Hi Mimi,

I've adjusted the patch as below.

David
---
commit bf33218ad2bf04f1b92f5c32499ab906f107864c
Author: Chun-Yi Lee 
Date:   Wed May 24 14:56:03 2017 +0100

kexec_file: Restrict at runtime if the kernel is locked down

When KEXEC_VERIFY_SIG is not enabled, kernel should not load images through
kexec_file systemcall if the kernel is locked down unless IMA can be used
to validate the image.

This code was showed in Matthew's patch but not in git:
https://lkml.org/lkml/2015/3/13/778

Cc: Matthew Garrett 
Signed-off-by: Chun-Yi Lee 
Signed-off-by: David Howells 
Reviewed-by: James Morris 
cc: ke...@lists.infradead.org

diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 9f48f4412297..3ba28fc3fab0 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -255,6 +255,14 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, 
initrd_fd,
if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
return -EPERM;
 
+   /* Don't permit images to be loaded into trusted kernels if we're not
+* going to verify the signature on them
+*/
+   if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) &&
+   !is_ima_appraise_enabled() &&
+   kernel_is_locked_down("kexec of unsigned images"))
+   return -EPERM;
+
/* Make sure we have a legal set of flags */
if (flags != (flags & KEXEC_FILE_FLAGS))
return -EINVAL;
--
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 03/27] Enforce module signatures if the kernel is locked down

[David Howells]

Hi Mimi,

I've altered this patch to allow for IMA appraisal on finit_module().  See the
attached.

David
---
commit c0d5336356004e7543314e388755a00e725521da
Author: David Howells 
Date:   Wed May 24 14:56:01 2017 +0100

Enforce module signatures if the kernel is locked down

If the kernel is locked down, require that all modules have valid
signatures that we can verify or that IMA can validate the file.

Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
Reviewed-by: James Morris 

diff --git a/kernel/module.c b/kernel/module.c
index de66ec825992..0ce29c8aa75a 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -64,6 +64,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "module-internal.h"
 
@@ -2757,7 +2758,8 @@ static inline void kmemleak_load_module(const struct 
module *mod,
 #endif
 
 #ifdef CONFIG_MODULE_SIG
-static int module_sig_check(struct load_info *info, int flags)
+static int module_sig_check(struct load_info *info, int flags,
+   bool can_do_ima_check)
 {
int err = -ENOKEY;
const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
@@ -2781,13 +2783,16 @@ static int module_sig_check(struct load_info *info, int 
flags)
}
 
/* Not having a signature is only an error if we're strict. */
-   if (err == -ENOKEY && !sig_enforce)
+   if (err == -ENOKEY && !sig_enforce &&
+   (!can_do_ima_check || !is_ima_appraise_enabled()) &&
+   !kernel_is_locked_down("Loading of unsigned modules"))
err = 0;
 
return err;
 }
 #else /* !CONFIG_MODULE_SIG */
-static int module_sig_check(struct load_info *info, int flags)
+static int module_sig_check(struct load_info *info, int flags,
+   bool can_do_ima_check)
 {
return 0;
 }
@@ -3630,13 +3635,13 @@ static int unknown_module_param_cb(char *param, char 
*val, const char *modname,
 /* Allocate and load the module: note that size of section 0 is always
zero, and we rely on this for optional sections. */
 static int load_module(struct load_info *info, const char __user *uargs,
-  int flags)
+  int flags, bool can_do_ima_check)
 {
struct module *mod;
long err;
char *after_dashes;
 
-   err = module_sig_check(info, flags);
+   err = module_sig_check(info, flags, can_do_ima_check);
if (err)
goto free_copy;
 
@@ -3830,7 +3835,7 @@ SYSCALL_DEFINE3(init_module, void __user *, umod,
if (err)
return err;
 
-   return load_module(, uargs, 0);
+   return load_module(, uargs, 0, false);
 }
 
 SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, flags)
@@ -3857,7 +3862,7 @@ SYSCALL_DEFINE3(finit_module, int, fd, const char __user 
*, uargs, int, flags)
info.hdr = hdr;
info.len = size;
 
-   return load_module(, uargs, flags);
+   return load_module(, uargs, flags, true);
 }
 
 static inline int within(unsigned long addr, void *start, unsigned long size)
--
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 07/27] kexec_file: Disable at runtime if securelevel has been set

[David Howells]

Mimi Zohar  wrote:

> At some point, we'll want to also require the initramfs be signed as well.

That could be tricky.  In Fedora, at least, that's assembled on the fly to
include just the drivers you need to be able to mount your root fs and find
the rest of your modules.  (Unless you mean just for the installer)

David
--
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

Darlehensangebot

[Mr David Williams]

Schönen Tag,
 
Sie benötigen einen echten Kredit online Ihre Rechnungen zu sichern?
Startet ein neues Unternehmen? Sie benötigen einen persönlichen Kredit
oder Business-Darlehen? Wir bieten ein Darlehen von € 10.000 bis €
500,000.000.00 mit 2% Zinsen pro Jahr und auch mit einem
erschwinglichen Rückzahlungsbedingungen und Zustand. Ich suche für
Darlehen und Projektinvestmentfonds ? Wir halten professionelle
Exzellenz, unsere Definition von Exzellenz liegt in hervorragenden
Kundenservice, erschwingliche Zahlung und Rückzahlung Pläne, schnell
und einfach-Prozess.
Hochachtungsvoll
 
Freundliche Grüße,
Herr David Williams
--
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