diff options
| author | Bill Roberts <bill.roberts@arm.com> | 2026-07-07 13:45:42 -0500 |
|---|---|---|
| committer | Dave Hansen <dave.hansen@linux.intel.com> | 2026-09-02 14:06:27 -0700 |
| commit | f4cadf2d1ee3a24f259495309b76f98af467004b (patch) | |
| tree | 8a0a6bf308f0575aa2f1c9c62c9ac39c337bc348 /scripts/Makefile.thinlto | |
| parent | cee9395acd8043be0644b25c34bfa86623f2b935 (diff) | |
| download | linux-next-f4cadf2d1ee3a24f259495309b76f98af467004b.tar.gz linux-next-f4cadf2d1ee3a24f259495309b76f98af467004b.zip | |
x86/shstk: Shadow stack enabling write return code change
The WRSS instruction (the special instruction that writes to shadow stacks)
cannot be used in userspace unless IA32_U_CET.SH_STK_EN=1 (user shadow
stack is enabled). So the kernel *should* return -EINVAL to userspace if
it tries to enable it when shadow stack is disabled. However, currently,
it will return -EPERM. But, that error code doesn't fit the condition as
the failure is due to an invalid state change request not a permission
issue.
Investigating userspace call sites, like glibc and criu (checkpoint code),
they do not rely on this specific error message, nor could a userspace
effectively utilize this specific return error code to indicate a
difference in "I cannot enable write because of invalid permissions"
versus "I cannot enable write because the shadow stack is disabled".
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Link: https://patch.msgid.link/20260707184542.1721085-1-bill.roberts@arm.com
Diffstat (limited to 'scripts/Makefile.thinlto')
0 files changed, 0 insertions, 0 deletions
