summaryrefslogtreecommitdiff
path: root/scripts/Makefile.thinlto
diff options
context:
space:
mode:
authorBill Roberts <bill.roberts@arm.com>2026-07-07 13:45:42 -0500
committerDave Hansen <dave.hansen@linux.intel.com>2026-09-02 14:06:27 -0700
commitf4cadf2d1ee3a24f259495309b76f98af467004b (patch)
tree8a0a6bf308f0575aa2f1c9c62c9ac39c337bc348 /scripts/Makefile.thinlto
parentcee9395acd8043be0644b25c34bfa86623f2b935 (diff)
downloadlinux-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