* Should Linux set the new constant-time mode CPU flags? @ 2022-08-25 23:15 Eric Biggers 2022-08-26 7:23 ` Peter Zijlstra ` (3 more replies) 0 siblings, 4 replies; 14+ messages in thread From: Eric Biggers @ 2022-08-25 23:15 UTC (permalink / raw) To: x86, linux-arm-kernel Cc: linux-crypto, linux-kernel, Adam Langley, Jason A. Donenfeld, Ard Biesheuvel Hi, Intel and ARM recently published documentation that says that no instructions are guaranteed to be constant-time with respect to their data operands, unless a "data independent timing" flag in the IA32_UARCH_MISC_CTL register (Intel) or DIT register (arm64) is set: * https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html * https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Registers/DIT--Data-Independent-Timing This is a major problem for crypto code, which needs to be constant-time, especially with respect to keys. And since this is a CPU issue, it affects all code running on the CPU. While neither company is treating this as a security disclosure, to me this looks exactly like a CPU vulnerability. For Intel, given that the mitigation is to set an MSR flag, it seems that the kernel will need to do that -- similar to the MSR flags that enable mitigations for speculative execution vulnerabilities. For arm64, it's not clear to me whether the DIT flag is privileged or not. If privileged, I expect it would need to be set by the kernel just like the Intel flag. If unprivileged, I expect there will still be work to do in the kernel, as the flag will need to be set when running any crypto code in the kernel. I'm wondering if people are aware of this issue, and whether anyone has any thoughts on whether/where the kernel should be setting these new CPU flags. There don't appear to have been any prior discussions about this. (Thanks to Adam Langley, who maintains BoringSSL, for bringing this to my attention.) - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Should Linux set the new constant-time mode CPU flags? 2022-08-25 23:15 Should Linux set the new constant-time mode CPU flags? Eric Biggers @ 2022-08-26 7:23 ` Peter Zijlstra 2022-08-26 8:45 ` Arnd Bergmann ` (2 subsequent siblings) 3 siblings, 0 replies; 14+ messages in thread From: Peter Zijlstra @ 2022-08-26 7:23 UTC (permalink / raw) To: Eric Biggers Cc: x86, linux-arm-kernel, linux-crypto, linux-kernel, Adam Langley, Jason A. Donenfeld, Ard Biesheuvel On Thu, Aug 25, 2022 at 11:15:58PM +0000, Eric Biggers wrote: > Hi, > > Intel and ARM recently published documentation that says that no instructions > are guaranteed to be constant-time with respect to their data operands, unless a > "data independent timing" flag in the IA32_UARCH_MISC_CTL register (Intel) or > DIT register (arm64) is set: > > * https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html > * https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Registers/DIT--Data-Independent-Timing > > This is a major problem for crypto code, which needs to be constant-time, > especially with respect to keys. And since this is a CPU issue, it affects all > code running on the CPU. While neither company is treating this as a security > disclosure, to me this looks exactly like a CPU vulnerability. > > For Intel, given that the mitigation is to set an MSR flag, it seems that the > kernel will need to do that -- similar to the MSR flags that enable mitigations > for speculative execution vulnerabilities. > > For arm64, it's not clear to me whether the DIT flag is privileged or not. If > privileged, I expect it would need to be set by the kernel just like the Intel > flag. If unprivileged, I expect there will still be work to do in the kernel, > as the flag will need to be set when running any crypto code in the kernel. > > I'm wondering if people are aware of this issue, and whether anyone has any > thoughts on whether/where the kernel should be setting these new CPU flags. > There don't appear to have been any prior discussions about this. (Thanks to > Adam Langley, who maintains BoringSSL, for bringing this to my attention.) Whichever way around I think you want OS support to make it a per-task property instead of a per CPU one. Also, *sigh* yet another MSR to touch :/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Should Linux set the new constant-time mode CPU flags? 2022-08-25 23:15 Should Linux set the new constant-time mode CPU flags? Eric Biggers 2022-08-26 7:23 ` Peter Zijlstra @ 2022-08-26 8:45 ` Arnd Bergmann 2022-09-15 17:18 ` Catalin Marinas 2022-08-26 15:40 ` Jeffrey Walton 2022-08-29 16:39 ` Jason A. Donenfeld 3 siblings, 1 reply; 14+ messages in thread From: Arnd Bergmann @ 2022-08-26 8:45 UTC (permalink / raw) To: Eric Biggers Cc: x86, linux-arm-kernel, linux-crypto, linux-kernel, Adam Langley, Jason A. Donenfeld, Ard Biesheuvel On Fri, Aug 26, 2022 at 1:15 AM Eric Biggers <ebiggers@kernel.org> wrote: > > For arm64, it's not clear to me whether the DIT flag is privileged or not. If > privileged, I expect it would need to be set by the kernel just like the Intel > flag. If unprivileged, I expect there will still be work to do in the kernel, > as the flag will need to be set when running any crypto code in the kernel. 7206dc93a58f ("arm64: Expose Arm v8.4 features") added the feature bit for Armv8.4+ processors. From what I can tell from the documentation and the kernel source, I see: - if the feature is set in HWCAP (or /proc/cpuinfo), then the instruction DIT register is available in user space, and sensitive code can set or clear the constant-time mode for the local thread. - On CPUs without the feature (almost all ARMv8 ones), the register should not be touched. - The bit is context switched on kernel entry, so setting the bit in user space does not change the behavior inside of a syscall - If we add a user space interface for setting the bit per thread on x86, the same interface could be supported to set the bit on arm64 to save user space implementations the trouble of checking the feature bits - the in-kernel crypto code does not set the bit today but could be easily changed to do this for CPUs that support it, if we can decide on a policy for when to enable or disable it. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Should Linux set the new constant-time mode CPU flags? 2022-08-26 8:45 ` Arnd Bergmann @ 2022-09-15 17:18 ` Catalin Marinas 0 siblings, 0 replies; 14+ messages in thread From: Catalin Marinas @ 2022-09-15 17:18 UTC (permalink / raw) To: Arnd Bergmann Cc: Eric Biggers, x86, linux-arm-kernel, linux-crypto, linux-kernel, Adam Langley, Jason A. Donenfeld, Ard Biesheuvel (catching up with this thread) On Fri, Aug 26, 2022 at 10:45:07AM +0200, Arnd Bergmann wrote: > On Fri, Aug 26, 2022 at 1:15 AM Eric Biggers <ebiggers@kernel.org> wrote: > > For arm64, it's not clear to me whether the DIT flag is privileged or not. If > > privileged, I expect it would need to be set by the kernel just like the Intel > > flag. If unprivileged, I expect there will still be work to do in the kernel, > > as the flag will need to be set when running any crypto code in the kernel. > > 7206dc93a58f ("arm64: Expose Arm v8.4 features") added the feature bit for > Armv8.4+ processors. From what I can tell from the documentation and the > kernel source, I see: > > - if the feature is set in HWCAP (or /proc/cpuinfo), then the instruction DIT > register is available in user space, and sensitive code can set or clear the > constant-time mode for the local thread. Indeed, the arm64 DIT feature can be enabled in user space, subject to checking the HWCAP bit or the CPUID regs (via kernel trapping and emulation). The expectation was that some crypto routines would set it on function entry, restore it on return but... > - On CPUs without the feature (almost all ARMv8 ones), the register should > not betouched. That's one of the drawbacks of using the features in user-space (the instruction is not in the hint/nop space). It can be worked around with ifunc resolvers but with a slight overhead on function calling. > - The bit is context switched on kernel entry, so setting the bit in user space > does not change the behavior inside of a syscall > - If we add a user space interface for setting the bit per thread on x86, > the same interface could be supported to set the bit on arm64 to save > user space implementations the trouble of checking the feature bits A prctl() would do here but I think the default should be off or at least allow a sysctl to control this. Enabling DIT could have a small performance impact while lots of (most?) apps don't need such guarantees. For arm64, my preference is to have this option per-thread and even be able to toggle it within a thread (not sure that's possible on x86 without a syscall). Other random ideas of deploying this (for arm64): have an ELF annotation that data independent timing is required. If that's on the main executable, the kernel could turn it on for the app. If it's on a (crypto) library, it's up to the dynamic loader to either turn it on for the whole app or just use some function veneers to save/restore it when the library code is executed. I assume having this per-thread would work on x86 as well but I'm not sure about the context switching cost. > - the in-kernel crypto code does not set the bit today but could be easily > changed to do this for CPUs that support it, if we can decide on a policy > for when to enable or disable it. In the kernel it's easier, at least for arm64, to enable it for specific functions (we can do boot-time code patching). Whichever way we support it, I'd rather not turn it on by default. Talking to some of the Arm microarchitects, such feature may prevent certain hardware optimisations. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Should Linux set the new constant-time mode CPU flags? 2022-08-25 23:15 Should Linux set the new constant-time mode CPU flags? Eric Biggers 2022-08-26 7:23 ` Peter Zijlstra 2022-08-26 8:45 ` Arnd Bergmann @ 2022-08-26 15:40 ` Jeffrey Walton 2022-08-29 16:39 ` Jason A. Donenfeld 3 siblings, 0 replies; 14+ messages in thread From: Jeffrey Walton @ 2022-08-26 15:40 UTC (permalink / raw) To: Eric Biggers Cc: X86 ML, Linux ARM, Linux Crypto Mailing List, LKML, Adam Langley, Jason A. Donenfeld, Ard Biesheuvel On Thu, Aug 25, 2022 at 7:24 PM Eric Biggers <ebiggers@kernel.org> wrote: > > Hi, > > Intel and ARM recently published documentation that says that no instructions > are guaranteed to be constant-time with respect to their data operands, unless a > "data independent timing" flag in the IA32_UARCH_MISC_CTL register (Intel) or > DIT register (arm64) is set: > > * https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html > * https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Registers/DIT--Data-Independent-Timing > > This is a major problem for crypto code, which needs to be constant-time, > especially with respect to keys. And since this is a CPU issue, it affects all > code running on the CPU. While neither company is treating this as a security > disclosure, to me this looks exactly like a CPU vulnerability. > > For Intel, given that the mitigation is to set an MSR flag, it seems that the > kernel will need to do that -- similar to the MSR flags that enable mitigations > for speculative execution vulnerabilities. > > For arm64, it's not clear to me whether the DIT flag is privileged or not. If > privileged, I expect it would need to be set by the kernel just like the Intel > flag. If unprivileged, I expect there will still be work to do in the kernel, > as the flag will need to be set when running any crypto code in the kernel. > > I'm wondering if people are aware of this issue, and whether anyone has any > thoughts on whether/where the kernel should be setting these new CPU flags. > There don't appear to have been any prior discussions about this. (Thanks to > Adam Langley, who maintains BoringSSL, for bringing this to my attention.) The thought that comes to mind for me is, please make setting/clearing the bit available in userland. Libraries like Botan, Crypto++ and OpenSSL could benefit from it. Jeff _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Should Linux set the new constant-time mode CPU flags? 2022-08-25 23:15 Should Linux set the new constant-time mode CPU flags? Eric Biggers ` (2 preceding siblings ...) 2022-08-26 15:40 ` Jeffrey Walton @ 2022-08-29 16:39 ` Jason A. Donenfeld 2022-08-29 18:08 ` Eric Biggers ` (2 more replies) 3 siblings, 3 replies; 14+ messages in thread From: Jason A. Donenfeld @ 2022-08-29 16:39 UTC (permalink / raw) To: Eric Biggers Cc: x86, linux-arm-kernel, linux-crypto, linux-kernel, Adam Langley, Ard Biesheuvel Hi Eric, On Thu, Aug 25, 2022 at 11:15:58PM +0000, Eric Biggers wrote: > I'm wondering if people are aware of this issue, and whether anyone has any > thoughts on whether/where the kernel should be setting these new CPU flags. > There don't appear to have been any prior discussions about this. (Thanks to Maybe it should be set unconditionally now, until we figure out how to make it more granular. In terms of granularity, I saw other folks suggesting making it per-task (so, presumably, a prctl() knob), and others mentioning doing it just for kernel crypto. For the latter, I guess the crypto API could set it inside of its abstractions, and the various lib/crypto APIs could set it at invocation time. I wonder, though, what's the cost of enabling/disabling it? Would we in fact need a kind of lazy-deferred disabling, like we have with kernel_fpu_end()? I also wonder what crypto-adjacent code might wind up being missed if we're going function by function. Like, obviously we'd set this for crypto_memneq, but what about potential unprotected `==` of ID numbers that could leak some info in various protocols? What other subtle nearby code should we be thinking about, that relies on constant time logic but isn't neatly folded inside a crypto_do_something() function? Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Should Linux set the new constant-time mode CPU flags? 2022-08-29 16:39 ` Jason A. Donenfeld @ 2022-08-29 18:08 ` Eric Biggers 2022-08-29 19:09 ` Jason A. Donenfeld 2022-08-29 19:05 ` Jason A. Donenfeld 2022-08-30 14:25 ` Dave Hansen 2 siblings, 1 reply; 14+ messages in thread From: Eric Biggers @ 2022-08-29 18:08 UTC (permalink / raw) To: Jason A. Donenfeld Cc: x86, linux-arm-kernel, linux-crypto, linux-kernel, Adam Langley, Ard Biesheuvel On Mon, Aug 29, 2022 at 12:39:53PM -0400, Jason A. Donenfeld wrote: > Hi Eric, > > On Thu, Aug 25, 2022 at 11:15:58PM +0000, Eric Biggers wrote: > > I'm wondering if people are aware of this issue, and whether anyone has any > > thoughts on whether/where the kernel should be setting these new CPU flags. > > There don't appear to have been any prior discussions about this. (Thanks to > > Maybe it should be set unconditionally now, until we figure out how to > make it more granular. > > In terms of granularity, I saw other folks suggesting making it per-task > (so, presumably, a prctl() knob), and others mentioning doing it just > for kernel crypto. For the latter, I guess the crypto API could set it > inside of its abstractions, and the various lib/crypto APIs could set it > at invocation time. I wonder, though, what's the cost of > enabling/disabling it? Would we in fact need a kind of lazy-deferred > disabling, like we have with kernel_fpu_end()? I also wonder what > crypto-adjacent code might wind up being missed if we're going function > by function. Like, obviously we'd set this for crypto_memneq, but what > about potential unprotected `==` of ID numbers that could leak some info > in various protocols? What other subtle nearby code should we be > thinking about, that relies on constant time logic but isn't neatly > folded inside a crypto_do_something() function? > I'd much prefer it being set unconditionally by default as well, as making everyone (both kernel and userspace) turn it on and off constantly would be a nightmare. Note that Intel's documentation says that CPUs before Ice Lake behave as if DOITM is always set: "For Intel® Core™ family processors based on microarchitectures before Ice Lake and Intel Atom® family processors based on microarchitectures before Gracemont that do not enumerate IA32_UARCH_MISC_CTL, developers may assume that the instructions listed here operate as if DOITM is enabled." (It's a bit ambiguous, as it leaves the door open to IA32_UARCH_MISC_CTL being retroactively added to old CPUs. But I assume that hasn't actually happened.) So I think the logical approach is to unconditionally set DOITM by default, to fix this CPU bug in Ice Lake and later and just bring things back to the way they were in CPUs before Ice Lake. With that as a baseline, we can then discuss whether it's useful to provide ways to re-enable this CPU bug / "feature", for people who want to get the performance boost (if one actually exists) of data dependent timing after carefully assessing the risks. The other way around, of making everything insecure by default, seems like a really bad idea. - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Should Linux set the new constant-time mode CPU flags? 2022-08-29 18:08 ` Eric Biggers @ 2022-08-29 19:09 ` Jason A. Donenfeld 0 siblings, 0 replies; 14+ messages in thread From: Jason A. Donenfeld @ 2022-08-29 19:09 UTC (permalink / raw) To: Eric Biggers Cc: x86, linux-arm-kernel, linux-crypto, linux-kernel, Adam Langley, Ard Biesheuvel On Mon, Aug 29, 2022 at 06:08:07PM +0000, Eric Biggers wrote: > I'd much prefer it being set unconditionally by default as well, as making > everyone (both kernel and userspace) turn it on and off constantly would be a > nightmare. > > Note that Intel's documentation says that CPUs before Ice Lake behave as if > DOITM is always set: > > "For Intel® Core™ family processors based on microarchitectures before Ice > Lake and Intel Atom® family processors based on microarchitectures before > Gracemont that do not enumerate IA32_UARCH_MISC_CTL, developers may assume > that the instructions listed here operate as if DOITM is enabled." > > (It's a bit ambiguous, as it leaves the door open to IA32_UARCH_MISC_CTL being > retroactively added to old CPUs. But I assume that hasn't actually happened.) > > So I think the logical approach is to unconditionally set DOITM by default, to > fix this CPU bug in Ice Lake and later and just bring things back to the way > they were in CPUs before Ice Lake. With that as a baseline, we can then discuss > whether it's useful to provide ways to re-enable this CPU bug / "feature", for > people who want to get the performance boost (if one actually exists) of data > dependent timing after carefully assessing the risks. > > The other way around, of making everything insecure by default, seems like a > really bad idea. Right. It's actually kind of surprising that Intel didn't already do this by default. Sure, maybe the Intel manual never explicitly guaranteed constant time, but a heck of a lot of code relies on that being the case. Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Should Linux set the new constant-time mode CPU flags? 2022-08-29 16:39 ` Jason A. Donenfeld 2022-08-29 18:08 ` Eric Biggers @ 2022-08-29 19:05 ` Jason A. Donenfeld 2022-08-30 14:25 ` Dave Hansen 2 siblings, 0 replies; 14+ messages in thread From: Jason A. Donenfeld @ 2022-08-29 19:05 UTC (permalink / raw) To: Eric Biggers Cc: x86, linux-arm-kernel, linux-crypto, linux-kernel, Adam Langley, Ard Biesheuvel On Mon, Aug 29, 2022 at 12:39:53PM -0400, Jason A. Donenfeld wrote: > In terms of granularity, I saw other folks suggesting making it per-task > (so, presumably, a prctl() knob), and others mentioning doing it just > for kernel crypto. For the latter, I guess the crypto API could set it > inside of its abstractions, and the various lib/crypto APIs could set it > at invocation time. I wonder, though, what's the cost of > enabling/disabling it? Would we in fact need a kind of lazy-deferred > disabling, like we have with kernel_fpu_end()? I also wonder what > crypto-adjacent code might wind up being missed if we're going function > by function. Like, obviously we'd set this for crypto_memneq, but what > about potential unprotected `==` of ID numbers that could leak some info > in various protocols? What other subtle nearby code should we be > thinking about, that relies on constant time logic but isn't neatly > folded inside a crypto_do_something() function? Another random note on this: I would hope that setting that MSR represents a speculation barrier or general instruction stream barrier, so that you can't do something naughty with the scheduler to toggle it rapidly and measure crypto timings somehow. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Should Linux set the new constant-time mode CPU flags? 2022-08-29 16:39 ` Jason A. Donenfeld 2022-08-29 18:08 ` Eric Biggers 2022-08-29 19:05 ` Jason A. Donenfeld @ 2022-08-30 14:25 ` Dave Hansen 2022-09-01 11:00 ` Peter Zijlstra 2022-09-15 17:52 ` Catalin Marinas 2 siblings, 2 replies; 14+ messages in thread From: Dave Hansen @ 2022-08-30 14:25 UTC (permalink / raw) To: Jason A. Donenfeld, Eric Biggers Cc: x86, linux-arm-kernel, linux-crypto, linux-kernel, Adam Langley, Ard Biesheuvel On 8/29/22 09:39, Jason A. Donenfeld wrote: > On Thu, Aug 25, 2022 at 11:15:58PM +0000, Eric Biggers wrote: >> I'm wondering if people are aware of this issue, and whether anyone has any >> thoughts on whether/where the kernel should be setting these new CPU flags. >> There don't appear to have been any prior discussions about this. (Thanks to > Maybe it should be set unconditionally now, until we figure out how to > make it more granular. Personally, I'm in this camp as well. Let's be safe and set it by default. There's also this tidbit in the Intel docs (and chopping out a bunch of the noise): (On) processors based on microarchitectures before Ice Lake ... the instructions listed here operate as if DOITM is enabled. IOW, setting DOITM=0 isn't going back to the stone age. At worst, I'd guess that you're giving up some optimization that only shows up in very recent CPUs in the first place. If folks want DOITM=1 on their snazzy new CPUs, then they came come with performance data to demonstrate the gain they'll get from adding kernel code to get DOITM=1. There are a range of ways we could handle it, all the way from adding a command-line parameter to per-task management. Anybody disagree? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Should Linux set the new constant-time mode CPU flags? 2022-08-30 14:25 ` Dave Hansen @ 2022-09-01 11:00 ` Peter Zijlstra 2022-10-25 5:06 ` Eric Biggers 2022-09-15 17:52 ` Catalin Marinas 1 sibling, 1 reply; 14+ messages in thread From: Peter Zijlstra @ 2022-09-01 11:00 UTC (permalink / raw) To: Dave Hansen Cc: Jason A. Donenfeld, Eric Biggers, x86, linux-arm-kernel, linux-crypto, linux-kernel, Adam Langley, Ard Biesheuvel On Tue, Aug 30, 2022 at 07:25:29AM -0700, Dave Hansen wrote: > On 8/29/22 09:39, Jason A. Donenfeld wrote: > > On Thu, Aug 25, 2022 at 11:15:58PM +0000, Eric Biggers wrote: > >> I'm wondering if people are aware of this issue, and whether anyone has any > >> thoughts on whether/where the kernel should be setting these new CPU flags. > >> There don't appear to have been any prior discussions about this. (Thanks to > > Maybe it should be set unconditionally now, until we figure out how to > > make it more granular. > > Personally, I'm in this camp as well. Let's be safe and set it by > default. There's also this tidbit in the Intel docs (and chopping out a > bunch of the noise): > > (On) processors based on microarchitectures before Ice Lake ... > the instructions listed here operate as if DOITM is enabled. > > IOW, setting DOITM=0 isn't going back to the stone age. At worst, I'd > guess that you're giving up some optimization that only shows up in very > recent CPUs in the first place. > > If folks want DOITM=1 on their snazzy new CPUs, then they came come with > performance data to demonstrate the gain they'll get from adding kernel > code to get DOITM=1. There are a range of ways we could handle it, all > the way from adding a command-line parameter to per-task management. > > Anybody disagree? Since I'm not feeling too well I figured I'd do something trivial and whipped up the below patch. --- arch/x86/include/asm/cpufeatures.h | 3 ++ arch/x86/include/asm/msr-index.h | 4 +++ arch/x86/kernel/cpu/common.c | 69 ++++++++++++++++++++++++++++++-------- arch/x86/kernel/cpu/scattered.c | 1 + 4 files changed, 63 insertions(+), 14 deletions(-) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index 333d94394516..9b92f4e5e80a 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -305,6 +305,7 @@ #define X86_FEATURE_USE_IBPB_FW (11*32+16) /* "" Use IBPB during runtime firmware calls */ #define X86_FEATURE_RSB_VMEXIT_LITE (11*32+17) /* "" Fill RSB on VM exit when EIBRS is enabled */ #define X86_FEATURE_CALL_DEPTH (11*32+18) /* "" Call depth tracking for RSB stuffing */ +#define X86_FEATURE_MCDT_NO (11*32+19) /* Not affected by MCDT */ /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */ #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* AVX VNNI instructions */ @@ -460,5 +461,7 @@ #define X86_BUG_MMIO_STALE_DATA X86_BUG(25) /* CPU is affected by Processor MMIO Stale Data vulnerabilities */ #define X86_BUG_RETBLEED X86_BUG(26) /* CPU is affected by RETBleed */ #define X86_BUG_EIBRS_PBRSB X86_BUG(27) /* EIBRS is vulnerable to Post Barrier RSB Predictions */ +#define X86_BUG_DOIT X86_BUG(28) +#define X86_BUG_MCDT X86_BUG(29) #endif /* _ASM_X86_CPUFEATURES_H */ diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h index 6674bdb096f3..08b4e0c2f7d3 100644 --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -119,6 +119,7 @@ * Not susceptible to * TSX Async Abort (TAA) vulnerabilities. */ +#define ARCH_CAP_DOIT BIT(12) /* Data Operand Independent Timing */ #define ARCH_CAP_SBDR_SSDP_NO BIT(13) /* * Not susceptible to SBDR and SSDP * variants of Processor MMIO stale data @@ -155,6 +156,9 @@ * Return Stack Buffer Predictions. */ +#define MSR_IA32_UARCH_MISC_CTL 0x00001b01 +#define UARCH_MISC_DOIT BIT(0) /* Enable DOIT */ + #define MSR_IA32_FLUSH_CMD 0x0000010b #define L1D_FLUSH BIT(0) /* * Writeback and invalidate the diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 28eba74b93de..e9d5bc870696 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -568,6 +568,30 @@ static __init int setup_disable_pku(char *arg) __setup("nopku", setup_disable_pku); #endif /* CONFIG_X86_64 */ +static bool doit_disabled = false; + +static __init int setup_disable_doit(char *arg) +{ + pr_info("x86: 'nodoit' specified, not enabling Data Operand Independent Timing\n"); + doit_disabled = true; + return 1; +} +__setup("nodoit", setup_disable_doit); + +static __always_inline void setup_doit(struct cpuinfo_x86 *c) +{ + u64 msr = 0; + + if (!cpu_has(c, X86_BUG_DOIT)) + return; + + if (!doit_disabled) + return; + + rdmsrl(MSR_IA32_UARCH_MISC_CTL, msr); + wrmsrl(MSR_IA32_UARCH_MISC_CTL, msr | UARCH_MISC_DOIT); +} + #ifdef CONFIG_X86_KERNEL_IBT __noendbr u64 ibt_save(void) @@ -1249,6 +1273,8 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = { #define MMIO_SBDS BIT(2) /* CPU is affected by RETbleed, speculating where you would not expect it */ #define RETBLEED BIT(3) +/* CPU might be affected by MXCSR Configuration Dependent Timing (MCDT) */ +#define MCDT BIT(4) static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = { VULNBL_INTEL_STEPPINGS(IVYBRIDGE, X86_STEPPING_ANY, SRBDS), @@ -1260,20 +1286,26 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = { VULNBL_INTEL_STEPPINGS(BROADWELL_G, X86_STEPPING_ANY, SRBDS), VULNBL_INTEL_STEPPINGS(BROADWELL_X, X86_STEPPING_ANY, MMIO), VULNBL_INTEL_STEPPINGS(BROADWELL, X86_STEPPING_ANY, SRBDS), - VULNBL_INTEL_STEPPINGS(SKYLAKE_L, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED), - VULNBL_INTEL_STEPPINGS(SKYLAKE_X, X86_STEPPING_ANY, MMIO | RETBLEED), - VULNBL_INTEL_STEPPINGS(SKYLAKE, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED), - VULNBL_INTEL_STEPPINGS(KABYLAKE_L, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED), - VULNBL_INTEL_STEPPINGS(KABYLAKE, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED), - VULNBL_INTEL_STEPPINGS(CANNONLAKE_L, X86_STEPPING_ANY, RETBLEED), - VULNBL_INTEL_STEPPINGS(ICELAKE_L, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), - VULNBL_INTEL_STEPPINGS(ICELAKE_D, X86_STEPPING_ANY, MMIO), - VULNBL_INTEL_STEPPINGS(ICELAKE_X, X86_STEPPING_ANY, MMIO), - VULNBL_INTEL_STEPPINGS(COMETLAKE, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), - VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x0, 0x0), MMIO | RETBLEED), - VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), - VULNBL_INTEL_STEPPINGS(LAKEFIELD, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), - VULNBL_INTEL_STEPPINGS(ROCKETLAKE, X86_STEPPING_ANY, MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(SKYLAKE_L, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED | MCDT), + VULNBL_INTEL_STEPPINGS(SKYLAKE_X, X86_STEPPING_ANY, MMIO | RETBLEED | MCDT), + VULNBL_INTEL_STEPPINGS(SKYLAKE, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED | MCDT), + VULNBL_INTEL_STEPPINGS(KABYLAKE_L, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED | MCDT), + VULNBL_INTEL_STEPPINGS(KABYLAKE, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED | MCDT), + VULNBL_INTEL_STEPPINGS(CANNONLAKE_L, X86_STEPPING_ANY, RETBLEED | MCDT), + VULNBL_INTEL_STEPPINGS(ICELAKE_L, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED | MCDT), + VULNBL_INTEL_STEPPINGS(ICELAKE_D, X86_STEPPING_ANY, MMIO | MCDT), + VULNBL_INTEL_STEPPINGS(ICELAKE_X, X86_STEPPING_ANY, MMIO | MCDT), + VULNBL_INTEL_STEPPINGS(COMETLAKE, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED | MCDT), + VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x0, 0x0), MMIO | RETBLEED | MCDT), + VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED | MCDT), + VULNBL_INTEL_STEPPINGS(LAKEFIELD, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED | MCDT), + VULNBL_INTEL_STEPPINGS(ROCKETLAKE, X86_STEPPING_ANY, MMIO | RETBLEED | MCDT), + VULNBL_INTEL_STEPPINGS(TIGERLAKE, X86_STEPPING_ANY, MCDT), + VULNBL_INTEL_STEPPINGS(TIGERLAKE_L, X86_STEPPING_ANY, MCDT), + VULNBL_INTEL_STEPPINGS(ALDERLAKE, X86_STEPPING_ANY, MCDT), + VULNBL_INTEL_STEPPINGS(ALDERLAKE_L, X86_STEPPING_ANY, MCDT), + VULNBL_INTEL_STEPPINGS(ALDERLAKE_N, X86_STEPPING_ANY, MCDT), + VULNBL_INTEL_STEPPINGS(ATOM_TREMONT, X86_STEPPING_ANY, MMIO | MMIO_SBDS), VULNBL_INTEL_STEPPINGS(ATOM_TREMONT_D, X86_STEPPING_ANY, MMIO), VULNBL_INTEL_STEPPINGS(ATOM_TREMONT_L, X86_STEPPING_ANY, MMIO | MMIO_SBDS), @@ -1318,6 +1350,9 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c) !(ia32_cap & ARCH_CAP_PSCHANGE_MC_NO)) setup_force_cpu_bug(X86_BUG_ITLB_MULTIHIT); + if (ia32_cap & ARCH_CAP_DOIT) + setup_force_cpu_bug(X86_BUG_DOIT); + if (cpu_matches(cpu_vuln_whitelist, NO_SPECULATION)) return; @@ -1388,6 +1423,11 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c) setup_force_cpu_bug(X86_BUG_RETBLEED); } + if (!cpu_has(c, X86_FEATURE_MCDT_NO)) { + if (cpu_matches(cpu_vuln_blacklist, MCDT)) + setup_force_cpu_bug(X86_BUG_MCDT); + } + if (cpu_has(c, X86_FEATURE_IBRS_ENHANCED) && !cpu_matches(cpu_vuln_whitelist, NO_EIBRS_PBRSB) && !(ia32_cap & ARCH_CAP_PBRSB_NO)) @@ -1869,6 +1909,7 @@ static void identify_cpu(struct cpuinfo_x86 *c) x86_init_rdrand(c); setup_pku(c); setup_cet(c); + setup_doit(c); /* * Clear/Set all flags overridden by options, need do it diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c index fd44b54c90d5..5063f8046554 100644 --- a/arch/x86/kernel/cpu/scattered.c +++ b/arch/x86/kernel/cpu/scattered.c @@ -27,6 +27,7 @@ static const struct cpuid_bit cpuid_bits[] = { { X86_FEATURE_APERFMPERF, CPUID_ECX, 0, 0x00000006, 0 }, { X86_FEATURE_EPB, CPUID_ECX, 3, 0x00000006, 0 }, { X86_FEATURE_INTEL_PPIN, CPUID_EBX, 0, 0x00000007, 1 }, + { X86_FEATURE_MCDT_NO, CPUID_ECX, 5, 0x00000007, 2 }, { X86_FEATURE_RRSBA_CTRL, CPUID_EDX, 2, 0x00000007, 2 }, { X86_FEATURE_CQM_LLC, CPUID_EDX, 1, 0x0000000f, 0 }, { X86_FEATURE_CQM_OCCUP_LLC, CPUID_EDX, 0, 0x0000000f, 1 }, _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: Should Linux set the new constant-time mode CPU flags? 2022-09-01 11:00 ` Peter Zijlstra @ 2022-10-25 5:06 ` Eric Biggers 0 siblings, 0 replies; 14+ messages in thread From: Eric Biggers @ 2022-10-25 5:06 UTC (permalink / raw) To: Peter Zijlstra Cc: Dave Hansen, Jason A. Donenfeld, x86, linux-arm-kernel, linux-crypto, linux-kernel, Adam Langley, Ard Biesheuvel On Thu, Sep 01, 2022 at 01:00:29PM +0200, Peter Zijlstra wrote: > Since I'm not feeling too well I figured I'd do something trivial and > whipped up the below patch. > > > --- > arch/x86/include/asm/cpufeatures.h | 3 ++ > arch/x86/include/asm/msr-index.h | 4 +++ > arch/x86/kernel/cpu/common.c | 69 ++++++++++++++++++++++++++++++-------- > arch/x86/kernel/cpu/scattered.c | 1 + > 4 files changed, 63 insertions(+), 14 deletions(-) We still need to do something about this. As this thread died out, I'll revive it by reviewing this patch. (I'm not an expert in arch/x86/ stuff, though!) > diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h > index 333d94394516..9b92f4e5e80a 100644 > --- a/arch/x86/include/asm/cpufeatures.h > +++ b/arch/x86/include/asm/cpufeatures.h > @@ -305,6 +305,7 @@ > #define X86_FEATURE_USE_IBPB_FW (11*32+16) /* "" Use IBPB during runtime firmware calls */ > #define X86_FEATURE_RSB_VMEXIT_LITE (11*32+17) /* "" Fill RSB on VM exit when EIBRS is enabled */ > #define X86_FEATURE_CALL_DEPTH (11*32+18) /* "" Call depth tracking for RSB stuffing */ > +#define X86_FEATURE_MCDT_NO (11*32+19) /* Not affected by MCDT */ Some of the other CPU feature flags have comments beginning with "", which apparently results in the feature not being listed in /proc/cpuinfo. (This header file is run through a shell script that looks at these comments and generates C code...) Should this "feature" be listed in /proc/cpuinfo? Looking for examples of other "feature" flags that mean that a CPU is not vulnerable to something, I found X86_FEATURE_AMD_SSB_NO and X86_FEATURE_BTC_NO. Those aren't listed in /proc/cpuinfo. Maybe this should be the same? Side note: maybe the comment should spell out "MXCSR Configuration Dependent Timing"? Acronyms can be hard to read. > +#define X86_BUG_DOIT X86_BUG(28) Maybe it should be X86_BUG_DODT? The bug is data operand *dependent* timing. Data operand *independent* timing is the desired behavior and the fix. > +#define X86_BUG_MCDT X86_BUG(29) According to Intel's documentation (https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html), MCDT is a separate bug which requires a separate mitigation. So I think any MCDT related stuff should be in a separate patch from DOITM. But more importantly, this patch doesn't actually implement any mitigation for MCDT. Should we be doing that? Intel recommends writing a certain value to MXCSR to mitigate MCDT. Is that feasible? > > #endif /* _ASM_X86_CPUFEATURES_H */ > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h > index 6674bdb096f3..08b4e0c2f7d3 100644 > --- a/arch/x86/include/asm/msr-index.h > +++ b/arch/x86/include/asm/msr-index.h > @@ -119,6 +119,7 @@ > * Not susceptible to > * TSX Async Abort (TAA) vulnerabilities. > */ > +#define ARCH_CAP_DOIT BIT(12) /* Data Operand Independent Timing */ > #define ARCH_CAP_SBDR_SSDP_NO BIT(13) /* > * Not susceptible to SBDR and SSDP > * variants of Processor MMIO stale data > @@ -155,6 +156,9 @@ > * Return Stack Buffer Predictions. > */ > > +#define MSR_IA32_UARCH_MISC_CTL 0x00001b01 > +#define UARCH_MISC_DOIT BIT(0) /* Enable DOIT */ The Intel documentation calls this bit "DOITM" (Data Operand Independent Timing Mode), not "DOIT". > +static __always_inline void setup_doit(struct cpuinfo_x86 *c) > +{ > + u64 msr = 0; > + > + if (!cpu_has(c, X86_BUG_DOIT)) > + return; > + > + if (!doit_disabled) > + return; This is backwards; it needs to be 'if (doit_disabled)'. > diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c > index fd44b54c90d5..5063f8046554 100644 > --- a/arch/x86/kernel/cpu/scattered.c > +++ b/arch/x86/kernel/cpu/scattered.c > @@ -27,6 +27,7 @@ static const struct cpuid_bit cpuid_bits[] = { > { X86_FEATURE_APERFMPERF, CPUID_ECX, 0, 0x00000006, 0 }, > { X86_FEATURE_EPB, CPUID_ECX, 3, 0x00000006, 0 }, > { X86_FEATURE_INTEL_PPIN, CPUID_EBX, 0, 0x00000007, 1 }, > + { X86_FEATURE_MCDT_NO, CPUID_ECX, 5, 0x00000007, 2 }, The Intel documentation says this bit is CPUID.(EAX=7H,ECX=2):EDX[5]=1. So CPUID_ECX is wrong; it needs to be CPUID_EDX. - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Should Linux set the new constant-time mode CPU flags? 2022-08-30 14:25 ` Dave Hansen 2022-09-01 11:00 ` Peter Zijlstra @ 2022-09-15 17:52 ` Catalin Marinas 2022-10-26 17:01 ` Ard Biesheuvel 1 sibling, 1 reply; 14+ messages in thread From: Catalin Marinas @ 2022-09-15 17:52 UTC (permalink / raw) To: Dave Hansen Cc: Jason A. Donenfeld, Eric Biggers, x86, linux-arm-kernel, linux-crypto, linux-kernel, Adam Langley, Ard Biesheuvel On Tue, Aug 30, 2022 at 07:25:29AM -0700, Dave Hansen wrote: > On 8/29/22 09:39, Jason A. Donenfeld wrote: > > On Thu, Aug 25, 2022 at 11:15:58PM +0000, Eric Biggers wrote: > >> I'm wondering if people are aware of this issue, and whether anyone has any > >> thoughts on whether/where the kernel should be setting these new CPU flags. > >> There don't appear to have been any prior discussions about this. (Thanks to > > Maybe it should be set unconditionally now, until we figure out how to > > make it more granular. > > Personally, I'm in this camp as well. Let's be safe and set it by > default. There's also this tidbit in the Intel docs (and chopping out a > bunch of the noise): > > (On) processors based on microarchitectures before Ice Lake ... > the instructions listed here operate as if DOITM is enabled. > > IOW, setting DOITM=0 isn't going back to the stone age. At worst, I'd > guess that you're giving up some optimization that only shows up in very > recent CPUs in the first place. > > If folks want DOITM=1 on their snazzy new CPUs, then they came come with > performance data to demonstrate the gain they'll get from adding kernel > code to get DOITM=1. There are a range of ways we could handle it, all > the way from adding a command-line parameter to per-task management. > > Anybody disagree? It's not my preferred option for arm64 but I admit the same reasoning could equally apply to us. If some existing crypto libraries relied on data independent timing for current CPUs but newer ones (with the DIT feature) come up with more aggressive, data-dependent optimisations, they may be caught off-guard. That said the ARM architecture spec never promised any timing, that's a micro-architecture detail and not all implementations are done by ARM Ltd. So I can't really tell what's out there. So I guess knobs for finer grained control would do, at least a sysctl (or cmdline) to turn it on/off globally and maybe a prctl() for user. We don't necessarily need this on arm64 but if x86 adds one, we might as well wire it up. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Should Linux set the new constant-time mode CPU flags? 2022-09-15 17:52 ` Catalin Marinas @ 2022-10-26 17:01 ` Ard Biesheuvel 0 siblings, 0 replies; 14+ messages in thread From: Ard Biesheuvel @ 2022-10-26 17:01 UTC (permalink / raw) To: Catalin Marinas Cc: Dave Hansen, Jason A. Donenfeld, Eric Biggers, x86, linux-arm-kernel, linux-crypto, linux-kernel, Adam Langley, Kees Cook On Thu, 15 Sept 2022 at 19:52, Catalin Marinas <catalin.marinas@arm.com> wrote: > > On Tue, Aug 30, 2022 at 07:25:29AM -0700, Dave Hansen wrote: > > On 8/29/22 09:39, Jason A. Donenfeld wrote: > > > On Thu, Aug 25, 2022 at 11:15:58PM +0000, Eric Biggers wrote: > > >> I'm wondering if people are aware of this issue, and whether anyone has any > > >> thoughts on whether/where the kernel should be setting these new CPU flags. > > >> There don't appear to have been any prior discussions about this. (Thanks to > > > Maybe it should be set unconditionally now, until we figure out how to > > > make it more granular. > > > > Personally, I'm in this camp as well. Let's be safe and set it by > > default. There's also this tidbit in the Intel docs (and chopping out a > > bunch of the noise): > > > > (On) processors based on microarchitectures before Ice Lake ... > > the instructions listed here operate as if DOITM is enabled. > > > > IOW, setting DOITM=0 isn't going back to the stone age. At worst, I'd > > guess that you're giving up some optimization that only shows up in very > > recent CPUs in the first place. > > > > If folks want DOITM=1 on their snazzy new CPUs, then they came come with > > performance data to demonstrate the gain they'll get from adding kernel > > code to get DOITM=1. There are a range of ways we could handle it, all > > the way from adding a command-line parameter to per-task management. > > > > Anybody disagree? > > It's not my preferred option for arm64 but I admit the same reasoning > could equally apply to us. If some existing crypto libraries relied on > data independent timing for current CPUs but newer ones (with the DIT > feature) come up with more aggressive, data-dependent optimisations, > they may be caught off-guard. That said the ARM architecture spec never > promised any timing, that's a micro-architecture detail and not all > implementations are done by ARM Ltd. So I can't really tell what's out > there. > > So I guess knobs for finer grained control would do, at least a sysctl > (or cmdline) to turn it on/off globally and maybe a prctl() for user. We > don't necessarily need this on arm64 but if x86 adds one, we might as > well wire it up. > With all the effort spent on plugging timing leaks in the kernel over the past couple of years, not enabling this at EL1 seems silly, no? Why would we ever permit privileged code to exhibit data dependent timing variances? As for a prctl() for user space - wouldn't it make more sense to enable this by default, and add a hwcap so user space can clear DIT directly if it feels the need to do so? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2022-10-26 17:02 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-08-25 23:15 Should Linux set the new constant-time mode CPU flags? Eric Biggers 2022-08-26 7:23 ` Peter Zijlstra 2022-08-26 8:45 ` Arnd Bergmann 2022-09-15 17:18 ` Catalin Marinas 2022-08-26 15:40 ` Jeffrey Walton 2022-08-29 16:39 ` Jason A. Donenfeld 2022-08-29 18:08 ` Eric Biggers 2022-08-29 19:09 ` Jason A. Donenfeld 2022-08-29 19:05 ` Jason A. Donenfeld 2022-08-30 14:25 ` Dave Hansen 2022-09-01 11:00 ` Peter Zijlstra 2022-10-25 5:06 ` Eric Biggers 2022-09-15 17:52 ` Catalin Marinas 2022-10-26 17:01 ` Ard Biesheuvel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).