The patch below does not apply to the 6.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.14.y git checkout FETCH_HEAD git cherry-pick -x a5951389e58d2e816eed3dbec5877de9327fd881 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to 'stable@vger.kernel.org' --in-reply-to '2025040844-unlivable-strum-7c2f@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From a5951389e58d2e816eed3dbec5877de9327fd881 Mon Sep 17 00:00:00 2001 From: Douglas Anderson dianders@chromium.org Date: Tue, 7 Jan 2025 12:06:02 -0800 Subject: [PATCH] arm64: errata: Add newer ARM cores to the spectre_bhb_loop_affected() lists
When comparing to the ARM list [1], it appears that several ARM cores were missing from the lists in spectre_bhb_loop_affected(). Add them.
NOTE: for some of these cores it may not matter since other ways of clearing the BHB may be used (like the CLRBHB instruction or ECBHB), but it still seems good to have all the info from ARM's whitepaper included.
[1] https://developer.arm.com/Arm%20Security%20Center/Spectre-BHB
Fixes: 558c303c9734 ("arm64: Mitigate spectre style branch history side channels") Cc: stable@vger.kernel.org Signed-off-by: Douglas Anderson dianders@chromium.org Reviewed-by: James Morse james.morse@arm.com Link: https://lore.kernel.org/r/20250107120555.v4.5.I4a9a527e03f663040721c5401c41d... Signed-off-by: Catalin Marinas catalin.marinas@arm.com
diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c index 89405be53d8f..0f51fd10b4b0 100644 --- a/arch/arm64/kernel/proton-pack.c +++ b/arch/arm64/kernel/proton-pack.c @@ -876,6 +876,14 @@ static u8 spectre_bhb_loop_affected(void) { u8 k = 0;
+ static const struct midr_range spectre_bhb_k132_list[] = { + MIDR_ALL_VERSIONS(MIDR_CORTEX_X3), + MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V2), + }; + static const struct midr_range spectre_bhb_k38_list[] = { + MIDR_ALL_VERSIONS(MIDR_CORTEX_A715), + MIDR_ALL_VERSIONS(MIDR_CORTEX_A720), + }; static const struct midr_range spectre_bhb_k32_list[] = { MIDR_ALL_VERSIONS(MIDR_CORTEX_A78), MIDR_ALL_VERSIONS(MIDR_CORTEX_A78AE), @@ -889,6 +897,7 @@ static u8 spectre_bhb_loop_affected(void) }; static const struct midr_range spectre_bhb_k24_list[] = { MIDR_ALL_VERSIONS(MIDR_CORTEX_A76), + MIDR_ALL_VERSIONS(MIDR_CORTEX_A76AE), MIDR_ALL_VERSIONS(MIDR_CORTEX_A77), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1), MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_GOLD), @@ -904,7 +913,11 @@ static u8 spectre_bhb_loop_affected(void) {}, };
- if (is_midr_in_range_list(read_cpuid_id(), spectre_bhb_k32_list)) + if (is_midr_in_range_list(read_cpuid_id(), spectre_bhb_k132_list)) + k = 132; + else if (is_midr_in_range_list(read_cpuid_id(), spectre_bhb_k38_list)) + k = 38; + else if (is_midr_in_range_list(read_cpuid_id(), spectre_bhb_k32_list)) k = 32; else if (is_midr_in_range_list(read_cpuid_id(), spectre_bhb_k24_list)) k = 24;
Hi stable maintainers,
On 08/04/25 14:45, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 6.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.14.y git checkout FETCH_HEAD git cherry-pick -x a5951389e58d2e816eed3dbec5877de9327fd881 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to 'stable@vger.kernel.org' --in-reply-to '2025040844-unlivable-strum-7c2f@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^..
Possible dependencies:
Note:
Have observed that mostly these dependencies are empty in newer stable FAILED patch emails.
Thanks, Harshit
thanks,
greg k-h
...
On Tue, Apr 08, 2025 at 03:22:47PM +0530, Harshit Mogalapalli wrote:
Hi stable maintainers,
On 08/04/25 14:45, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 6.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.14.y git checkout FETCH_HEAD git cherry-pick -x a5951389e58d2e816eed3dbec5877de9327fd881 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to 'stable@vger.kernel.org' --in-reply-to '2025040844-unlivable-strum-7c2f@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^..
Possible dependencies:
Note:
Have observed that mostly these dependencies are empty in newer stable FAILED patch emails.
Maybe because there are no possible dependencies? I don't know, those are generated somehow "magically" by Sasha, so maybe he hasn't updated them for newer releases?
thanks,
greg k-h
Hi,
On Tue, Apr 8, 2025 at 2:17 AM gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 6.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.14.y git checkout FETCH_HEAD git cherry-pick -x a5951389e58d2e816eed3dbec5877de9327fd881 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to 'stable@vger.kernel.org' --in-reply-to '2025040844-unlivable-strum-7c2f@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^..
FWIW, this patch applies cleanly for me to the top of 6.14.y if you simply apply all 5 patches in the series, all of which are CC stable. AKA these commands work
git checkout v6.14.1 # Current linux-6.14.y git cherry-pick ed1ce841245d~..a5951389e58d
Where you start getting a conflict is if you also take this patch from mainline:
e3121298c7fc arm64: Modify _midr_range() functions to read MIDR/REVIDR internally
The merge conflict between those two series was resolved upstream in:
edb0e8f6e2e1 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
-Doug
Hi,
On Tue, Apr 8, 2025 at 8:49 AM Doug Anderson dianders@chromium.org wrote:
Hi,
On Tue, Apr 8, 2025 at 2:17 AM gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 6.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.14.y git checkout FETCH_HEAD git cherry-pick -x a5951389e58d2e816eed3dbec5877de9327fd881 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to 'stable@vger.kernel.org' --in-reply-to '2025040844-unlivable-strum-7c2f@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^..
FWIW, this patch applies cleanly for me to the top of 6.14.y if you simply apply all 5 patches in the series, all of which are CC stable. AKA these commands work
git checkout v6.14.1 # Current linux-6.14.y git cherry-pick ed1ce841245d~..a5951389e58d
Where you start getting a conflict is if you also take this patch from mainline:
e3121298c7fc arm64: Modify _midr_range() functions to read MIDR/REVIDR internally
The merge conflict between those two series was resolved upstream in:
edb0e8f6e2e1 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
I tried again as of today's linux-6.14.y (which is 6.14.2), and the patches still apply cleanly. I can send all 5 patches to the lists if it's desired, but I'm uncertain if it's required since they all apply cleanly. Just "git cherry-pick ed1ce841245d~..a5951389e58d". They all apply cleanly all the way back to 5.15 as far as I can tell. Would I need to send the same 5 clean picks in response to every stable kernel from 5.15 all the way to 6.14?
These patches don't apply cleanly to 5.4, but that's because kernel 5.4 doesn't have `proton-pack.c`, so presumably none of the Spectre mitigations were ported back that far.
Some of the spectre stuff is present in 5.10, but it looks like not all patches are being picked there. It's probably not critical to support newer ARM cores there, but changing the default to say cores are vulnerable might be worth it? What do folks think?
-Doug
-Doug
-Doug
On Mon, Apr 14, 2025 at 08:37:36AM -0700, Doug Anderson wrote:
Hi,
On Tue, Apr 8, 2025 at 8:49 AM Doug Anderson dianders@chromium.org wrote:
Hi,
On Tue, Apr 8, 2025 at 2:17 AM gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 6.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.14.y git checkout FETCH_HEAD git cherry-pick -x a5951389e58d2e816eed3dbec5877de9327fd881 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to 'stable@vger.kernel.org' --in-reply-to '2025040844-unlivable-strum-7c2f@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^..
FWIW, this patch applies cleanly for me to the top of 6.14.y if you simply apply all 5 patches in the series, all of which are CC stable. AKA these commands work
git checkout v6.14.1 # Current linux-6.14.y git cherry-pick ed1ce841245d~..a5951389e58d
Where you start getting a conflict is if you also take this patch from mainline:
e3121298c7fc arm64: Modify _midr_range() functions to read MIDR/REVIDR internally
The merge conflict between those two series was resolved upstream in:
edb0e8f6e2e1 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
I tried again as of today's linux-6.14.y (which is 6.14.2), and the patches still apply cleanly. I can send all 5 patches to the lists if it's desired, but I'm uncertain if it's required since they all apply cleanly. Just "git cherry-pick ed1ce841245d~..a5951389e58d". They all apply cleanly all the way back to 5.15 as far as I can tell. Would I need to send the same 5 clean picks in response to every stable kernel from 5.15 all the way to 6.14?
I see all but the last one in the stable queues right now, let me try the last one...
Ok, that one also applied from 5.15.y and newer.
These patches don't apply cleanly to 5.4, but that's because kernel 5.4 doesn't have `proton-pack.c`, so presumably none of the Spectre mitigations were ported back that far.
Some of the spectre stuff is present in 5.10, but it looks like not all patches are being picked there. It's probably not critical to support newer ARM cores there, but changing the default to say cores are vulnerable might be worth it? What do folks think?a
That's up to you.
thanks,
greg k-h
Hi,
On Thu, Apr 17, 2025 at 7:10 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Apr 14, 2025 at 08:37:36AM -0700, Doug Anderson wrote:
Hi,
On Tue, Apr 8, 2025 at 8:49 AM Doug Anderson dianders@chromium.org wrote:
Hi,
On Tue, Apr 8, 2025 at 2:17 AM gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 6.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.14.y git checkout FETCH_HEAD git cherry-pick -x a5951389e58d2e816eed3dbec5877de9327fd881 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to 'stable@vger.kernel.org' --in-reply-to '2025040844-unlivable-strum-7c2f@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^..
FWIW, this patch applies cleanly for me to the top of 6.14.y if you simply apply all 5 patches in the series, all of which are CC stable. AKA these commands work
git checkout v6.14.1 # Current linux-6.14.y git cherry-pick ed1ce841245d~..a5951389e58d
Where you start getting a conflict is if you also take this patch from mainline:
e3121298c7fc arm64: Modify _midr_range() functions to read MIDR/REVIDR internally
The merge conflict between those two series was resolved upstream in:
edb0e8f6e2e1 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
I tried again as of today's linux-6.14.y (which is 6.14.2), and the patches still apply cleanly. I can send all 5 patches to the lists if it's desired, but I'm uncertain if it's required since they all apply cleanly. Just "git cherry-pick ed1ce841245d~..a5951389e58d". They all apply cleanly all the way back to 5.15 as far as I can tell. Would I need to send the same 5 clean picks in response to every stable kernel from 5.15 all the way to 6.14?
I see all but the last one in the stable queues right now, let me try the last one...
Ok, that one also applied from 5.15.y and newer.
Thanks! Yeah, I saw a bunch go through. I'll try to check back in a few days to make sure they all show up on git.
These patches don't apply cleanly to 5.4, but that's because kernel 5.4 doesn't have `proton-pack.c`, so presumably none of the Spectre mitigations were ported back that far.
Some of the spectre stuff is present in 5.10, but it looks like not all patches are being picked there. It's probably not critical to support newer ARM cores there, but changing the default to say cores are vulnerable might be worth it? What do folks think?a
That's up to you.
I ended up finding the spectre stuff even on v5.4--it was just in a different file. However, I'm not going to attempt to do any backporting to v5.4 or v5.10 myself because:
* The original incentive for me to post this series was to add QCOM_KRYO_4XX_GOLD to the k24 list. ...but there's no support for that CPU in 5.4 upstream anyway.
* The Kryo4XX patch _did_ apply to 5.10, just the further cleanups to "assume vulnerable" failed because the 5.10 tree doesn't have all the cleanups it depended upon. Backporting it would be a bigger effort and I'm not sure what the incentive would be. I'm happy to review if someone else wants to do the backport, though.
* The patch to add newer ARM cores seems even less likely to be needed on 5.4 / 5.10 kernels. Hopefully anyone developing on those newer cores is using a newer kernel.
-Doug
linux-stable-mirror@lists.linaro.org