diff options
| author | Yuki Okushi <jtitor@2k36.org> | 2023-05-06 09:09:32 +0900 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-05-06 09:09:32 +0900 |
| commit | ea1a0d76af42436115c26e4c7f60d56e993069a1 (patch) | |
| tree | 356010c33512e1ecaaa9c2ed9833aff0e8d76087 /tests/codegen/src-hash-algorithm/src-hash-algorithm-sha1.rs | |
| parent | 3d9a1de690c794fc72102d2de2324beeefe81322 (diff) | |
| parent | 97eab4db84715ebc475607e24dcdc65c6e0dd5d5 (diff) | |
| download | rust-ea1a0d76af42436115c26e4c7f60d56e993069a1.tar.gz | |
Rollup merge of #111139 - fortanix:raoul/fix_mxcsr_configuration_dependent_timing, r=thomcc
Fix MXCSR configuration dependent timing
Dependent on the (potentially secret) data some vector instructions operate on, and the content in MXCSR, instruction retirement may be delayed by one cycle. This is a potential side channel.
This PR fixes this vulnerability for the `x86_64-fortanix-unknown-sgx` platform by loading MXCSR with `0x1fbf` through an `xrstor` instruction when the enclave is entered and executing an `lfence` immediately after. Other changes of the MXCSR happen only when the enclave is about to be exited and no vector instructions will be executed before it will actually do so. Users of EDP who change the MXCSR and do wish to defend against this side channel, will need to implement the software mitigation described [here](https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/mxcsr-configuration-dependent-timing.html).
cc: `@jethrogb` `@monokles`
Diffstat (limited to 'tests/codegen/src-hash-algorithm/src-hash-algorithm-sha1.rs')
0 files changed, 0 insertions, 0 deletions