Diego Antonio Rosario Palomino (Aug 24 2024 at 22:35): Diego Antonio Rosario Palomino (Aug 24 2024 at 22:35):Hello, i would like to discuss some timing side channel attack mitigations with anyone that is interested.
1)Preventing timers in multi threaded code.
Speculative execution attacks relly on timing side channels to access private information.
Their exploitability can be greatly reduced by jittering and reducing the resolution of timers. However this can be circunvented if malicious code can communicate without delay to a backround thread dedicated to keeping track of the time.
Blocking shared data from being read for some time after it is updated could be used to prevent that, however that could cost performance ?
Many functional languages share almost exclusively ( or exclusively ) inmutable data. I am wondering whether wasm could take advantage of that : Different threads could pass each other inmutable references, and only the message that sends the reference would have to be delayed, memory regions or inner objects would not need to be individually locked
Lann Martin (Aug 26 2024 at 12:41):Have you reviewed Wasmtime's existing Spectre mitigations?
Alex Crichton (Aug 26 2024 at 14:19):There are mitigations in place for speculative execution (enabled by default) but there are no mitigations in place for cross-thread execution. WebAssembly has no native means of spawning a thread though and doing so requires embedder support so if you're worried you can always opt to not support it as an embedder. Most wasm binaries today don't assume threads at this time as well.
Alex Crichton (Aug 26 2024 at 14:19):Wasm wouldn't provide you any sort of guarantees about memory to lock/unlock/etc, you'd have to do that through a higher level abstraction
Ralph (Aug 29 2024 at 07:48):there are some good papers on how to modify the JIT to emit slightly varying code randomly, mitigating timing code as well, but to my knowledge no one has implemented that anywhere specifically.
Diego Antonio Rosario Palomino (Aug 30 2024 at 02:55):Yes, i reviewed the existing mitigations. However preventing timers is still desirable for several reasons :
Diego Antonio Rosario Palomino (Aug 30 2024 at 03:03):@Alex Crichton
Even if wasm doesnt feature mutexes and the like, maybe hosts could still implement mitigations against timers. For example keep an array of bools that corresponds to shared memory and set them to false for a random time after a location gets modified. Reading a shared address check the if the bool it corresponds to is true
Wasm could also introduce locks, so languages could target those features, just like how languages initally had to build their own gcs, but can now chose to do that or use Wasms
Diego Antonio Rosario Palomino (Aug 30 2024 at 03:04):Ralph said:
there are some good papers on how to modify the JIT to emit slightly varying code randomly, mitigating timing code as well, but to my knowledge no one has implemented that anywhere specifically.
you mean this paper ? https://css.csail.mit.edu/6.858/2013/projects/an24021-sa23885.pdf
Chris Fallin (Aug 30 2024 at 06:11):Blocking shared data from being read for some time after it is updated could be used to prevent that, however that could cost performance ?
For example keep an array of bools that corresponds to shared memory and set them to false for a random time after a location gets modified. Reading a shared address check the if the bool it corresponds to is true
I don't have any constructive ideas on mitigations for the shared-memory multithreading case, but I just wanted to note that the above thoughts seem to miss how shared-memory threading is implemented today: in any reasonably performant compilation model, a Wasm engine has to turn Wasm loads and stores into direct machine loads and stores. The bounds-checking may be explicit or not, but doing anything more than a cmp-and-branch (or Spectre-mitigation cmove) is going to be too costly to be practical. There isn't a place to put logic like "hide shared memory updates for some time" because loads and stores go directly to hardware; only the MMU is in that path, and updates to MMU mappings (aka TLB shootdowns) are relatively very slow.
Said more bluntly: if the cost of mitigation is a 10x or more penalty in execution speed, why do multithreading at all (unless one has >>10 cores willing to burn)?
Chris Fallin (Aug 30 2024 at 06:12):Another potential seed for thought: shared-memory multithreading in Wasm is not really fundamentally different, from a security point of view, from native shared-memory multithreading. Whatever mitigations may exist against timing widgets elsewhere could equally well be done inside the sandbox. In other words, it's not a Wasm-specific problem, and Wasm doesn't add any new twists IMHO (essentially, we add a base pointer to reach the Wasm heap, that's it, otherwise -- normal load and store instructions).
Ralph (Aug 30 2024 at 08:48):Diego Antonio Rosario Palomino said:
Ralph said:
there are some good papers on how to modify the JIT to emit slightly varying code randomly, mitigating timing code as well, but to my knowledge no one has implemented that anywhere specifically.
you mean this paper ? https://css.csail.mit.edu/6.858/2013/projects/an24021-sa23885.pdf
I had recently read this one: https://arxiv.org/pdf/2312.08156. I believe the main point is the same, roughly speaking.
Ralph (Aug 30 2024 at 08:51):Chris Fallin said:
Another potential seed for thought: shared-memory multithreading in Wasm is not really fundamentally different, from a security point of view, from native shared-memory multithreading. Whatever mitigations may exist against timing widgets elsewhere could equally well be done inside the sandbox. In other words, it's not a Wasm-specific problem, and Wasm doesn't add any new twists IMHO (essentially, we add a base pointer to reach the Wasm heap, that's it, otherwise -- normal load and store instructions).
What Chris says: speculative attacks are a generalized cpu problem, and a very interesting one. Every major cloud provider I know applies various techniques now at the hardware, hal, driver, and virtualization layers -- so I'm less concerned about such things myself though if I were running or delivering something I would very much be interested depending on the customer and the use case.
Ralph (Aug 30 2024 at 08:59):I think there's a larger conceptual problem that I bang on about periodically. People are now getting the message that wasm is a "secure cloud native binary" or something like that. This is an "OK" starting point, but it is then interpreted by the listener's mental context, which is typically EITHER containers or native code with OS and hardware access.
Ralph (Aug 30 2024 at 09:01):Once you start digging in, you discover that while several entire categories of attacks are eliminated (yay!) there are categories of cpu-related problems that are not -- bummer, I thought this was "safe"???. Speculation is definitely in that category. It's my belief that wasm will have mitigations eventually, but that's going to be hard work that must have enough value behind it to pay for the hours to do it. (Everyone wants security, no one wants to pay to do it.) BUT! not there yet.
Ralph (Aug 30 2024 at 09:02):The second "security" issue they encounter is that "they can't do everything they want directly with the OS or the hardware". This is also true, and it's a feature, not a bug.
Ralph (Aug 30 2024 at 09:03):but it does create some "wut" moments when you're learning that you can't do everything by default you had assumed you could (because containers, because native code can)
Ralph (Aug 30 2024 at 09:41):but that really comes into play when they assume there's readonly memory inside the module -- because OSes have this. wasm does not. It could! But something designed for for a small set of functions doesn't need that as a core feature. OSes do; so people assume this is a "mistake" instead of something you might or might not care about.
Ralph (Sep 01 2024 at 14:42):Ralph said:
Diego Antonio Rosario Palomino said:
Ralph said:
there are some good papers on how to modify the JIT to emit slightly varying code randomly, mitigating timing code as well, but to my knowledge no one has implemented that anywhere specifically.
you mean this paper ? https://css.csail.mit.edu/6.858/2013/projects/an24021-sa23885.pdf
I had recently read this one: https://arxiv.org/pdf/2312.08156. I believe the main point is the same, roughly speaking.
and this one: https://arxiv.org/pdf/2309.07638
Last updated: Nov 22 2024 at 16:03 UTC