mdriley

Just a few more Rust libraries we've shipped in Chromium:

- https://github.com/image-rs/image-png

- https://github.com/webmproject/CrabbyAvif

- https://github.com/RCasatta/qr_code

- https://github.com/unicode-org/icu4x

I tend to agree. See also: https://issues.chromium.org/issues/401081629

Happy to report the BMP work is actually being done by our friends on the Edge team at Microsoft! https://chromium-review.googlesource.com/c/chromium/src/+/72...

Obligatory oldnewthing: https://devblogs.microsoft.com/oldnewthing/20030929-02/?p=42...

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.

TL;DR: use std::simd if you don’t mind nightly, wide if you don’t need multiversioning, and otherwise pulp or macerator.

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...

Hi, I lead Chrome's Rust efforts. I think the Typescript folks made a great and well-reasoned decision.

Based on the testing performed before the initial deployment of the Template Type (on March 05, 2024), trust in the checks performed in the Content Validator, and previous successful IPC Template Instance deployments, these instances were deployed into production.

It compiled, so they shipped it to everyone all at once without ever running it themselves.

They fell short of "works on my machine".

Man Yue Mo worked at Semmle (https://blog.sonatype.com/steps-to-responsible-disclosure) before it was acquired by GitHub (https://github.blog/2019-09-18-github-welcomes-semmle/). That research function has carried on as the GitHub Security Lab.

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.

Itanium had sliding register windows too: https://devblogs.microsoft.com/oldnewthing/20150729-00/?p=90...

The report says the cooling issue caused "a loss of service availability for a subset of [one] Availability Zone".

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?

(2015)

see also: an empirical analysis of how many "u"s the Internet thinks are in "excuuuuuse me, princess", by Ryan North (of Dinosaur Comics and other fine literature)

https://qwantz.livejournal.com/112122.html

one relevant datapoint: https://devblogs.microsoft.com/dotnet/announcing-grpc-json-t...

It seems like a lot of other technologies in this space have solved the listed problems while remaining compatible with browsers, load balancers, reverse proxies, etc.

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?

Eric Brandwine (VP/DE @ AWS) said publicly in 2019 that EC2 had never scheduled different tenants on the same physical core at the same time, even before we learned about things like MDS.

https://youtu.be/kQ4H6XO-iao?t=2485

"EncryptData"

https://github.com/microsoft/omi/blob/e4d72481fa2f805148c9c8...

See also Rands, “Seven plus or minus three”

https://randsinrepose.com/archives/seven-plus-or-minus-three...

You might enjoy Uber’s paper on SubmitQueue, their system to run CI on what they guess will be the sequence of commits that test successfully: https://eng.uber.com/research/keeping-master-green-at-scale/

Definitely not appropriate for protecting Real Infrastructure, but for my handful of personal machines I put my authorized keys in a Google Doc and configure hosts to download it using `AuthorizedKeysCommand`. Makes it easy to add and revoke hosts in one place, which also makes rotation possible.

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

If you'd like to see the last data that was public, here's the commit that merged in the removal: https://gitlab.com/gitlab-com/www-gitlab-com/-/commit/5ed24d...

Er, a few problems with the reasoning here:

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.

Heh, nope, `timebuild.pl` is the canonical entrypoint for an "official" Windows build, and has been for a very long time. It's a hideously elaborate dependency resolver and task runner that is responsible for tying together all the various build steps necessary to create an installable OS.

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 system

Sure, it's easy enough to find network-attached screens. The hard part is giving those screens access to anything without them showing up as vectors for every Red Team exercise.

Gizmos 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.

Every problem you describe was successfully worked through for the Google Code turndown in 2016.

(disclosure: I work at Google on side-channel stuff and https://github.com/google/safeside)

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)

When you say "control over the ISA", I'll assume you mean "precise control over the emitted instructions".

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.

SGX is a tool in the toolbox, but it solves a different problem: isolating a small section of especially privileged code from the rest of a larger, less-trusted application.

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.

so, some things:

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)

Wasm sandboxing is even safe to run in the same process as other code (at least modulo Spectre-type vulnerabilities)...

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.

ECC is not a total solution.

https://www.vusec.net/projects/eccploit/