[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Nishanth Menon]

Hi Folks,

This is a follow through on the discussion we have had in [1].
This itself is'nt a complete solution and is based on recommendation
This from Arm[2] for variant 2 CVE-2017-5715

The Linux kernel discussions are spread out in [3], ATF and OPTEE
status are available in [4].

This is just an RFC series (build tested at this point) to check if
the direction is fine and should follow the final solution once kernel
patches get to upstream, IMHO.

NOTE: As per ARM recommendations[2], and discussions in list[1] ARM
Cortex-A9/12/17 do not need additional steps in u-boot to enable the
OS level workarounds.

Nishanth Menon (2):
  ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
    CVE-2017-5715
  ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for
    CVE-2017-5715

 arch/arm/Kconfig           |  9 +++++++++
 arch/arm/cpu/armv7/start.S | 15 +++++++++++++--
 2 files changed, 22 insertions(+), 2 deletions(-)

[1] https://marc.info/?t=151639906500002&r=1&w=2
[2] https://developer.arm.com/support/security-update
[3] https://marc.info/?t=151543790400007&r=1&w=2 and the latest in https://marc.info/?l=linux-arm-kernel&m=151689379521082&w=2
[4] https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6 https://www.op-tee.org/security-advisories/ https://www.linaro.org/blog/meltdown-spectre/
-- 
2.15.1

[U-Boot] [RFC PATCH 1/2] ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for CVE-2017-5715

[Nishanth Menon]

As recommended by Arm in [1], IBE[2] has to be enabled unconditionally
for BPIALL to be functional on Cortex-A8 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.

NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
   provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the right
   locations.

[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/Bgbffjhh.html

Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Andre Przywara <Andre.Przywara@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/Kconfig           | 5 +++++
 arch/arm/cpu/armv7/start.S | 7 +++++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f6d57f5505ff..c2ac0fef9d0c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -86,6 +86,8 @@ config THUMB2_KERNEL
 # CONFIG_ARM_ERRATA_621766
 # CONFIG_ARM_ERRATA_798870
 # CONFIG_ARM_ERRATA_801819
+# CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+
 config ARM_ERRATA_430973
 	bool
 
@@ -155,6 +157,9 @@ config ARM_ERRATA_852423
 config ARM_ERRATA_855873
 	bool
 
+config ARM_CORTEX_A8_CVE_2017_5715
+	bool
+
 config CPU_ARM720T
 	bool
 	select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 7e2695761e98..64c5d7598dea 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -249,12 +249,15 @@ skip_errata_801819:
 	pop	{r1-r5}			@ Restore the cpu info - fall through
 #endif
 
-#ifdef CONFIG_ARM_ERRATA_430973
+#if defined(CONFIG_ARM_ERRATA_430973) || defined (CONFIG_ARM_CORTEX_A8_CVE_2017_5715)
 	mrc	p15, 0, r0, c1, c0, 1	@ Read ACR
 
+#ifdef CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+	orr	r0, r0, #(0x1 << 6)	@ Set IBE bit always to enable OS WA
+#else
 	cmp	r2, #0x21		@ Only on < r2p1
 	orrlt	r0, r0, #(0x1 << 6)	@ Set IBE bit
-
+#endif
 	push	{r1-r5}			@ Save the cpu info registers
 	bl	v7_arch_cp15_set_acr
 	pop	{r1-r5}			@ Restore the cpu info - fall through
-- 
2.15.1

[U-Boot] [RFC PATCH 2/2] ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for CVE-2017-5715

[Nishanth Menon]

As recommended by Arm in [1], ACR needs to be set[2] to enable
invalidation of BTB. This has to be enabled unconditionally for
ICIALLU to be functional on Cortex-A15 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.

NOTE: This patch in itself is NOT the final solution, this requires:
a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
   provide direct access to ACR register.
b) Operating Systems such as Linux to provide adequate workaround in the
   right locations.

[1] https://developer.arm.com/support/security-update
[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html

Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Andre Przywara <Andre.Przywara@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/Kconfig           | 4 ++++
 arch/arm/cpu/armv7/start.S | 8 ++++++++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c2ac0fef9d0c..116cee559ca4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -87,6 +87,7 @@ config THUMB2_KERNEL
 # CONFIG_ARM_ERRATA_798870
 # CONFIG_ARM_ERRATA_801819
 # CONFIG_ARM_CORTEX_A8_CVE_2017_5715
+# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
 
 config ARM_ERRATA_430973
 	bool
@@ -160,6 +161,9 @@ config ARM_ERRATA_855873
 config ARM_CORTEX_A8_CVE_2017_5715
 	bool
 
+config ARM_CORTEX_A15_CVE_2017_5715
+	bool
+
 config CPU_ARM720T
 	bool
 	select SYS_CACHE_SHIFT_5
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 64c5d7598dea..4835316bb37e 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -238,6 +238,14 @@ skip_errata_798870:
 skip_errata_801819:
 #endif
 
+#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
+	mrc	p15, 0, r0, c1, c0, 1	@ read auxilary control register
+	orr	r0, r0, #1 << 0		@ Enable invalidates of BTB
+	push	{r1-r5}			@ Save the cpu info registers
+	bl	v7_arch_cp15_set_acr
+	pop	{r1-r5}			@ Restore the cpu info - fall through
+#endif
+
 #ifdef CONFIG_ARM_ERRATA_454179
 	mrc	p15, 0, r0, c1, c0, 1	@ Read ACR
 
-- 
2.15.1

[U-Boot] [RFC PATCH 2/2] ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for CVE-2017-5715

[Marc Zyngier]

On 25/01/18 21:45, Nishanth Menon wrote:
> As recommended by Arm in [1], ACR needs to be set[2] to enable
> invalidation of BTB. This has to be enabled unconditionally for
> ICIALLU to be functional on Cortex-A15 processors. Provide a config

Not quite. ACTLR[0] (Enable invalidates of BTB) has to be set for the
BTB to be invalidated on ICIALLU. ICIALLU itself is always functional
(otherwise, we'd have much bigger problems).

> option for platforms to enable this option based on impact analysis
> for products.
> 
> NOTE: This patch in itself is NOT the final solution, this requires:
> a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
>    provide direct access to ACR register.
> b) Operating Systems such as Linux to provide adequate workaround in the
>    right locations.
> 
> [1] https://developer.arm.com/support/security-update
> [2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
> 
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: Andre Przywara <Andre.Przywara@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Tom Rini <trini@konsulko.com>
> Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
> 
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>  arch/arm/Kconfig           | 4 ++++
>  arch/arm/cpu/armv7/start.S | 8 ++++++++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index c2ac0fef9d0c..116cee559ca4 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -87,6 +87,7 @@ config THUMB2_KERNEL
>  # CONFIG_ARM_ERRATA_798870
>  # CONFIG_ARM_ERRATA_801819
>  # CONFIG_ARM_CORTEX_A8_CVE_2017_5715
> +# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
>  
>  config ARM_ERRATA_430973
>  	bool
> @@ -160,6 +161,9 @@ config ARM_ERRATA_855873
>  config ARM_CORTEX_A8_CVE_2017_5715
>  	bool
>  
> +config ARM_CORTEX_A15_CVE_2017_5715
> +	bool
> +
>  config CPU_ARM720T
>  	bool
>  	select SYS_CACHE_SHIFT_5
> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> index 64c5d7598dea..4835316bb37e 100644
> --- a/arch/arm/cpu/armv7/start.S
> +++ b/arch/arm/cpu/armv7/start.S
> @@ -238,6 +238,14 @@ skip_errata_798870:
>  skip_errata_801819:
>  #endif
>  
> +#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
> +	mrc	p15, 0, r0, c1, c0, 1	@ read auxilary control register
> +	orr	r0, r0, #1 << 0		@ Enable invalidates of BTB
> +	push	{r1-r5}			@ Save the cpu info registers
> +	bl	v7_arch_cp15_set_acr
> +	pop	{r1-r5}			@ Restore the cpu info - fall through
> +#endif
> +
>  #ifdef CONFIG_ARM_ERRATA_454179
>  	mrc	p15, 0, r0, c1, c0, 1	@ Read ACR
>  
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[U-Boot] [RFC PATCH 2/2] ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for CVE-2017-5715

[Nishanth Menon]

On 01/26/2018 03:17 AM, Marc Zyngier wrote:
> On 25/01/18 21:45, Nishanth Menon wrote:
>> As recommended by Arm in [1], ACR needs to be set[2] to enable
>> invalidation of BTB. This has to be enabled unconditionally for
>> ICIALLU to be functional on Cortex-A15 processors. Provide a config
> 
> Not quite. ACTLR[0] (Enable invalidates of BTB) has to be set for the
> BTB to be invalidated on ICIALLU. ICIALLU itself is always functional
> (otherwise, we'd have much bigger problems).
> 

Thanks Marc. That did come out completely wrong! Sorry about that. 
will update once we have kernel side story complete.


-- 
Regards,
Nishanth Menon

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Fabio Estevam]

On Thu, Jan 25, 2018 at 7:45 PM, Nishanth Menon <nm@ti.com> wrote:
> Hi Folks,
>
> This is a follow through on the discussion we have had in [1].
> This itself is'nt a complete solution and is based on recommendation
> This from Arm[2] for variant 2 CVE-2017-5715
>
> The Linux kernel discussions are spread out in [3], ATF and OPTEE
> status are available in [4].
>
> This is just an RFC series (build tested at this point) to check if
> the direction is fine and should follow the final solution once kernel
> patches get to upstream, IMHO.
>
> NOTE: As per ARM recommendations[2], and discussions in list[1] ARM
> Cortex-A9/12/17 do not need additional steps in u-boot to enable the
> OS level workarounds.
>
> Nishanth Menon (2):
>   ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
>     CVE-2017-5715
>   ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for
>     CVE-2017-5715

Do we have any feedback on this series, please?

[U-Boot] [RFC PATCH 1/2] ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for CVE-2017-5715

[Marek Vasut]

On 01/25/2018 10:45 PM, Nishanth Menon wrote:
> As recommended by Arm in [1], IBE[2] has to be enabled unconditionally
> for BPIALL to be functional on Cortex-A8 processors. Provide a config
> option for platforms to enable this option based on impact analysis
> for products.
> 
> NOTE: This patch in itself is NOT the final solution, this requires:
> a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
>    provide direct access to ACR register.
> b) Operating Systems such as Linux to provide adequate workaround in the right
>    locations.
> 
> [1] https://developer.arm.com/support/security-update
> [2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/Bgbffjhh.html
> 
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: Andre Przywara <Andre.Przywara@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Tom Rini <trini@konsulko.com>
> Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
> 
> Signed-off-by: Nishanth Menon <nm@ti.com>

Bump ? Linux recently started checking for the IBE bit, so it'd be good
to get this applied.

> ---
>  arch/arm/Kconfig           | 5 +++++
>  arch/arm/cpu/armv7/start.S | 7 +++++--
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f6d57f5505ff..c2ac0fef9d0c 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -86,6 +86,8 @@ config THUMB2_KERNEL
>  # CONFIG_ARM_ERRATA_621766
>  # CONFIG_ARM_ERRATA_798870
>  # CONFIG_ARM_ERRATA_801819
> +# CONFIG_ARM_CORTEX_A8_CVE_2017_5715
> +
>  config ARM_ERRATA_430973
>  	bool
>  
> @@ -155,6 +157,9 @@ config ARM_ERRATA_852423
>  config ARM_ERRATA_855873
>  	bool
>  
> +config ARM_CORTEX_A8_CVE_2017_5715
> +	bool
> +
>  config CPU_ARM720T
>  	bool
>  	select SYS_CACHE_SHIFT_5
> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> index 7e2695761e98..64c5d7598dea 100644
> --- a/arch/arm/cpu/armv7/start.S
> +++ b/arch/arm/cpu/armv7/start.S
> @@ -249,12 +249,15 @@ skip_errata_801819:
>  	pop	{r1-r5}			@ Restore the cpu info - fall through
>  #endif
>  
> -#ifdef CONFIG_ARM_ERRATA_430973
> +#if defined(CONFIG_ARM_ERRATA_430973) || defined (CONFIG_ARM_CORTEX_A8_CVE_2017_5715)
>  	mrc	p15, 0, r0, c1, c0, 1	@ Read ACR
>  
> +#ifdef CONFIG_ARM_CORTEX_A8_CVE_2017_5715
> +	orr	r0, r0, #(0x1 << 6)	@ Set IBE bit always to enable OS WA
> +#else
>  	cmp	r2, #0x21		@ Only on < r2p1
>  	orrlt	r0, r0, #(0x1 << 6)	@ Set IBE bit
> -
> +#endif
>  	push	{r1-r5}			@ Save the cpu info registers
>  	bl	v7_arch_cp15_set_acr
>  	pop	{r1-r5}			@ Restore the cpu info - fall through
> 


-- 
Best regards,
Marek Vasut

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Nishanth Menon]

On Tue, May 22, 2018 at 9:05 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Thu, Jan 25, 2018 at 7:45 PM, Nishanth Menon <nm@ti.com> wrote:
>> Hi Folks,
>>
>> This is a follow through on the discussion we have had in [1].
>> This itself is'nt a complete solution and is based on recommendation
>> This from Arm[2] for variant 2 CVE-2017-5715
>>
>> The Linux kernel discussions are spread out in [3], ATF and OPTEE
>> status are available in [4].
>>
>> This is just an RFC series (build tested at this point) to check if
>> the direction is fine and should follow the final solution once kernel
>> patches get to upstream, IMHO.
>>
>> NOTE: As per ARM recommendations[2], and discussions in list[1] ARM
>> Cortex-A9/12/17 do not need additional steps in u-boot to enable the
>> OS level workarounds.
>>
>> Nishanth Menon (2):
>>   ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
>>     CVE-2017-5715
>>   ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for
>>     CVE-2017-5715
>

I started respinning the series, while there is definitely a use of
implementing in u-boot,
I am starting to wonder if we should also be doing this in kernel. ->
following is an example:
for OMAP5uEVM (dual A15) with  next-20180612 -> Uboot does setup the
IBE bit, so the
CPU0 ICIALLU does get activated however, that is not true for CPU1.
Further if we enter low power states, we'd also start loosing the
context, wont we?

Log:

[    0.001484] Calibrating delay loop (skipped), value calculated
using timer frequency.. 12.28 BogoMIPS (lpj=61440)
[    0.001510] pid_max: default: 32768 minimum: 301
[    0.001804] Security Framework initialized
[    0.001907] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.001928] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.004144] CPU: Testing write buffer coherency: ok
[    0.004258] CPU0: Spectre v2: using ICIALLU workaround
[    0.005130] /cpus/cpu at 0 missing clock-frequency property
[    0.005159] /cpus/cpu at 1 missing clock-frequency property
[    0.005178] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.006660] Setting up static identity map for 0x80100000 - 0x80100078
[    0.007036] rcu: Hierarchical SRCU implementation.
[    0.008424] smp: Bringing up secondary CPUs ...
[    0.010557] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.010566] CPU1: Spectre v2: firmware did not set auxiliary
control register IBE bit, system vulnerable
[    0.011162] smp: Brought up 1 node, 2 CPUs
[    0.011181] SMP: Total of 2 processors activated (24.57 BogoMIPS).
[    0.011197] CPU: All CPU(s) started in HYP mode.
[    0.011211] CPU: Virtualization extensions available.
[    0.013729] devtmpfs: initialized
[    0.044497] VFP support v0.3: implementor 41 architecture 4 part 30
variant f rev 0
[    0.046160] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.046201] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.046942] pinctrl core: initialized pinctrl subsystem
[    0.050282] NET: Registered protocol family 16
[    0.054624] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.055930] omap_hwmod: l3_main_3 using broken dt data from ocp
[    0.057244] omap_hwmod: l3_main_2 using broken dt data from ocp
[    0.167706] audit: initializing netlink subsys (disabled)
[    0.168044] audit: type=2000 audit(0.160:1): state=initialized
audit_enabled=0 res=1
[    0.168979] (NULL device *): Failed to create dummy-scm_conf at 0
debugfs directory
[    0.169566] cpuidle: using governor menu
[    0.184644] OMAP GPIO hardware version 0.1


-- 
---
Regards,
Nishanth Menon

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Nishanth Menon]

On Tue, May 22, 2018 at 9:05 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Thu, Jan 25, 2018 at 7:45 PM, Nishanth Menon <nm@ti.com> wrote:
>> Hi Folks,
>>
>> This is a follow through on the discussion we have had in [1].
>> This itself is'nt a complete solution and is based on recommendation
>> This from Arm[2] for variant 2 CVE-2017-5715
>>
>> The Linux kernel discussions are spread out in [3], ATF and OPTEE
>> status are available in [4].
>>
>> This is just an RFC series (build tested at this point) to check if
>> the direction is fine and should follow the final solution once kernel
>> patches get to upstream, IMHO.
>>
>> NOTE: As per ARM recommendations[2], and discussions in list[1] ARM
>> Cortex-A9/12/17 do not need additional steps in u-boot to enable the
>> OS level workarounds.
>>
>> Nishanth Menon (2):
>>   ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
>>     CVE-2017-5715
>>   ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for
>>     CVE-2017-5715
>

I started respinning the series, while there is definitely a use of
implementing in u-boot,
I am starting to wonder if we should also be doing this in kernel. ->
following is an example:
for OMAP5uEVM (dual A15) with  next-20180612 -> Uboot does setup the
IBE bit, so the
CPU0 ICIALLU does get activated however, that is not true for CPU1.
Further if we enter low power states, we'd also start loosing the
context, wont we?

Log:

[    0.001484] Calibrating delay loop (skipped), value calculated
using timer frequency.. 12.28 BogoMIPS (lpj=61440)
[    0.001510] pid_max: default: 32768 minimum: 301
[    0.001804] Security Framework initialized
[    0.001907] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.001928] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.004144] CPU: Testing write buffer coherency: ok
[    0.004258] CPU0: Spectre v2: using ICIALLU workaround
[    0.005130] /cpus/cpu at 0 missing clock-frequency property
[    0.005159] /cpus/cpu at 1 missing clock-frequency property
[    0.005178] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.006660] Setting up static identity map for 0x80100000 - 0x80100078
[    0.007036] rcu: Hierarchical SRCU implementation.
[    0.008424] smp: Bringing up secondary CPUs ...
[    0.010557] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.010566] CPU1: Spectre v2: firmware did not set auxiliary
control register IBE bit, system vulnerable
[    0.011162] smp: Brought up 1 node, 2 CPUs
[    0.011181] SMP: Total of 2 processors activated (24.57 BogoMIPS).
[    0.011197] CPU: All CPU(s) started in HYP mode.
[    0.011211] CPU: Virtualization extensions available.
[    0.013729] devtmpfs: initialized
[    0.044497] VFP support v0.3: implementor 41 architecture 4 part 30
variant f rev 0
[    0.046160] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.046201] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.046942] pinctrl core: initialized pinctrl subsystem
[    0.050282] NET: Registered protocol family 16
[    0.054624] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.055930] omap_hwmod: l3_main_3 using broken dt data from ocp
[    0.057244] omap_hwmod: l3_main_2 using broken dt data from ocp
[    0.167706] audit: initializing netlink subsys (disabled)
[    0.168044] audit: type=2000 audit(0.160:1): state=initialized
audit_enabled=0 res=1
[    0.168979] (NULL device *): Failed to create dummy-scm_conf at 0
debugfs directory
[    0.169566] cpuidle: using governor menu
[    0.184644] OMAP GPIO hardware version 0.1


-- 
---
Regards,
Nishanth Menon

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Russell King - ARM Linux]

On Tue, Jun 12, 2018 at 02:13:38PM -0500, Nishanth Menon wrote:
> On Tue, May 22, 2018 at 9:05 AM, Fabio Estevam <festevam@gmail.com> wrote:
> > On Thu, Jan 25, 2018 at 7:45 PM, Nishanth Menon <nm@ti.com> wrote:
> >> Hi Folks,
> >>
> >> This is a follow through on the discussion we have had in [1].
> >> This itself is'nt a complete solution and is based on recommendation
> >> This from Arm[2] for variant 2 CVE-2017-5715
> >>
> >> The Linux kernel discussions are spread out in [3], ATF and OPTEE
> >> status are available in [4].
> >>
> >> This is just an RFC series (build tested at this point) to check if
> >> the direction is fine and should follow the final solution once kernel
> >> patches get to upstream, IMHO.
> >>
> >> NOTE: As per ARM recommendations[2], and discussions in list[1] ARM
> >> Cortex-A9/12/17 do not need additional steps in u-boot to enable the
> >> OS level workarounds.
> >>
> >> Nishanth Menon (2):
> >>   ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
> >>     CVE-2017-5715
> >>   ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for
> >>     CVE-2017-5715
> >
> 
> I started respinning the series, while there is definitely a use of
> implementing in u-boot,
> I am starting to wonder if we should also be doing this in kernel.

How does the kernel set the bit when the kernel is running in non-secure
mode, when the ACTLR is read-only in that mode?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Russell King - ARM Linux]

On Tue, Jun 12, 2018 at 02:13:38PM -0500, Nishanth Menon wrote:
> On Tue, May 22, 2018 at 9:05 AM, Fabio Estevam <festevam@gmail.com> wrote:
> > On Thu, Jan 25, 2018 at 7:45 PM, Nishanth Menon <nm@ti.com> wrote:
> >> Hi Folks,
> >>
> >> This is a follow through on the discussion we have had in [1].
> >> This itself is'nt a complete solution and is based on recommendation
> >> This from Arm[2] for variant 2 CVE-2017-5715
> >>
> >> The Linux kernel discussions are spread out in [3], ATF and OPTEE
> >> status are available in [4].
> >>
> >> This is just an RFC series (build tested at this point) to check if
> >> the direction is fine and should follow the final solution once kernel
> >> patches get to upstream, IMHO.
> >>
> >> NOTE: As per ARM recommendations[2], and discussions in list[1] ARM
> >> Cortex-A9/12/17 do not need additional steps in u-boot to enable the
> >> OS level workarounds.
> >>
> >> Nishanth Menon (2):
> >>   ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
> >>     CVE-2017-5715
> >>   ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for
> >>     CVE-2017-5715
> >
> 
> I started respinning the series, while there is definitely a use of
> implementing in u-boot,
> I am starting to wonder if we should also be doing this in kernel.

How does the kernel set the bit when the kernel is running in non-secure
mode, when the ACTLR is read-only in that mode?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Nishanth Menon]

On 21:40-20180612, Russell King - ARM Linux wrote:
[...]
> > I started respinning the series, while there is definitely a use of
> > implementing in u-boot,
> > I am starting to wonder if we should also be doing this in kernel.
> 
> How does the kernel set the bit when the kernel is running in non-secure
> mode, when the ACTLR is read-only in that mode?

For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve
it:
https://patchwork.kernel.org/patch/10461273/

This'd be similar in implementation to ARM erratum 801819 workaround
that needs two pieces (u-boot + kernel). I am not really worried about
OMAP5/DRA7 since they should'nt loose context in Low power modes.
Other SoCs need to be aware of the constraints.

/me wishes PSCI was a standard during ARMv7, but it was'nt... So
legacy v7 SoCs have implementations that are kind of different (even
smc calling conventions vary).

-- 
Regards,
Nishanth Menon

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Nishanth Menon]

On 21:40-20180612, Russell King - ARM Linux wrote:
[...]
> > I started respinning the series, while there is definitely a use of
> > implementing in u-boot,
> > I am starting to wonder if we should also be doing this in kernel.
> 
> How does the kernel set the bit when the kernel is running in non-secure
> mode, when the ACTLR is read-only in that mode?

For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve
it:
https://patchwork.kernel.org/patch/10461273/

This'd be similar in implementation to ARM erratum 801819 workaround
that needs two pieces (u-boot + kernel). I am not really worried about
OMAP5/DRA7 since they should'nt loose context in Low power modes.
Other SoCs need to be aware of the constraints.

/me wishes PSCI was a standard during ARMv7, but it was'nt... So
legacy v7 SoCs have implementations that are kind of different (even
smc calling conventions vary).

-- 
Regards,
Nishanth Menon

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Russell King - ARM Linux]

On Tue, Jun 12, 2018 at 04:58:34PM -0500, Nishanth Menon wrote:
> On 21:40-20180612, Russell King - ARM Linux wrote:
> [...]
> > > I started respinning the series, while there is definitely a use of
> > > implementing in u-boot,
> > > I am starting to wonder if we should also be doing this in kernel.
> > 
> > How does the kernel set the bit when the kernel is running in non-secure
> > mode, when the ACTLR is read-only in that mode?
> 
> For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve
> it:
> https://patchwork.kernel.org/patch/10461273/
> 
> This'd be similar in implementation to ARM erratum 801819 workaround
> that needs two pieces (u-boot + kernel). I am not really worried about
> OMAP5/DRA7 since they should'nt loose context in Low power modes.
> Other SoCs need to be aware of the constraints.
> 
> /me wishes PSCI was a standard during ARMv7, but it was'nt... So
> legacy v7 SoCs have implementations that are kind of different (even
> smc calling conventions vary).

It may seem to be an easy way out (do everything in the kernel) but
have you considered that the secure world is also vulnerable?

If the IBE bit is not set in the secure world, then the secure world
is not implementing the workarounds, and therefore the non-secure
world has the possibility to use the Spectre vulnerabilities to
exploit the secure world with enough effort and knowledge.

You really need to _also_ fix these vulnerabilities in the secure
world, which includes setting the IBE bit there.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Russell King - ARM Linux]

On Tue, Jun 12, 2018 at 04:58:34PM -0500, Nishanth Menon wrote:
> On 21:40-20180612, Russell King - ARM Linux wrote:
> [...]
> > > I started respinning the series, while there is definitely a use of
> > > implementing in u-boot,
> > > I am starting to wonder if we should also be doing this in kernel.
> > 
> > How does the kernel set the bit when the kernel is running in non-secure
> > mode, when the ACTLR is read-only in that mode?
> 
> For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve
> it:
> https://patchwork.kernel.org/patch/10461273/
> 
> This'd be similar in implementation to ARM erratum 801819 workaround
> that needs two pieces (u-boot + kernel). I am not really worried about
> OMAP5/DRA7 since they should'nt loose context in Low power modes.
> Other SoCs need to be aware of the constraints.
> 
> /me wishes PSCI was a standard during ARMv7, but it was'nt... So
> legacy v7 SoCs have implementations that are kind of different (even
> smc calling conventions vary).

It may seem to be an easy way out (do everything in the kernel) but
have you considered that the secure world is also vulnerable?

If the IBE bit is not set in the secure world, then the secure world
is not implementing the workarounds, and therefore the non-secure
world has the possibility to use the Spectre vulnerabilities to
exploit the secure world with enough effort and knowledge.

You really need to _also_ fix these vulnerabilities in the secure
world, which includes setting the IBE bit there.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Nishanth Menon]

On 10:08-20180613, Russell King - ARM Linux wrote:
> On Tue, Jun 12, 2018 at 04:58:34PM -0500, Nishanth Menon wrote:
> > On 21:40-20180612, Russell King - ARM Linux wrote:
> > [...]
> > > > I started respinning the series, while there is definitely a use of
> > > > implementing in u-boot,
> > > > I am starting to wonder if we should also be doing this in kernel.
> > > 
> > > How does the kernel set the bit when the kernel is running in non-secure
> > > mode, when the ACTLR is read-only in that mode?
> > 
> > For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve
> > it:
> > https://patchwork.kernel.org/patch/10461273/
> > 
> > This'd be similar in implementation to ARM erratum 801819 workaround
> > that needs two pieces (u-boot + kernel). I am not really worried about
> > OMAP5/DRA7 since they should'nt loose context in Low power modes.
> > Other SoCs need to be aware of the constraints.
> > 
> > /me wishes PSCI was a standard during ARMv7, but it was'nt... So
> > legacy v7 SoCs have implementations that are kind of different (even
> > smc calling conventions vary).
> 
> It may seem to be an easy way out (do everything in the kernel) but
> have you considered that the secure world is also vulnerable?

Yes, we have.

> If the IBE bit is not set in the secure world, then the secure world
> is not implementing the workarounds, and therefore the non-secure
> world has the possibility to use the Spectre vulnerabilities to
> exploit the secure world with enough effort and knowledge.
> 
> You really need to _also_ fix these vulnerabilities in the secure
> world, which includes setting the IBE bit there.

Correct, but, unfortunately, this is NOT always the case / not necessary in
some cases. Example:

On General purpose (GP) devices such as in OMAP, ROM owns the secure APIs,
there is no override of secure world APIs possible. In such cases, we
have to see if there is anything that needs to be protected. in case of
GP devices, there are no secure assets to protect and any SMC calls are
just support services provided by ROM.

a) updating secure side is not possible
b) secure side updates is not necessary since there are no critical run time
   services provided by ROM.

On devices such as Keystone 2 (TI) generation, yes, we do have ability
to update secure side and must be done as well.

-- 
Regards,
Nishanth Menon

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715

[Nishanth Menon]

On 10:08-20180613, Russell King - ARM Linux wrote:
> On Tue, Jun 12, 2018 at 04:58:34PM -0500, Nishanth Menon wrote:
> > On 21:40-20180612, Russell King - ARM Linux wrote:
> > [...]
> > > > I started respinning the series, while there is definitely a use of
> > > > implementing in u-boot,
> > > > I am starting to wonder if we should also be doing this in kernel.
> > > 
> > > How does the kernel set the bit when the kernel is running in non-secure
> > > mode, when the ACTLR is read-only in that mode?
> > 
> > For OMAP5/DRA7 SMP systems, I just posted a patch that seems to resolve
> > it:
> > https://patchwork.kernel.org/patch/10461273/
> > 
> > This'd be similar in implementation to ARM erratum 801819 workaround
> > that needs two pieces (u-boot + kernel). I am not really worried about
> > OMAP5/DRA7 since they should'nt loose context in Low power modes.
> > Other SoCs need to be aware of the constraints.
> > 
> > /me wishes PSCI was a standard during ARMv7, but it was'nt... So
> > legacy v7 SoCs have implementations that are kind of different (even
> > smc calling conventions vary).
> 
> It may seem to be an easy way out (do everything in the kernel) but
> have you considered that the secure world is also vulnerable?

Yes, we have.

> If the IBE bit is not set in the secure world, then the secure world
> is not implementing the workarounds, and therefore the non-secure
> world has the possibility to use the Spectre vulnerabilities to
> exploit the secure world with enough effort and knowledge.
> 
> You really need to _also_ fix these vulnerabilities in the secure
> world, which includes setting the IBE bit there.

Correct, but, unfortunately, this is NOT always the case / not necessary in
some cases. Example:

On General purpose (GP) devices such as in OMAP, ROM owns the secure APIs,
there is no override of secure world APIs possible. In such cases, we
have to see if there is anything that needs to be protected. in case of
GP devices, there are no secure assets to protect and any SMC calls are
just support services provided by ROM.

a) updating secure side is not possible
b) secure side updates is not necessary since there are no critical run time
   services provided by ROM.

On devices such as Keystone 2 (TI) generation, yes, we do have ability
to update secure side and must be done as well.

-- 
Regards,
Nishanth Menon