summaryrefslogtreecommitdiff
path: root/fs/netfs/Makefile
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2024-12-10 10:25:04 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2025-01-20 08:51:44 -0800
commit91309a70829d94c735c8bb1cc383e78c96127a16 (patch)
treefcf5a4cc7bfb2b0dfc365c93c7c33549f555a3da /fs/netfs/Makefile
parent027ea4f5f2c814b703adabdd42b779cd98e24411 (diff)
x86: use cmov for user address masking
This was a suggestion by David Laight, and while I was slightly worried that some micro-architecture would predict cmov like a conditional branch, there is little reason to actually believe any core would be that broken. Intel documents that their existing cores treat CMOVcc as a data dependency that will constrain speculation in their "Speculative Execution Side Channel Mitigations" whitepaper: "Other instructions such as CMOVcc, AND, ADC, SBB and SETcc can also be used to prevent bounds check bypass by constraining speculative execution on current family 6 processors (Intel® Core™, Intel® Atom™, Intel® Xeon® and Intel® Xeon Phi™ processors)" and while that leaves the future uarch issues open, that's certainly true of our traditional SBB usage too. Any core that predicts CMOV will be unusable for various crypto algorithms that need data-independent timing stability, so let's just treat CMOV as the safe choice that simplifies the address masking by avoiding an extra instruction and doesn't need a temporary register. Suggested-by: David Laight <David.Laight@aculab.com> Link: https://www.intel.com/content/dam/develop/external/us/en/documents/336996-speculative-execution-side-channel-mitigations.pdf Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/netfs/Makefile')
0 files changed, 0 insertions, 0 deletions