Missing CPU vulnerability and mitigation info on the Bcm2712

[ell1e]

My apologies if I'm just missing it, but it seems like this page lacks info on CPU vulnerabilities and the existence and effectiveness of mitigations of these in the latest mainline kernel: https://github.com/raspberrypi/documentation/blob/develop/documentation/asciidoc/computers/processors/bcm2712.adoc

This page suggests at least the predecessor was affected by quite a few of the widely found speculative issues: https://www.cvedetails.com/vulnerability-list/vendor_id-5420/product_id-96497/Broadcom-Bcm2711.html

Having definite information on this is to my understanding essential for e.g. any serious ARM64 cloud data center use and may sometimes even impact web browsing safety whenever it affects process isolation, so it would be nice if this was documented properly somewhere. Also, if there are any helpful workarounds to mitigate potential issues further, like disabling hyper threading does on many x64 desktop CPUs, that would also be useful.

[ghollingworth]

Rather than us provide generic information concerning particular vulnerabilities, it would be better to refer to the Arm security center for the particular architecture in question. For A76, this is the right page I believe:

https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability

We would only list vulnerabilities which only affect our particular processor.

Happy to add a link to that page someone a little more general.

[ell1e]

The ARM page seems geared at system developers, not so much users and administrators. Let me elaborate:

IMHO the most interesting thing to know is whether a mainline Linux kernel would be expected to have the necessary kernel side software mitigations and/or microcode updates (if the CPU supports them) and/or ARM trustzone firmware updates applied out of the box. Especially the latter two might be rather Raspberry Pi 5 specific questions since to my limited understanding, the boot images and detailed support can vary a lot between different ARM64 boards even with the same CPU on it. My apologies if I'm mistaken here.

One way to provide some info on that would be what the Vulnerabilities table of lscpu would be expected to list for a mainline kernel, for example. A note on whether any average user space application dealing with some secret info like passwords, but not running any untrusted code inside its process, would need to make use of any extra compiler mitigations to retain basic process isolation might also help.

The ARM page specifically seems to lack the following info if I'm reading it right: 1. for many mitigations it only lists kernel mitigations are needed but only for some whether mainline Linux actually has them, 2. for some mitigations trustzone firmware updates are listed as being needed but this doesn't tell a user or admin whether action on their part would be required or whether the kernel or similar are handling this already, 3. some mention of a "Variant 4" bug lists specific revisions of A76 and it's not too obvious to me which one a Raspberry 5 would ship, 4. and generally a table featuring all ARM processors and all their issues rather than just the trimmed down list actually relevant for the Raspberry Pi 5 will be hard to read for many admins.

I hope some of this feedback is helpful for figuring out how to best address this.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ell1e]

The underlying issue still seems to be present with the documentation page.

[JamesH65]

@tdewey-rpi Possible CRA impact?

[tdewey-rpi]

As @ghollingworth points out, if we replicate information from the ARM Security Center, we do risk stale information being presented to our users.

That puts us in a bit of a bind - on the one hand, I'd love to present a page like @ell1e describes (specifically, Raspberry Pi HW, known hardware vulns, known mitigations), but I'd also be extremely reticent to risk presenting stale information and granting people the illusion of coverage because they read a stale page in our documentation.

At the very minimum, however, we could expand the hardware descriptions to include the relevant core revision information. We already make reference to the stepping information from Broadcom on the SoCs we use, so I don't see a major technical readability jump by then including core revision data useful for making security decisions. This would not be subject to third party change in a way that would result in us presenting stale data, and would at least make navigating the ARM table more straightforward.

On the CRA, @JamesH65, I'll have to dig in further between the mixes of shoulds and musts - I believe the labelling and linking to the manufacturer's security information would comply, but I still cannot claim complete knowledge at this time.

[ell1e]

Maybe you could then ask ARM to at least add the missing information on which mitigation is actually handled by a mainline kernel in practice? My apologies if I'm just bad at reading, but it seems to be missing in some spots:

Variant 1: Says "Userspace code implementing software privilege boundaries should be reworked" for Linux, but doesn't specify whether the main Linux compiler toolchains gcc or clang were patched upstream to do this and starting from which version.

Variant 2: Says "For Cortex-A8, Cortex-A9, Cortex-A12, Cortex-A15, and Cortex-A17 please apply the kernel patches provided by Arm" for Linux, but doesn't seem to say whether the mainline kernel was patched to do this and starting from which version.

Variant 3: Says "Ensure your kernel implements Kernel Page Table Isolation (KPTI), referring to the patches in the branch above" for Linux, but doesn't seem to say whether the mainline kernel was patched to do this and starting from which version.

Variant 4: Says "Mitigation is based on disabling a hardware feature" for Linux, but doesn't seem to say whether the mainline kernel was patched to do this and starting from which version.

Spectre BHB: Says "View available Kernel patches" for Linux, but doesn't seem to say whether the mainline kernel was patched to do this and starting from which version.

Trusted Firmware-A: This one is listed with multiple patches in multiple places, but seemingly without info whether 1. the user can patch this on Linux and how, or 2. whether the mainline kernel patches this automatically and starting from which version, 3. where to get these updates, etc.

Basically, the info seems at best actionable to kernel developers but mostly useless to end users and system administrator right now. That seems however like what the page https://github.com/raspberrypi/documentation/blob/develop/documentation/asciidoc/computers/processors/bcm2712.adoc should possibly cover, so that end users get a very simple basic criterion like "there are issues x, y, and z, and use kernel x.y.z or newer and it should have all known mitigations for issues x, y, and z". Basically, I think any security-interested end user will just want to know if they need to do anything and if their CPU will be patched in practice or not, so they can make any upgrade or purchase decisions based on that.

Again, sorry if the ARM pages cover all this and I'm just missing the link or section that lists this concisely.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ell1e]

The issue seems to be unsolved.

[ell1e]

Is the stale marker bot perhaps somehow not working right? Sorry if it is and I'm just using up everybody's time.

[by]

Why not simply put the respective links to https://developer.arm.com and https://developer.arm.com/Arm%20Security%20Center into the docs?

[ell1e]

It would be a start, but as I pointed out above, ARM doesn't seem to list that much concrete info on the practical situation on Linux for admins (rather than kernel devs). Unless I missed something, which admittedly wouldn't be the first time 😛