geogriffin's comments

> nothing says it has to be specifically earmarked for anything

Lawsuits in the US about deceptive fees like [1] come to mind.

[1] https://blog.ticketmaster.com/schlesinger-v-ticketmaster/

I have ran into a couple places I needed GATs while writing abstractions, without realizing beforehand it'd lead to needing GATs. This is especially true with lifetimes, which I'm not used to thinking about as part of an abstraction.. I think it will naturally open up doors for everyone without anyone necessarily realizing it apriori.

Looks like pretty good code, but interesting that they only have a few dependencies and decided to implement a lot of stuff, like kernel polling, themselves rather than using the mio crate. I wonder why.

They also implemented the noise handshake in a non-generic way tightly coupled to wireguard protocol, again written themselves instead of using an external dependency, which I think is also the approach other wireguard implementations have taken.. which is fine, but harder to independently verify. There's a lot of code there.

My thought specifically was that "core networking code" is code that handles untrusted, unsolicited data potentially from the entire world, written in C, with special performance requirements that gives programmers a license to eliminate redundant bounds checks wherever possible..

Pretty sure it was introduced here: https://github.com/apple/darwin-xnu/commit/c10988c130af09087...

In this commit a bunch of code was copy-pasted from BSD into ip_icmp.c in icmp_error() to quote IP packet data in icmp error responses. Unfortunately they forgot to copy a line from the BSD source which would prevent the overflow:

  icmplen = min(icmplen, M_TRAILINGSPACE(m) - sizeof(struct ip) - ICMP_MINLEN);

m is allocated with a fixed-length buffer (mbuf), which means without that line above we can overrun it:

  m = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR);

Copy-paste programming in core networking code...

Let's be precise; that Intel is enforcing enclave Launch Control is orthogonal to the SGX mechanism itself. Launch Control is a bane to end-users, like you said, and a pain to enclave creators (I had to talk to some random business development employee at Intel..) Intel has even specified a system for users to use their own Launch Control (or disable it) but that is not implemented in any actual chips.

Agreed.

> Only the CPU (silicon or microcode) can assist you in the flushing of L1 when you exit enclave mode.

This seems correct, upon double-checking. The interrupt process within SGX is called Asynchronous Enclave Exit (AEX) and does not give the enclave an opportunity to run any code upon interrupt, though it is possible to run code upon every enclave entry (via code placed at the Asynchronous Entry Pointer). I'm not sure that would help with any speculation-based exploits, however.

It looks like Intel is pushing these security-related patches pretty hard on vendors, as this latest patch was available in late May on one IBM board Softlayer uses, and early June on another Supermicro board they use.

BIOS updates are required for most SGX-related microcode updates, as the microcode has to be up-to-date before enabling the SGX feature via a MSR (which is usually done by the BIOS). This is so you can't start an enclave with old microcode, exploit it, upgrade microcode, and still pass remote attestation.

Also, the more major spectre-related microcode updates have to be applied very early (in the BIOS) probably for technical reasons. For this latest microcode update, for example, Intel didn't even include it in their downloadable microcode package as you linked to. On my v6 Xeons, I was able to get to revision 0x84 with the latest OS microcode package, but 0x8e with a BIOS upgrade.

SGX Remote Attestation was built specifically to deal with events like this. Intel starts to reject attesting to vulnerable microcode revisions after some period following disclosure. In this case, they even postponed disclosure until patched microcode revisions were available and those revisions already required for successful attesation.

If said SGX application wasn't built around this model then it's probably not a valid use case of SGX..

You wouldn't be able to disable interrupts as non-root. The iopl syscall allows the PoC to use CLI to disable interrupts. See the "sudo" in the NO_INTERRUPTS runs:

  $ gcc -o test test.c -Wall -DHIT_THRESHOLD=50 -DNO_INTERRUPTS
  $ sudo ./test

I would guess the deadlock is due to a hardware watchdog timer rebooting the system, or some other hardware function that needs to be tended to periodically before it hangs.

Welcome to Erlang/OTP "releases" where the folklore is that Ericsson engineers spent as much time testing releases (read: state migration code) as they did application code.

This gives new meaning to "location transparency" a la Erlang..

I've been doing this for a few years using my own domain and "recipient_delimiter = -" in postfix and actually (annoyingly) have yet to see an email address leaked. considering all the spam i got on my Gmail address, I was thinking it would happen fast, but I guess 1) I'm probably being more careful and 2) these things take time.

are you sure that little popup is not implemented in some emacs package? i get those little popups when working in edts-mode with erlang..

William Byrd's work in program synthesis is an interesting take on this, where an IDE can, guided by test cases written for a function, actually auto-complete code itself whilst writing the function, or tell the programmer when they have something wrong by violating a test case. Of course it is impractical right now, but a good step nonetheless.. It (Barliman) is demoed near the end of this video: https://youtu.be/OyfBQmvr2Hc

The chromeos security model praised in this article seems quite too conservative for devs to me, considering the inconvenience trade-offs:

- persistent state is discouraged, but not disallowed. in fact, when the browser is exploited, any/all internal state necessarily must be be accessable and modifiable. i'm taking an educated guess that persistent browser internal state is less guarded against exploitation than external inputs.

- once pwned, most of your important data can probably be captured and accounts taken over before you ever decide to reboot. it's a PITA to have to reboot before accessing anything sensitive; no one should have to think/remember to do that. (maybe if chromeos were serious about preventing persistent threats, they'd force a reboot every night?)

- yes, it's defense-in-depth, but security is a game of trade-offs, where convenience often trumps technical security mechanisms in terms of increasing security overall.

I enable dev mode, but I appreciate the "stateless" sentiment in terms of encouraging data backup. i think I end up backing up my data (git push, etc.) more often than I would on a non-chromeos laptop, because it "feels" like more a necessity; especially after my 2 yr-old son hit the spacebar during that god-awful dev-mode bootup warning screen, and proceeded to factory-reset my chromebook.

Western Digital solves #2 and #3 for the MyCloud EX4 by somehow issuing real browser-trusted certs to each device for the domain device<mac_address>.wd2go.com using their intermediate CA "Western Digital Technologies Certification Authority" (https://www.censys.io/certificates/eb94f8e2c8d0c8338bb8ba40e...), which is in turn issued by COMODO. Now, not everyone has an intermediate CA locked to their own domain, but maybe that's the issue? X.509 has the ability to restrict CAs to particular domains (e.g. see the "path constraint" on WD's CA in the info link above), so if it was easy to be issued a CA cert for your own domain, couldn't that be a potential solution to this problem?

I'm an erlang fan but I wouldn't claim message passing is "fast" in the sense that you might be thinking of (though copying data does have some GC and CPU cache performance benefits that are harder to reason about.) There's no magic in Erlang; copying data is copying data. The benefits of Erlang lie elsewhere, and I've heard Joe Armstrong, when asked about BEAM performance, say something along the lines of "why do you care about performance [in this day and age]?"

has anyone affected by this bug tried using a kernel configured with hyperthreading support disabled? would that work?