Searched hist:"072 e8aeb2b37970f90f682cbbfc44b62c0a04557" (Results 1 – 2 of 2) sorted by relevance
| /rk3399_ARM-atf/lib/extensions/pauth/ |
| H A D | pauth.c | 072e8aeb2b37970f90f682cbbfc44b62c0a04557 Thu Sep 11 08:03:26 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> fix(cpufeat): don't overwrite PAuth keys with an erroneous cache clean
Accessing cpu_data when TF-A is built with HW_ASSISTED_COHERENCY=1 is
simple. Caching (SCTLR_EL3.C) is enabled along with the MMU and we can
rely on all accesses being coherent. However, this is not the case when
HW_ASSISTED_COHERENCY=0. Most of EL3's initialisation (especially on
warm boot) happens with the MMU on but with caching being off. Caches
are only enabled deep into CPU_ON processing when we can be certain the
core has entered coherency. This latter case is the subject of this
patch.
Prior to this patch, the way to work around that was to clean the
apiakey cpu_data storage right after writing it. The write would have
gone straight to memory as caches were off and the clean asserted that
nothing would be in the caches which were assumed to be invalid since
we've just came out of reset.
The problem with this is that we cannot assume that ALL caches are
invalid when coming out of reset. We can reasonably assume those private
to the core to be (so the L1 and/or the L2; those are guaranteed to be
invalidated out of reset for every Arm core) but that is not the case
for shared caches (eg an L2/L3 DSU cache) which can be on when a core
powers down. So the old keys could still be live in the shared cache, we
write new ones to memory and clean the old to memory too, undoing the
work.
So the correct thing to do is to clean and invalidate the cache prior to
writing the keys to memory and invalidate it after. This ensures that if
there is any other data after the apiakey, which shares the cache line,
it will be safely forwarded to memory and the caches will be invalid
when caching is turned on.
It is important to note at this point that this was never observed in
practice - every known configuration that uses PAuth has the apiakey as
the very last member of the cpu_data struct which is padded up to a
cache line and the usage of the apiakey is such that it was never
allocated into the shared caches. So the clean would effectively perform
an invalidate of only the apiakey and all worked well. This was only
spotted with a proposed patch that added data after the apiakey
(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/39698/7).
Change-Id: I8493221dff53114c5c56dd73fbfd2a3301e2542c
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/docs/ |
| H A D | porting-guide.rst | 072e8aeb2b37970f90f682cbbfc44b62c0a04557 Thu Sep 11 08:03:26 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> fix(cpufeat): don't overwrite PAuth keys with an erroneous cache clean
Accessing cpu_data when TF-A is built with HW_ASSISTED_COHERENCY=1 is
simple. Caching (SCTLR_EL3.C) is enabled along with the MMU and we can
rely on all accesses being coherent. However, this is not the case when
HW_ASSISTED_COHERENCY=0. Most of EL3's initialisation (especially on
warm boot) happens with the MMU on but with caching being off. Caches
are only enabled deep into CPU_ON processing when we can be certain the
core has entered coherency. This latter case is the subject of this
patch.
Prior to this patch, the way to work around that was to clean the
apiakey cpu_data storage right after writing it. The write would have
gone straight to memory as caches were off and the clean asserted that
nothing would be in the caches which were assumed to be invalid since
we've just came out of reset.
The problem with this is that we cannot assume that ALL caches are
invalid when coming out of reset. We can reasonably assume those private
to the core to be (so the L1 and/or the L2; those are guaranteed to be
invalidated out of reset for every Arm core) but that is not the case
for shared caches (eg an L2/L3 DSU cache) which can be on when a core
powers down. So the old keys could still be live in the shared cache, we
write new ones to memory and clean the old to memory too, undoing the
work.
So the correct thing to do is to clean and invalidate the cache prior to
writing the keys to memory and invalidate it after. This ensures that if
there is any other data after the apiakey, which shares the cache line,
it will be safely forwarded to memory and the caches will be invalid
when caching is turned on.
It is important to note at this point that this was never observed in
practice - every known configuration that uses PAuth has the apiakey as
the very last member of the cpu_data struct which is padded up to a
cache line and the usage of the apiakey is such that it was never
allocated into the shared caches. So the clean would effectively perform
an invalidate of only the apiakey and all worked well. This was only
spotted with a proposed patch that added data after the apiakey
(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/39698/7).
Change-Id: I8493221dff53114c5c56dd73fbfd2a3301e2542c
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|