abadideanever let it be said that Microsoft wasn’t very ahead of the curve! they had their .gitignore neatly set up in the 70s
| Joined | Oct 27, 2022 |
| Pronouns | she/her |
Alyssa the Kate
- 118 Followers
- 288 Following
- 53 Posts
Rust firmware security at big G 🦀 | opinions are her own | makes code smol | talks about weird stuff | 🏳️🌈🏳️⚧️
✧✦Catherine✦✧
Björkus "No time_t to Die" Dorkus
Thomas Depierre@mirabilos we do and we prefer to have nice things that we can actually use.
And spend the time fixing old code
Aria DesiresMy baby is stable in Rust!!! Strict Provenance BAYBEEEE
https://doc.rust-lang.org/std/ptr/index.html#strict-provenance
Will DormannAnd here we have it.
CVE-2025-0282 and CVE-2025-0283
https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Connect-Secure-Policy-Secure-ZTA-Gateways-CVE-2025-0282-CVE-2025-0283
CVE-2025-0282 (CVSS 9.0 stack buffer overflow) is being exploited in the wild.
@sha1lan In any case, I'm always happy to see more folks invested in memory safety. I'm glad to discuss further if you'd like. 🦀
(unrelatedly, I love your name!)
> in a memory-safe language, the invariants used to uphold memory safety only “lean on” invariants that are enforced entirely by the language, compiler, and runtime...
Rust sits at this interesting boundary where it has a checked superset of the language that is memory unsafe. This escape hatch can be combined with the type and safety system to create entirely *new* safety invariants that are programmer-designed but language-enforced. This is how indexing in a Vec works: inside it does a bounds check with its capacity field, and then an unsafe memory access. It's sound since it's memory safe for all valid inputs. The designers of Vec know this because they designed the `data` pointer to have an invariant that it points to `capacity * size_of::<T>()` units of owned aligned memory. Breaking that invariant outside of `Vec`'s definition itself requires `unsafe`.
@sha1lan
What I would do in practice is replace the `bool` array with an array of `#[repr(transparent)] struct OpenBool(u8);` and just accept any non-zero as true. Then I could manipulate the bytes safely with zerocopy and with minimal checks.
What I would do in practice is replace the `bool` array with an array of `#[repr(transparent)] struct OpenBool(u8);` and just accept any non-zero as true. Then I could manipulate the bytes safely with zerocopy and with minimal checks.
@sha1lan
In order to do that conversion, you either:
- Use `unsafe`, at which point reviewers' eyes can hyperfocus on whether all usage of the conversion is valid, or
- Use safe, statically-checked conversions like https://docs.rs/zerocopy/latest/zerocopy/trait.IntoBytes.html#method.as_mut_bytes, which would fail because this library knows that `&mut bool` cannot be safely converted into `&mut [u8]`.