I don’t protest the coinage here (goodness knows my native language did worse things to English words), but I can’t stop saying it in Gollum’s voice.

(a) If the type of a is “array of length N of pointer to (say) char” (declaration: char *a[N]), then a[i][j] means the jth char in the contiguous block pointed to by the ith pointer. In C#, this is what you get with an array of arrays.

(b) If the type of a is “array of length N of array of length M of char” (declaration: char a[N][M] — sic!), then a[i][j] means the jth element of the ith element, aka the (i*M+j)th char in the single contiguous memory block. In C#, this is what you get with a two-dimensional array.

The way this happens is a bit subtle:

(a) The value a, of type “array of size N of pointer to char”, first decays into “pointer to pointer to char”, then a[i] retrieves the ith “pointer to char” starting from it as a base, then in turn a[i][j] retrieves the jth “char” starting from that as a base.

(b) The value a, of type “array of length N of array of length M of char”, first decays into “pointer to array of length M of char” (sic!), then a[i] retrieves the ith “array of length M of char” starting from it as a base, which then decays into “pointer to char”, then a[i][j] retrieves the jth “char” starting from that as a base.

NB: There are no implicit references here, unlike in C#; in part (b), a is an N*M-byte chunk of memory and a[i] is an M-byte piece of it.

I don’t see how. I was trying to explain why it’s reasonable for a volatile read to be a side effect, after which the C rule on unsequenced side effects applies, yielding UB as you say.

That said, your “common parlance” definition of “data race” is not the definition used by the C standard, so your last sentence is at best misleading in a discussion of standard C.

> The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior.

(Here “conflicting” and “happens before” are defined in the preceding text.)

[1] http://web.archive.org/web/20031018072659/http://msdn.micros...

whose results won’t embarrass (of course; sorry)

In TPM-only mode, I only see the screen—which asks for an recovery key that serves an alternative to the TPM-borne secret, not for whatever you are calling the “TPM PIN” here—whenever I update the firmware or the bootloader (the latter from the other side of the dual-boot setup). Otherwise it boots straight to the login screen, which meshes with the measured-boot-only theory of operation I’ve described above. There’s nothing nefarious in this part, even if I think it exposes an unwisely large attack surface (e.g. the USB stack). I suspect you simply reboot so rarely you’re never hitting the happy path.

Rendering text beyond ASCII is famously difficult to do; rendering formatted text is sometimes difficult to even make sense of (e.g. what should a style change in the middle of an Arabic word do? how about a selection boundary being moved with arrow keys?); rendering honest-to-goodness Markdown, which can technically include arbitrary HTML tags, is nowhere in the vicinity of a small project.

None of which is to say that you shouldn’t demand that a toolkit solve it for you, only that I understand why the RichEdit control reportedly had a separate team allocated to it in turn-of-the-millenium Microsoft. Working with a large amount of formatted text feels like it should be the most complicated feature of any UI toolkit and I shudder at the thought of even designing the API for it.

(A web browser is good at all this. It also has the API surface of a web browser.)

And some things will still be on you regardless. Did you know Android has two modes for text wrapping, one that won’t reflow the entire paragraph after a single-word change at the end and a different one whose results embarrass a typographer from half a millenium ago? That’s very much the correct way to do things, but if you’re streaming text in, it’s on you to decide whether you want subpar wrapping throughout or a layout jump whenever a paragraph break arrives. Most importantly, it’s on you to know the question exists; there are more, some more important than this one.

(Modern toolkits aren’t the only ones that can be bad at scaling to large amounts of data, either. Notably, Microsoft had to write an entire new “windowless” one to replace USER’s heavyweight window-based one so that Access wouldn’t collapse under its own weight. They then reused it for IE, for similar reasons. Raymond Chen’s response[1] to complaints about that toolkit staying private to Microsoft amounted to “fuck off”.)

[1] https://devblogs.microsoft.com/oldnewthing/20050211-00/?p=36...

Not what happened here (I reserve my judgment wrt the promised TPM+PIN exploit).

In the default TPM-only mode of BitLocker, the secret is in fact in the TPM, which will (as instructed by Windows upon key creation) release it to the correct OS running on the correct computer. Notably not in the picture is any user-provided data: measured boot is the only protection. It is only the correct programming of the OS that makes it request an account password (completely unrelated to the disk-encryption cryptography) before letting the user poke at the disk, which the OS can at that point already decrypt.

Well, turns out the programming is such that if you ask politely it’ll just pop an Administrator(?) shell.

For what it’s worth, NT allows any 16-bit quantity but L'\\' (0x005C) in filenames (even nulls); it’s the Win32 layer on top of it that imposes all the other weird restrictions and mappings.

Just yesterday I encountered people complaining about a VM not connecting to a cloud service when they neglected to put their DNS server’s address in the config for the DHCP server used by that particular host. And a dysfunctional RNG is much more difficult to detect.

Short-lived isolated VMs (like might be used for CI) are one place where entropy can be a problem. The relevant definition of “platform” here is less about the CPU architecture and more about the environment.

In the default BitLocker configuration, Windows puts all the key material in the TPM, locked behind the usual trusted-boot stuff: known-good BIOS hashes the bootloader and tells the TPM, bootloader hashes the kernel and tells the TPM, kernel hashes the initial process and tells the TPM, (I’m not sure how far it goes in this specific application,) and at the end of it the TPM won’t release the keys unless the entire chain was correct. This process does (modulo TPM flaws) ensure the disk will only be decryptable when in the original computer running the original OS. It does not ensure that the original OS will not subsequently give a root shell to anyone who walks up to the keyboard and types in a cheat code, and that’s essentially what’s happening here.

Celebrite et al. take a similar approach: after your Android phone boots and you first enter your PIN (which, unlike with BitLocker defaults, is required to unlock the TPM, thus the distinguished status of “before first unlock” aka BFU vs “after first unlock” aka AFU), the key material is already in RAM and breaking dm-crypt is not necessary; all that’s needed is find a USB stack vulnerability or a Bluetooth stack vulnerability or whatnot that can be leveraged into a root shell.

It’s also a way of saying that the entire approach taken by hardware disk encryption (unspecified crypto done inside the device in an unverifiable manner) has, with the benefit of hindsight, proven fundamentally flawed despite its reasonable appearance (in every system which had used it, not just storage), and I wish there was a way to pressure (consumer) storage vendors into going in a different direction. It is simply never a wise choice to trust people’s opaque crypto, however competent they are.

Less emotionally but mostly equivalently, the expense and non-cryptographic skill requirements of breaking mass-storage crypto are quite high while the rewards are comparable to those from breaking much softer targets, so the absence of results since that one paper only changes my mind very slightly. Besides, we know plenty of examples of what these kinds of opaque, serious-business, pay-to-play environments produce: cellular crypto is an uninterrupted series of disasters, so is Wi-Fi, and the things that we do know about storage devices don’t point to an outstanding culture of cryptographic competence there either. Once you’ve done enough to slap an “OPAL” label on it (which says nothing about the internals), there’s just no competitive pressure to improve.

There is a right way to do all this, and it’s essentially what NICs do: allow the host to offload symmetric crypto to the device, but keep the results of said crypto accessible at any moment. And it’s not like there are even that many modes used in full-disk encryption, let alone ciphers.