402 karma · joined April 1, 2014
Security, compilers, infrastructure. MSFT, FB, GOOG.
https://bsky.app/profile/matt.dev
> He eagerly sought intelligent advice and let it change his mind. He was held to account by a vigorous legislature.
> For us, today, Idiocracy might as well be The West Wing.
- https://github.com/image-rs/image-png
- https://github.com/webmproject/CrabbyAvif
> Multilingual support also explains why you see things like “1 folder(s)” instead of “1 folder” and “2 folders”. Why not have two format strings, one for when the number of items is exactly one, and one for when the number of items is two or more?
> Well, for one, that would significantly increase the number of strings we would have to carry around. (If you say “just add s to make the plural” then you really need to get out more!)
> For two, some languages (such as Slovene) have a “dual” number in addition to singular and plural. The Lahir language has singular (one), dual (two), trial (three), paucal (a few), and plural (many). So now you have to have perhaps five versions of every string that contains a replaceable number.
This matches the conclusion we reached for Chromium. We were okay with nightly, so we're using `std::simd` but trying to avoid the least stable APIs. More details: https://docs.google.com/document/d/1lh9x43gtqXFh5bP1LeYevWj0...
It compiled, so they shipped it to everyone all at once without ever running it themselves.
They fell short of "works on my machine".
Semmle built CodeQL, now offered by GitHub (https://docs.github.com/en/code-security/code-scanning/intro...), which GitHub and Microsoft (see https://www.microsoft.com/en-us/security/blog/2023/11/02/ann...) want to associate with "deep security insight".
So they continue to fund this kind of novel security research, for which security practitioners across industry are grateful.
How did a single-AZ failure cause outages for two dozen services?
Why did a single-AZ failure mean "approximately half of Cosmos DB clusters in the Australia East region were either down or heavily degraded" and require those clusters to do a cross-region failover?
It was a product choice not to offer a fallback path when HTTP/2 was unavailable. That choice made gRPC impossible to deploy in a lot of real-world environments.
What motivated that choice?
https://randsinrepose.com/archives/seven-plus-or-minus-three...
I have a hardware-backed "doomsday key" to use if the Google Doc stops working.
Writeup and script at https://github.com/mmdriley/authorized_keys
1. Windows developers did not build large parts of the product on any regular basis. Windows took ~18 hours to build on incredibly powerful build lab hardware -- as soon as it took longer, it was time to buy a new build lab. Incremental rebuilds were notoriously flaky, at least in the days before https://github.com/microsoft/BuildXL. The most common dev loop that I saw was to install a recent dogfood build (so APIs and binary interfaces were reasonably recent) and then repeatedly rebuild and clobber binaries on that install.
2. The only real build-configuration options for timebuild were architecture and compile mode (dbg, chk, fre, opt). There wasn't an option to build or not build parts of the tree.
3. raymondc's reference to "kernel-colored glasses" is about viewing things from the kernel side of API guarantees. This is more an applied lesson in Conway's Law.
refs: https://web.itu.edu.tr/~dalyanda/mssecrets/other/Startup.htm
In order to perform these operations, execute the following command from within a razzle window, whose current directory is %sdxroot%.
· perl tools\timebuild.pl
Experience with “Timebuild”, razzle, and the Windows build systemGizmos are used for basically any screen at Facebook that needs to display "live" information -- conference rooms, building maps, monitoring dashboards, etc. Each one has a provisioned identity protected by secure boot and hardware root of trust. They have a minimum of onboard storage (maybe even nothing mutable/persistent after boot?) so they're not a foothold for persistence.
I'm really excited to read that post!
I agree that the best we can claim right now is that we've made Spectre and other speculative attacks "expensive enough" that they're unlikely to be the most profitable area for attack.
That said, I'd be a bit worried about the assertion we haven't seen Spectre attacks "in the wild". It is incredibly difficult to put together a set of metrics that would convincingly detect attempts at even a straightforward speculative information disclosure.
(haha, two branches, I get it)
In which case: yes! That's Speculative Load Hardening (https://llvm.org/docs/SpeculativeLoadHardening.html). SLH tries to squash side-channels by preventing any speculatively-loaded data from being forwarded to dependent instructions until proving that branch prediction followed the right path.
But this undoes a lot of the performance that microarchitectures have added through branch prediction, since dependent memory loads (think linked list entries, or C++ vtables) are stalled behind full resolution of the branch condition.
If you're doing nontrivial compute, you can end up ahead performance-wise by splitting the computation into a separate process and invoking it via IPC. Now you don't need SLH because the untrusted process doesn't have long-lived secrets in its address space.
The sandbox described in the article is trying to do roughly the opposite: protect the main application from an isolated section of untrusted code.
Also, SGX requires extreme care in deployment due to side-channel attacks, see e.g. https://software.intel.com/security-software-guidance/insigh...
SEV is also interesting, but requires code to run in a separate VM -- which satisfies my requirement above that it at least be in a different process.
1. Information disclosure is pretty important, especially if your process has AWS credentials in the environment block or it's doing mTLS with a long-lived key.
2. Those operating systems already exist, see e.g. https://twitter.com/aionescu/status/948818841747955713
3. Spectre V1 is within the same process, so this isn't a question of address mappings across differently-privileged domains. It's the same domain (i.e. address space).
4. Flushing address spaces across privilege domains isn't a concern on modern processors thanks to tagged TLBs and process-context or address space identifiers (PCID, ASID)
If you want strong security with this big a modulus you may have been looking for RSA. (ugh, sorry)
Spectre V1 (speculative bounds check bypass / type confusion) is basically game over for intra-process memory isolation without introducing expensive or complicated mitigations: speculation barriers at every branch, or a more optimized pass like Speculative Load Hardening (https://llvm.org/docs/SpeculativeLoadHardening.html) that can bring the overhead _down_ to 20-50%.
From what I've seen, the best understanding right now is that the process is the smallest defensible unit of isolation.
That's not to say that using WASM as an intermediate compilation target won't eliminate some threats! The runtime can definitely help to improve memory safety, for example. But if you care about confidentiality of the data in your process, any code that is untrusted enough to require sandboxing should also be run out-of-process, e.g. across an IPC boundary.