| Message ID | 20250128155428.210645-1-mark.rutland@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: mitigate CVE-2024-7881 in the absence of firmware mitigation | expand |
Hi Mark, On Tue, Jan 28, 2025 at 03:54:24PM +0000, Mark Rutland wrote: > On some CPUs from Arm Ltd, it is possible for unprivileged code to cause > a hardware prefetcher to form an address using the contents of a memory > location which is accessible by privileged accesses in the active > translation regime, potentially leaking the contents of this memory > location via a side channel. This has been assigned CVE-2024-7881: > > https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881 > > Arm's recommended mitigation is that firmware configures an > IMPLEMENTATION DEFINED control bit (CPUACTLR6_EL1[41]) to disable the > affected prefetcher, and updates to Trusted Firmware-A are available to > do this. For systems which have not yet recevied a firmware update, KPTI > can help to mitigate the issue. > > These patches enable KPTI for affected parts when the firmware > mitigation is not present. The presence of the mitigation is identified > by the presence of the SMCCC_ARCH_WORKAROUND_4 SMCCC call, which was > deployed with the mitigation. This is documented in the SMCCC 1.6 G BET0 > specification: > > https://developer.arm.com/documentation/den0028/gbet0/?lang=en > > I have tested this on a few configurations of virtual platforms. I'd > appreciate any feedback, especially on the KVM changes. The KVM changes look reasonable and follow the usual model for this crud. It would be nice to report the mitigation state to userspace somehow as I would like to have a KVM selftest for all of the hardware vulnerabilities. But anyway, Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
On Thu, Jan 30, 2025 at 01:48:53PM -0800, Oliver Upton wrote: > Hi Mark, > > On Tue, Jan 28, 2025 at 03:54:24PM +0000, Mark Rutland wrote: > > On some CPUs from Arm Ltd, it is possible for unprivileged code to cause > > a hardware prefetcher to form an address using the contents of a memory > > location which is accessible by privileged accesses in the active > > translation regime, potentially leaking the contents of this memory > > location via a side channel. This has been assigned CVE-2024-7881: > > > > https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881 > > > > Arm's recommended mitigation is that firmware configures an > > IMPLEMENTATION DEFINED control bit (CPUACTLR6_EL1[41]) to disable the > > affected prefetcher, and updates to Trusted Firmware-A are available to > > do this. For systems which have not yet recevied a firmware update, KPTI > > can help to mitigate the issue. > > > > These patches enable KPTI for affected parts when the firmware > > mitigation is not present. The presence of the mitigation is identified > > by the presence of the SMCCC_ARCH_WORKAROUND_4 SMCCC call, which was > > deployed with the mitigation. This is documented in the SMCCC 1.6 G BET0 > > specification: > > > > https://developer.arm.com/documentation/den0028/gbet0/?lang=en > > > > I have tested this on a few configurations of virtual platforms. I'd > > appreciate any feedback, especially on the KVM changes. > > The KVM changes look reasonable and follow the usual model for this > crud. It would be nice to report the mitigation state to userspace > somehow as I would like to have a KVM selftest for all of the hardware > vulnerabilities. Lemme go figure that out. Just to check, do you mean exposed through a KVM mechanism, or under /sys/devices/system/cpu/vulnerabilities/ ? I assume the latter. > But anyway, > > Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Thanks; much appreciated! Mark.
On Fri, Jan 31, 2025 at 11:01:38AM +0000, Mark Rutland wrote: > On Thu, Jan 30, 2025 at 01:48:53PM -0800, Oliver Upton wrote: > > Hi Mark, > > > > On Tue, Jan 28, 2025 at 03:54:24PM +0000, Mark Rutland wrote: > > > On some CPUs from Arm Ltd, it is possible for unprivileged code to cause > > > a hardware prefetcher to form an address using the contents of a memory > > > location which is accessible by privileged accesses in the active > > > translation regime, potentially leaking the contents of this memory > > > location via a side channel. This has been assigned CVE-2024-7881: > > > > > > https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881 > > > > > > Arm's recommended mitigation is that firmware configures an > > > IMPLEMENTATION DEFINED control bit (CPUACTLR6_EL1[41]) to disable the > > > affected prefetcher, and updates to Trusted Firmware-A are available to > > > do this. For systems which have not yet recevied a firmware update, KPTI > > > can help to mitigate the issue. > > > > > > These patches enable KPTI for affected parts when the firmware > > > mitigation is not present. The presence of the mitigation is identified > > > by the presence of the SMCCC_ARCH_WORKAROUND_4 SMCCC call, which was > > > deployed with the mitigation. This is documented in the SMCCC 1.6 G BET0 > > > specification: > > > > > > https://developer.arm.com/documentation/den0028/gbet0/?lang=en > > > > > > I have tested this on a few configurations of virtual platforms. I'd > > > appreciate any feedback, especially on the KVM changes. > > > > The KVM changes look reasonable and follow the usual model for this > > crud. It would be nice to report the mitigation state to userspace > > somehow as I would like to have a KVM selftest for all of the hardware > > vulnerabilities. > > Lemme go figure that out. Just to check, do you mean exposed through a > KVM mechanism, or under /sys/devices/system/cpu/vulnerabilities/ ? I > assume the latter. Yep, the latter. Google has a test out of tree that checks the pseudo-FW registers, hypercalls, and guest ID registers against what's in sysfs.
On Tue, 28 Jan 2025 15:54:24 +0000, Mark Rutland wrote: > On some CPUs from Arm Ltd, it is possible for unprivileged code to cause > a hardware prefetcher to form an address using the contents of a memory > location which is accessible by privileged accesses in the active > translation regime, potentially leaking the contents of this memory > location via a side channel. This has been assigned CVE-2024-7881: > > https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881 > > [...] Applied to arm64 (for-next/leaky-prefetcher), thanks! There hasn't been much review (thanks Oliver for looking at the KVM bits) and there's some implied work that can go on top of this series. But the patches looked fine to me, so I queued them. Mark or others, please shout if you'd like them dropped, they are on a branch. [1/4] arm64: cpufeature: rename unmap_kernel_at_el0() -> needs_kpti() https://git.kernel.org/arm64/c/174ade921138 [2/4] arm64: cpufeature: factor out cpu_is_meltdown_safe() https://git.kernel.org/arm64/c/f4fe70cd8522 [3/4] arm64: cpufeature: mitigate CVE-2024-7881 https://git.kernel.org/arm64/c/837dfd070e94 [4/4] KVM: arm64: expose SMCCC_ARCH_WORKAROUND_4 to guests https://git.kernel.org/arm64/c/d2c173acbf93
On Fri, Mar 14, 2025 at 06:37:25PM +0000, Catalin Marinas wrote: > On Tue, 28 Jan 2025 15:54:24 +0000, Mark Rutland wrote: > > On some CPUs from Arm Ltd, it is possible for unprivileged code to cause > > a hardware prefetcher to form an address using the contents of a memory > > location which is accessible by privileged accesses in the active > > translation regime, potentially leaking the contents of this memory > > location via a side channel. This has been assigned CVE-2024-7881: > > > > https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881 > > > > [...] > > Applied to arm64 (for-next/leaky-prefetcher), thanks! > > There hasn't been much review (thanks Oliver for looking at the KVM > bits) and there's some implied work that can go on top of this series. > But the patches looked fine to me, so I queued them. Mark or others, > please shout if you'd like them dropped, they are on a branch. I'm really not comfortable with this series and would prefer to see it dropped while we continue the discussion, especially as it's causing minor conflicts with the KVM/arm64 tree in -next. The series is pitched a bit like an erratum workaround, but the overall problem that a memory-dependent prefetcher can bypass permission checks is fairly general and, even if nobody else gets this wrong, I doubt that it's the last time Arm will mess it up. So, while the EL3 mitigation may be Arm-specific, I don't think the rest of it really is. That's especially true given the sorry state of spectre mitigations on third-party derivatives of Arm designs, such as the Qualcomm Kryo parts, and the fact that we provide userspace with a mechanism today for querying the state of those mitigations via sysfs. The immediate question, then, is whether this broken behaviour is prohibited by CSV3. The text in the latest Arm ARM just refers to "Data loaded under speculation", so it's not entirely clear whether that applies to a prefetcher. If it *does*, then I can see the argument for treating this like an erratum, but then we should zap CSV3 and treat these parts as being affected by meltdown. On the other hand, if CSV3 is not intended to cover these prefetchers, then we probably need to add a new "CVE-2024-7881" entry to /sys/devices/system/cpu/vulnerabilities. As it stands with this patch series, userspace has no way to know about the problem. kpti gets silently enabled in dmesg: | CPU features: detected: Kernel page table isolation (KPTI) but the contents of the vulnerabilities directory is pretty misleading: gather_data_sampling: Not affected ghostwrite: Not affected itlb_multihit: Not affected l1tf: Not affected mds: Not affected meltdown: Not affected mmio_stale_data: Not affected reg_file_data_sampling: Not affected retbleed: Not affected spec_rstack_overflow: Not affected spec_store_bypass: Mitigation: Speculative Store Bypass disabled via prctl spectre_v1: Mitigation: __user pointer sanitization spectre_v2: Mitigation: CSV2, BHB srbds: Not affected tsx_async_abort: Not affected The meltdown entry doesn't even mention that KPTI has been enabled. If we decide to go with a new entry for this, then we also need to change the default behaviour along the lines of Doug's Spectre-BHB changes queued on for-next/spectre-bhb-assume-vulnerable so that we assume vulnerable if we don't know better. To do otherwise will result in false assurances to userspace on derivative and third-party implementations. To be clear: I'm not at all against mitigating this problem and advertising the status of that mitigation. I *am* against quietly handling it like a CPU erratum whilst simultaneously telling userspace that meltdown is not a problem regardless of the mitigation state. Will
On Mon, Mar 17, 2025 at 09:26:12PM +0000, Will Deacon wrote: > On Fri, Mar 14, 2025 at 06:37:25PM +0000, Catalin Marinas wrote: > > On Tue, 28 Jan 2025 15:54:24 +0000, Mark Rutland wrote: > > > On some CPUs from Arm Ltd, it is possible for unprivileged code to cause > > > a hardware prefetcher to form an address using the contents of a memory > > > location which is accessible by privileged accesses in the active > > > translation regime, potentially leaking the contents of this memory > > > location via a side channel. This has been assigned CVE-2024-7881: > > > > > > https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881 > > > > > > [...] > > > > Applied to arm64 (for-next/leaky-prefetcher), thanks! > > > > There hasn't been much review (thanks Oliver for looking at the KVM > > bits) and there's some implied work that can go on top of this series. > > But the patches looked fine to me, so I queued them. Mark or others, > > please shout if you'd like them dropped, they are on a branch. > > I'm really not comfortable with this series and would prefer to see it > dropped while we continue the discussion, especially as it's causing > minor conflicts with the KVM/arm64 tree in -next. Catalin, unless you say otherwise, I'm going to assume this will be dropped in the interim. > The series is pitched a bit like an erratum workaround, but the overall > problem that a memory-dependent prefetcher can bypass permission checks > is fairly general and, even if nobody else gets this wrong, I doubt that > it's the last time Arm will mess it up. So, while the EL3 mitigation may > be Arm-specific, I don't think the rest of it really is. That's > especially true given the sorry state of spectre mitigations on > third-party derivatives of Arm designs, such as the Qualcomm Kryo parts, > and the fact that we provide userspace with a mechanism today for > querying the state of those mitigations via sysfs. > > The immediate question, then, is whether this broken behaviour is > prohibited by CSV3. The text in the latest Arm ARM just refers to > "Data loaded under speculation", so it's not entirely clear whether that > applies to a prefetcher. Hmm, good point. I think prefetchers fall under the ARM ARM glossary definition of speculation, which includes: - Operations generated by the hardware that are not directly generated by any instructions appearing in the Execution stream. > If we decide to go with a new entry for this, then we also need to > change the default behaviour along the lines of Doug's Spectre-BHB > changes queued on for-next/spectre-bhb-assume-vulnerable so that we > assume vulnerable if we don't know better. To do otherwise will result > in false assurances to userspace on derivative and third-party > implementations. Is the idea here that we'd assume any part with FEAT_CSV3 is vulnerable to CVE-2024-7881 unless told otherwise by firmware / known good list of implementations? ARCH_WORKAROUND_4 assumes software has already detected an affected implementation and doesn't distinguish between "not affected" and "not mitigated". So I'd be concerned that we're gonna turn on KPTI for a load of unrelated parts for something that hasn't (yet) been defined as a new ecosystem bug. > To be clear: I'm not at all against mitigating this problem and > advertising the status of that mitigation. I *am* against quietly > handling it like a CPU erratum whilst simultaneously telling userspace > that meltdown is not a problem regardless of the mitigation state. I like your idea of treating this as a broken CSV3 implementation instead of an entirely new CPU bug, if only to avoid the 'assume the worst' problem. Either way KVM will need to implement the SMCCC call to the letter, even if we wind up nuking CSV3. Thanks, Oliver
On Mon, Mar 17, 2025 at 03:38:34PM -0700, Oliver Upton wrote: > On Mon, Mar 17, 2025 at 09:26:12PM +0000, Will Deacon wrote: > > On Fri, Mar 14, 2025 at 06:37:25PM +0000, Catalin Marinas wrote: > > > On Tue, 28 Jan 2025 15:54:24 +0000, Mark Rutland wrote: > > > > On some CPUs from Arm Ltd, it is possible for unprivileged code to cause > > > > a hardware prefetcher to form an address using the contents of a memory > > > > location which is accessible by privileged accesses in the active > > > > translation regime, potentially leaking the contents of this memory > > > > location via a side channel. This has been assigned CVE-2024-7881: > > > > > > > > https://developer.arm.com/Arm%20Security%20Center/Arm%20CPU%20Vulnerability%20CVE-2024-7881 > > > > > > > > [...] > > > > > > Applied to arm64 (for-next/leaky-prefetcher), thanks! > > > > > > There hasn't been much review (thanks Oliver for looking at the KVM > > > bits) and there's some implied work that can go on top of this series. > > > But the patches looked fine to me, so I queued them. Mark or others, > > > please shout if you'd like them dropped, they are on a branch. > > > > I'm really not comfortable with this series and would prefer to see it > > dropped while we continue the discussion, especially as it's causing > > minor conflicts with the KVM/arm64 tree in -next. > > Catalin, unless you say otherwise, I'm going to assume this will be > dropped in the interim. Yes, I just dropped it.