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.
Real ale has plenty of lower alcohol percentage options:
My faves are Harvest Pale 3.8% and Our House 3.4%
I also like mild which is often <=3%
0% Guinness is the only beer I would say that matches the taste of alcohol based beer. The others can be ok, but taste too malty, the flavour is off somehow. Also having 2 or more none alcohol beers seems to also make me feel "hungover" in a way, maybe due to additives.
I am very sceptical about this. I have some experience in GPU virtualization and passthrough with Nvidia GPUs and they are really not designed to be able to share them with multiple guests/host without Nvidia's blessing (licenced drivers).
Yes they are not... we run the Nvidia drivers unmodified. Only thing we have done is make the guest driver think it's running on the host, talking to the host's GPU kernel.
It works really well with a ~2% performance penalty. Nvproxy by google/gvisor has been doing this for years.
You should try running it yourself and see how it goes :D
So you can share the GPU between multiple VMs? I can have 4 VMs simultaneously do work on the GPU?
And each one would have its own Nvidia driver? How do they not interfere with each other? I mean I am by no means an expert in GPU architecture or anything similar, but I thought the problems with sharing a GPU come from the differences between GPU vs CPU architecture. On the other hand, multiple processes on a host can run on the same GPU, but that is all using the same kernel. I am just very confused.
This has been a thing for AMD, Intel, and Qualcomm GPUs for a few years now. Search for "DRM native context".
The only difference here is that you had to use mesa drivers before and now someone made it work with the Nvidia drivers.
Fair point, we still have a long way to go in terms of security AND being suitable for everyday use.
However, nvgpu is meant to be used in PCI passthrough in scenarios where you would want to run and share your GPU across multiple KVM guests, or you don't want to detach the GPU from the host, and plug it into the VM you are running... you know, that little dance you do everytime you want to game inside a VM.
On a laptop, I never got a working setup where I could attach/detach a modern nvidia card from host linux. So something that can do without is better.
But intel SRIOV is a thing as well, which should be the secure alternative.
I got it working on my laptop. It has an Intel integrated iGPU and an NVIDIA discrete dGPU. I was able to pass through the NVIDIA GPU and use it for CUDA/etc.
But the NVIDIA dGPU is muxless, so apparently all of the display outputs (laptop screen, HDMI outputs) are effectively hard wired to the iGPU. dGPU can render in a VM, it just has no where it can send it without trying to use Looking Glass or similar approach.
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!
Are you saying that RightSignature puts the checksum information inside the document and therefore destroys the checksum? What is the thinking behind that?
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.
How often do we need to bind a specific machine to a specific key in the case of TLS?
In every case of TLS I've seen we are concerned with organizational identity, not machine identity. This effectively extends to client certificates in cases like B2B & vendor integration.
In both scenarios you would definitely want to use an HSM style solution.
Protecting the HSM from inappropriate use (proving you are allowed to sign using the keys within) is a problem orthogonal to protecting the key material. In cloud HSM applications, you often combine the cloud vendors managed identity solution and HSM policies to effectively bind a set of machines to a set of keys.
Any time you've got hardware and want to attest that it hasn't been tampered with before allowing it to interact with something like an API endpoint.
At work we deploy industrial IoT gateways, these are very much not end-user devices. We are actually concerned about the device's identity, and more specifically about being able to attest that the device is in fact the one we thought it was and it hasn't been tampered with. By putting the key for TLS client certificate in the device's TPM, locked behind attestation that what's been booted is what we expected to boot, we can have a reasonable degree of confidence that we're communicating with the device we thought we were rather than just someone who managed to copy the private key off disk.
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.
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
What mjg59 says. The benchmarks are against a vTPM, that was what I had access to, and it's the environment I'm implementing the RATS side in.
Worth adding that not every outbound connection needs to go through the TPM (IMO). It's for the handful of services where the machine-identity actually matters, a secret store, or an HSM releasing key material onto an attested confidential VM, in my 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.
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.
If distributing under 3(b) then it's legitimate to only supply source on request. Historically source has been distributed without revision control history or metadata and been considered acceptable (the source tarballs on gnu.org are snapshots, for instance) so I think the preferred form argument is also tricky. I agree that there's huge value in having the individual commits, but from a GPL perspective we had this argument when Red Hat started flattening all patches in the RHEL kernel source 15 years ago.
When the build system expects a certain metadata which is removed by the force pushes or tag removal, then that is arguably not the preferred form. Grapheneos notes this elsewhere in the thread. [1]
I've been wondering about the Red Hat model! Seems like so much of modern development involves git blame or whatever to make sense of how the code came to be, and sometimes rule out an "obvious" modification that actually turns out to be a bad idea now that you know the historical context.
GrapheneOS might have a better case though if it's not just about understanding the code but about how the Android build system expects that everything is in Git.
I don't know what "Red Hat model" you mean, but if you're referring to their code delivery: It's not a problem for their internal developers, because they can use git lol. You can theoretically go to the upstream projects individually and merge the code drop with their nearest branch, and THEN do git blame/diff to figure out the delta and history of some lines of code. There are probably a few upstream open-source projects out there with no public VCS, but those are rare.
The license requires that it be distributed on a medium customarily used for software interchange, and I don't think you'd stand a good chance of arguing that paper satisfies that.
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.
Unfortunately, I know more than a few companies who do that. The same kind of developer who used SourceSafe to just checkout the entire project (thus locking it) while busy with it. And then pop a intranetcrm_200826_0713.zip on SharePoint. Enough of them around still unfortunately.
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
Mostly agreed. However you can solve the problem of having x% of disks corrupted via error correcting codes. It's what Google already does for their own internal storage: when you own millions of hard disks, some of them will inevitably fail.
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.