| 09:57 | <Aapo Alasuutari> | In terms of the C++/Rust memory model, SharedArrayBuffer's UNORDERED ordering is just an ordinary read or write, right? (Assuming the platform doesn't need locks to write a value of that size in a single operation.) And not Relaxed. |
| 09:58 | <Andreu Botella> | my understanding is that in the C++/Rust memory model, "ordinary" reads and writes to a shared buffer, even if fine by the platform, can lead to compiler optimizations that might still mess things up |
| 09:58 | <Andreu Botella> | I think relaxed will do the right thing |
| 10:01 | <Andreu Botella> | or in other words, "ordinary" reads and writes to the same memory across threads without any other kind of synchronization, are a data race, with is UB in C++ and Rust |
| 10:04 | <Andreu Botella> | relaxed is a stronger constraint than the spec requires |
| 10:05 | <Aapo Alasuutari> | Yeah, the spec just kindly asks devs to refrain from writing data races, so Relaxed seems to be the "right but wrong" thing. |
| 10:05 | <Aapo Alasuutari> | It's right by C++/Rust standards, but it's wrong by spec standards. |
| 10:06 | <Andreu Botella> | I'm pretty sure that the spec only defines minimum constraints, and relaxed is stronger than that minimum constraint, so it's fine |
| 10:06 | <Aapo Alasuutari> | But the P word! |
| 10:06 | <Andreu Botella> | but it's been a long time since I've looked at this |
| 10:09 | <Aapo Alasuutari> | https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Writing.20a.20WebAssembly.20interpreter.20in.20Rust.20for.20wasm.20threads/with/488916330 for actually the exact same discussion (albeit from Wasm point of view, but it's the same point of view in the end) |
| 16:51 | <Michael Ficarra> | probably best to avoid installing any npm packages for a little while: https://www.reversinglabs.com/blog/shai-hulud-worm-npm |
| 17:56 | <kriskowal> | The best time to plug the postinstall scripts hole was yesterday, but today will do. There’s a tool for limiting postinstall script execution to a list configured by the project and by default denied. https://www.npmjs.com/package/@lavamoat/allow-scripts And I see that it might not be protecting people using some versions of yarn https://github.com/LavaMoat/LavaMoat/pull/1218 Please let me know if you have information we can post to provide guidance on how to use our package managers safely going forward. This would be a good use of the #tc39-tg3-security:matrix.org channel if folks would meet me there. |
| 18:03 | <Michael Ficarra> | nothing has changed in the last decade: https://blog.npmjs.org/post/141702881055/package-install-scripts-vulnerability |
| 18:11 | <Michael Ficarra> | hopefully enough people with publishing rights for major packages have MFA enabled on publish that it'll slow the spread |
| 19:15 | <bakkot> | npm enforces 2FA for people with publish right to popular packages |
| 20:36 | <Aapo Alasuutari> | Thinking on this a bit more, I don't think there's a way to implement ECMAScript SharedArrayBuffer related operations without inline assembly in Rust and C++: not only can you race (UB but could be fixed by using bytewise Relaxed operations), you can also do mixed-size atomic operations like CompareAndExchange: that's forbidden by C++ atomics as far as I can gleam but now we absolutely cannot fix this by using bytewise Relaxed operations as it would destroy the atomicity of the operation. So, it's ... problematic. At least until Rust decides to allow mixed-size atomics which it well might. |
| 20:45 | <Andreu Botella> | IIRC such atomic operations are always within an aligned 8-byte chunk |
| 20:47 | <Andreu Botella> | I think it's possible to implement the backing store as an [AtomicU64] |
| 20:49 | <Aapo Alasuutari> | Atomics can be used on any TypedArray backed by a SAB, so not limited to 8 bytes. |
| 20:50 | <Andreu Botella> | 64 bits = 8 bytes |
| 20:50 | <Andreu Botella> | I don't think there's been proposals for a Decimal128TypedArray yet |
| 20:51 | <kriskowal> | There has not, but the possibility has been invoked. |
| 20:51 | <Aapo Alasuutari> | Ah sorry, I misunderstood your meaning. I thought you implied that the ECMAScript spec says that all atomic operations are secretly done in 8-byte chunks. |
| 20:53 | <Aapo Alasuutari> | But anyway, that leads to a possibly worse problem where all atomic operations less than 8 bytes, and all unordered operations, became CAS loops. |
| 20:55 | <Andreu Botella> | my understanding is that Rust's atomics do use CAS loops on a larger size sometimes |
| 20:55 | <Aapo Alasuutari> | Yes, but this would mean CAS loops on smaller types :) |
| 20:55 | <Aapo Alasuutari> | 1 byte atomic write would need to CAS-loop on the whole 8 byte replacement to make sure it doesn't mangle the other 7 bytes. |
| 20:58 | <Aapo Alasuutari> | But I realise I'm actually talking silly things: there is a way to fix the problem of tearing appearing with atomic operations if the backing store is [AtomicU8], and that is to just use a lock. Of course, ECMAScript spec says that at least 4 byte atomics should be lock free, so that's a little awkward. |