Searched hist:f8138056404d788c94bff8b159317bf38145f102 (Results 1 – 5 of 5) sorted by relevance
| /rk3399_ARM-atf/include/lib/extensions/ |
| H A D | pauth.h | f8138056404d788c94bff8b159317bf38145f102 Wed Apr 02 10:02:44 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> refactor(cpufeat): convert FEAT_PAuth setup to C
An oversimplified view of FEAT_PAuth is that it's a symmetric encryption
of the LR. PAC instructions execute as NOPs until explicitly turned on.
So in a function that turns PAuth on, the signing would have executed as
a NOP and the authentication will encrypt the address, leading to a
failure. That's why enablement is in assembly - we have full control of
when pointer authentications happen.
However, assembly is hard to read, is opaque to the compiler for
optimisations, and we need to call into C anyway for the platform hook
to get the key. So convert it to C. We can instruct the compiler to not
generate branch protection for the enable function only and as long as
the caller doesn't do branch protection (and all callers are entrypoints
written in assembly) everything will work.
Change-Id: I8917a26e1293033c910e3058664e3ca9207359b7
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/lib/extensions/pauth/ |
| H A D | pauth.c | f8138056404d788c94bff8b159317bf38145f102 Wed Apr 02 10:02:44 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> refactor(cpufeat): convert FEAT_PAuth setup to C
An oversimplified view of FEAT_PAuth is that it's a symmetric encryption
of the LR. PAC instructions execute as NOPs until explicitly turned on.
So in a function that turns PAuth on, the signing would have executed as
a NOP and the authentication will encrypt the address, leading to a
failure. That's why enablement is in assembly - we have full control of
when pointer authentications happen.
However, assembly is hard to read, is opaque to the compiler for
optimisations, and we need to call into C anyway for the platform hook
to get the key. So convert it to C. We can instruct the compiler to not
generate branch protection for the enable function only and as long as
the caller doesn't do branch protection (and all callers are entrypoints
written in assembly) everything will work.
Change-Id: I8917a26e1293033c910e3058664e3ca9207359b7
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/include/lib/libc/ |
| H A D | cdefs.h | f8138056404d788c94bff8b159317bf38145f102 Wed Apr 02 10:02:44 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> refactor(cpufeat): convert FEAT_PAuth setup to C
An oversimplified view of FEAT_PAuth is that it's a symmetric encryption
of the LR. PAC instructions execute as NOPs until explicitly turned on.
So in a function that turns PAuth on, the signing would have executed as
a NOP and the authentication will encrypt the address, leading to a
failure. That's why enablement is in assembly - we have full control of
when pointer authentications happen.
However, assembly is hard to read, is opaque to the compiler for
optimisations, and we need to call into C anyway for the platform hook
to get the key. So convert it to C. We can instruct the compiler to not
generate branch protection for the enable function only and as long as
the caller doesn't do branch protection (and all callers are entrypoints
written in assembly) everything will work.
Change-Id: I8917a26e1293033c910e3058664e3ca9207359b7
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/include/lib/ |
| H A D | utils_def.h | f8138056404d788c94bff8b159317bf38145f102 Wed Apr 02 10:02:44 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> refactor(cpufeat): convert FEAT_PAuth setup to C
An oversimplified view of FEAT_PAuth is that it's a symmetric encryption
of the LR. PAC instructions execute as NOPs until explicitly turned on.
So in a function that turns PAuth on, the signing would have executed as
a NOP and the authentication will encrypt the address, leading to a
failure. That's why enablement is in assembly - we have full control of
when pointer authentications happen.
However, assembly is hard to read, is opaque to the compiler for
optimisations, and we need to call into C anyway for the platform hook
to get the key. So convert it to C. We can instruct the compiler to not
generate branch protection for the enable function only and as long as
the caller doesn't do branch protection (and all callers are entrypoints
written in assembly) everything will work.
Change-Id: I8917a26e1293033c910e3058664e3ca9207359b7
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/lib/el3_runtime/aarch64/ |
| H A D | context_mgmt.c | f8138056404d788c94bff8b159317bf38145f102 Wed Apr 02 10:02:44 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> refactor(cpufeat): convert FEAT_PAuth setup to C
An oversimplified view of FEAT_PAuth is that it's a symmetric encryption
of the LR. PAC instructions execute as NOPs until explicitly turned on.
So in a function that turns PAuth on, the signing would have executed as
a NOP and the authentication will encrypt the address, leading to a
failure. That's why enablement is in assembly - we have full control of
when pointer authentications happen.
However, assembly is hard to read, is opaque to the compiler for
optimisations, and we need to call into C anyway for the platform hook
to get the key. So convert it to C. We can instruct the compiler to not
generate branch protection for the enable function only and as long as
the caller doesn't do branch protection (and all callers are entrypoints
written in assembly) everything will work.
Change-Id: I8917a26e1293033c910e3058664e3ca9207359b7
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|