51–60 of 119 posts
AWS bulletin: https://aws.amazon.com/security/security-bulletins/AWS-2018-... . Amazon Linux bulletin: https://alas.aws.amazon.com/ALAS-2018-1058.html RHEL patches are out. CentOS after delay, presumably. Nothing yet for Debian/Ubuntu. TL;DR: AWS is patched. Go update your kernel (especially if you run other people's code).
404 not found on the AWS link.
https://foreshadowattack.eu/ via https://lobste.rs/recent
Earlier quoted context omitted.
Contrast: "Meanwhile, we suggest using the stronger security and isolation properties of EC2 instances to separate any untrusted workloads." with: "Google Compute Engine employs host isolation features which ensure that an individual core is never concurrently shared between distinct virtual machines. This isolation also ensures that, in the case that different virtual machines are scheduled sequentially, the L1 data…
Amazon offers "dedicated hosts" and "dedicated instances", which you can specify in the "tenancy" field when launching an EC2 instance. I bet that's the stronger isolation that they're referring to. Costs more, though. https://aws.amazon.com/ec2/dedicated-hosts/
The "strong isolation of EC2 instances" refers to the properties of isolation provided by EC2's virtualization compared to processes within an operating system. It is challenging to safely and securely run untrusted code within sandboxes and processes using general purpose software. However, the hypervisor and hardware based virtualization of EC2 instances is engineered to provide isolation between mutually untrusted instances.
There are several reasons that customers may want to use dedicated instances or dedicated hosts, so we provide those tenancy options as well. The most common reason customers use dedicated hosts so that they can bring their own software licenses, which are often tied to a physical host.
Disclosure: I work for AWS.
Earlier quoted context omitted.
I think the key word is 'concurrently'. My guess is that micro and small instances indeed share CPUs, just never 'at the same time' and L1 is flushed before transition from one VM to another. I work for Google Cloud, but not related to security or OS development, so am not aware how it is actually being done.
> and L1 is flushed before transition from one VM to another. Is this true?
Getting the SGX attestation key would permanently break SGX-based blockchain (Hyperledger Sawtooth?) mining, if I understand correctly. It's amazing that (if this is correct) this vulnerability has permanently broken a large software project.
Earlier quoted context omitted.
There is a lot of legacy cruft in x86, but it's the devil we know. After decades of use, we are still discovering vulnerabilities, in a platform thought to be well-understood. The closest alternative would be ARM. In any case, it's a massive undertaking.
the problem is that hte platform is not well-understood. The design is convoluted and often not well-principled.
Earlier quoted context omitted.
How is the latter possible in case of 1 vCPU VM instances if 1 vCPU == 1 hyperthread? Do they give you a full core in this case?
1 vCPU instances do not simultaneously share cores with other customer instances via SMT (Intel Hyper-Threading Technology). A core can be sequentially time sliced between customer instances when you use a fractional (m3.medium) or burst (T2 instances) CPU instance type. https://aws.amazon.com/ec2/instance-types/ includes a note that provides some additional information about when vCPUs utilize Intel HT Technology: E…
Earlier quoted context omitted.
Or just keep using AMD CPUs, because yet again they are unaffected https://www.amd.com/en/corporate/security-updates
Never mind that AMD sockets used to last longer (less frequent incompatible socket changes), which meant you could do longer with your motherboard. Not sure if that still is the case though.
Getting the SGX attestation key would permanently break SGX-based blockchain (Hyperledger Sawtooth?) mining, if I understand correctly. It's amazing that (if this is correct) this vulnerability has permanently broken a large software project.
If said SGX application wasn't built around this model then it's probably not a valid use case of SGX..
Earlier quoted context omitted.
1 vCPU instances do not simultaneously share cores with other customer instances via SMT (Intel Hyper-Threading Technology). A core can be sequentially time sliced between customer instances when you use a fractional (m3.medium) or burst (T2 instances) CPU instance type. https://aws.amazon.com/ec2/instance-types/ includes a note that provides some additional information about when vCPUs utilize Intel HT Technology: E…
Um, no. If I schedule a micro instance in a particular zone and nothing else, for the duration of my timeslice the VM will have to monopolize the core. Optimal use of vCPUs would demand that two VM threads get scheduled to the core to take advantage of HT, which Google says it won’t do. Timeslicing doesn’t solve this problem. At least that’s my reading of what they said.