Hi Ayan,
On 05/08/2024 11:44, Ayan Kumar Halder wrote:
On 02/08/2024 14:27, Julien Grall wrote:
Hi,
Hi Julien,
On 02/08/2024 13:14, Ayan Kumar Halder wrote:
From: Penny Zheng <[email protected]>
VMAP is widely used in ALTERNATIVE feature, CPUERRATA feature, etc to
remap a range of memory with new memory attributes. Since this is
highly dependent on virtual address translation, we choose to fold VMAP
in MMU system.
In this patch, we introduce a new Kconfig CONFIG_HAS_VMAP, and make it
only support in MMU system on ARM architecture. And we make features
like ALTERNATIVE, CPUERRATA, etc, now depend on VMAP.
While I agree that alternative should depend on VMAP (for now), I feel
this is incorrect for CPUERRATA. Very likely, you will need to deal
with them on the MPU.
Before making any suggestion, would you be able to clarify how you
envision to deal with errata? Will they be selected at built time or
boot time?
TBH, I hadn't thought that through. I am thinking about selecting them
at built time (like it is been done for Arm64 cpus).
To clarify, on arm64, the decision to enable the bulk of mitigation is
done at runtime. The Kconfig is just to remove it from the binary if you
you are not targeting such HW. With that in mind...
However given that there are lesser number of MPU cpus (only R52 and
R82) compared to MMU ones, could there be a simpler approach.
... do you mean always an errata enabled in the Kconfig would be always
mitigate (IOW no runtime selection)?
I am open to any suggestions you have.
Also, can we disable the CPUERRATA on MPU until we add support for the
first errata ?
So I have looked at the code and it is rather unclear why you actually
need to disable CPU Errata. Can you clarify what would happen if
cpuerrata is always built *and* CONFIG_ARM64_HARDEN_BRANCH_PREDICATOR is
gated by HAS_VMAP? I am assuming we will not need the branch predictor
hardening on Cortex-R (at least this is the implication from [1]).
Now regarding alternative, at least for arm64 this is used outside of
the errata. Not critical right now, but at some point you will want to
re-enable alternatives.
Cheers,
[1]
https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability
--
Julien Grall
