mjg59

If an authority on a topic says something and someone with no demonstrated experience on that topic disagrees with them without providing any evidence, that's not really an argument to authority kind of situation.

Oh, sorry, I didn't answer the other part of your comment. Network is required so you can boot from the network, which is commonly used for reimaging systems (not just servers, it's often done for laptops in enterprise environments). Non-keyboard input is a necessity for any devices that don't have a keyboard, but mouse input is also just what users expect these days.

No, no modern OS uses any BIOS calls on UEFI systems, and CSMs are disabled by default on any system sold with secure boot enabled (ie, everything sold with Windows pre-installed)

No, you'll still have the TPM's dictionary attack lockout.

Yup, if there's no passphrase involved.

It being UEFI doesn't mean it's a standard platform, there's no ACPI and you're going to need a custom kernel that targets that specific device. UEFI alone isn't enough to support booting a generic OS.

And thanks! Updated my profile.

UEFI is pretty common on phones now, but it's unlikely that any of them are running this network stack there.

Yeah I'm actually not terribly worried about the server scenario, but having a way to get code exec in the firmware lets you defeat measured boot, which means this is a Bitlocker bypass in the default config.

> doesn't really provide a hardware abstraction layer like BIOS does

I'm not really sure what this means. UEFI provides a consistent interface to access storage devices, network devices, input devices, and access to a framebuffer. How else would bootloaders work?

Wrapping/unwrapping means the HSM would generate the private key and then encrypt it with a key only known to the other HSMs. Those other HSMs would then decrypt the key on import. The private key should still have been impossible to examine outside the HSMs.

Yes. The degree to which this presents a different experience is one I would not have found credible beforehand.

Saw it on Friday in Berkeley, and: yes, there was absolutely audience participation, and there were moments where I had to restrain myself from joining in.

They're incredibly different things telling different stories. One doesn't replace the other.

In the US market, at least, the quality has improved dramatically over the past few years. Several established breweries now produce alcohol-removed versions of existing beers, with varying degrees of success - but in general my experience is that alcohol-free dark beers work better, the increased maltiness does a better job of hiding what's missing. IPAs and lagers can end up tasting somewhat thin compared to the normal version.

There's a few things I miss about the UK, and one of them is easy availability of beer that's less than 5%. Unfortunately that seems to have been creeping upwards - the shift to craft keg (rather than cask) beer seems to have been accompanied by moving more in the direction of US-style stronger beers. Several breweries do still produce milds that are in the <3% range, but it's increasingly hard to find them, even in pubs that used to be reliable suppliers. It's interesting how cultural this is.

Does "how it goes" include the guest being able to DMA over the host kernel?

Hrm, something of a lack of discussion about what level of access the card has to the host in the absence of IOMMU-restricted passthrough.

Not quite the scenario described (it wasn't an academic paper), but https://mjg59.dreamwidth.org/73317.html is my experience of dealing with a forged PDF. Part of the reason it's rare is that it's actually very hard to do it well!

In the given case - you want to bind communication to a given confidential compute instance, which means you want to be able to ensure that the communication is coming from within the confidential compute instance, which means you want to be able to prove that the private key is only accessible from within that instance. An HSM buys you nothing more there.

This feels like a somewhat odd design choice - you have a TEE, most TEEs (outside TPMs) are fast so there's little overhead in pushing your signing through there, why bother with short-lived credentials instead of just attesting to private key material ownership and having that be what the SPIFFE cert is issued to? Bearer token SVIDs are an awful thing that we should be getting as far away from as possible.

I helped design the attestation framework for https://docs.cloud.google.com/transfer-appliance/docs/4.0/re... - the goal was to ensure that the device you're about to copy a bunch of sensitive information onto is actually the device you were shipped and is running the expected software. This is definitely used in the real world.

A dedicated HSM will give you stronger trust that the private key material can't be extracted, but there's no real way to bind an HSM to a specific client and that's a very easy thing to do in the vTPM case.

You didn't really go into actually verifying the machine identity - obviously if you have a trusted mechanism to do that in advance then that's easy enough, but otherwise you'd want something like https://github.com/google/go-attestation and then to use control plane APIs to identify the vTPM EK to tie the TPM to the VM.

The benchmarks are from GCP, where the vTPM is implemented in the hypervisor rather than on something that's plausibly an 8051[1]. Doing this on actual client hardware is going to be a bunch slower.

[1] Typically ARM these days, but most system vendors aren't picking TPM vendors based on performance

I teach OS security for a masters course. I don't know where my students are for any given semester - it's a mixture between experts who need a certification (I have taught someone who literally wrote the book on a major OS's security model) and people who have ended up on security entirely by accident. It is extremely hard to write something that lands for that entire range. "Finished highschool" is really not a precise determinator in the way "I am literally 5" is.

I wholeheartedly agree. Making it more difficult to obtain GPLed source code than it was before is fundamentally a dick move.

Oh, I agree there.

They are, which is how they know how long it's taking.

My personal website isn't customarily used for software interchange, but http is. I think getting into discussions about which websites are acceptable and which aren't feels like a bad place.

But nobody has done this, which is why it's a problem for Graphene

1) floppy disks are not customarily used for software interchange - where they are still used (aircraft software updates, bits of San Francisco's streetcar infrastructure) it's weird enough to be remarked upon. 2) the cost to Google of finding enough working floppies and paying someone to dump that much code onto them, then mailing them out, then having the other end just say "disk 323 was corrupted by USPS X rays, please send again" 20 times, would massively outweigh the benefits of making this awkward