| Message ID | 20180125214559.27570-1-nm@ti.com |
|---|---|
| Headers | show |
| Series | ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715 | expand |
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?
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@0 missing clock-frequency property [ 0.005159] /cpus/cpu@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@0 debugfs directory [ 0.169566] cpuidle: using governor menu [ 0.184644] OMAP GPIO hardware version 0.1
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?
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).
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.
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.
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/