Still waiting.
Low effort threads like this needs to be nuked. @moderators
Low effort threads ? Itās a discussion piece. I am by no means a CPU architect and I would imagine many of us arenāt, but I do have exposure to the hardware. This thread is about he possibilities of a vulnerability in a cpu architecture. This isnāt about anyoneās allegiance to a specific manufacturer or used as a way to attack each others for said allegiances. This is posted under āTech Policy & Newsā and that is exactly what it is. The problem is not the thread itās the people who choose to bring their war to the comments section.
Some of you need to decompress, go outside and quit believing you run the forum or should have any input on what getās posted as long as it abides by forum rules. Over time Iāve noticed several community members who lurk in the comments and spark unnecessary strife, maybe the mods should be more aggressive with those who are toxic.
I agree with your statement, and I should take more time to formulate my thoughts before posting, considering I do have some exposure to the hardware in question.
3 Likes
See? You typed three paragraphs there. All weāre asking for is MAYBE a little of YOUR input about the topic. YOUR insights. What do YOU think about the topic. Even just a single sentence helps, if youāre rushed or donāt have much to say.
3 Likes
Yet it remains a given fact that exploitation of this vulnerability via the Browser can be done with certain key factors in place. These key factors are not easily replicated in real world usage versus white paper written factors. There lay the simple gist of the matter without needing a novelette being written to explain what has numerous papers documenting the above already.
Long story short: Timing for the above must be precise with very specific criteria being met for the exploit to be workable as a vulnerability. Elsewise it remains more potential versus real world exploitation.
2 Likes
I disagree.
Judging by the material generated by this particular ālow effort thread,ā I would emphatically state that even if it were the Authorās sole intent to author low quality materialā¦ The Community at large has obfuscated that matter by the simple act of commenting with higher quality material that has drawn attention to the very thread mentioned.
4 Likes
So it should be but a small matter to edit your opening statement with your own thoughts upon the material you Authored.
Problem solved.
1 Like
well said.
1 Like
Getting us back on the rails, I guessā¦ But Iām thinking the āissueā that came of this feature is a software limitation of how a hypervisor interacts with the hardware.
My guess is that the host OS still needs to manage the encryption, which would mean that it isnāt unreasonable for the host OS to be able to get unencrypted data from a VMās allocated ram.
In the same sense that the internet runs on trust that netadmins need to trust others to not blow everything up with malicious BGP configs, we still need to do the same for datacenter admins. I donāt really think this will change until a hypervisor is managed by specialized hardware (i.e. motherboard)ā¦
Without looking too much into the research, Iām wondering if this could go the other way around so the VM could get at the hostās ramā¦?
This is wrong. AMDās SEV manages the encryption transparently to the OS and the encryption key never leaves the SEV. The OS just sees the memory as memory.
2 Likes
The whole point of encrypting the RAM is that neither host nor other guests can access the VMās memory. So if a rogue host can circumvent the encryption there is definitely a design problem there.
sounds like another version of what we have already seen with spectre and meltdown. read things that were supposed to be unreadable and do it almost undetectable.
As per @wendell you canāt really protect from a malicious hyper visor administrator, and from the sounds of it this still provides some level of protection against a VM escape from another VM running on the same hypervisor.
No released intel products even do memory encryption yet.***
And yes the AMD bias is strong here because the userbase is relatively technically educated.
There have been real world observed performance and stability problems with the meltdown patches, and iāve personally had to deal with them.
Put money where my mouth is and bought a 2700Xā¦
It been less than a month but AMDās responce from the artical. Unlike intels bug releases its seems the AMD releases go straight to the press. Lazy intel caching needs all the help it can get.
Why the german researchers didnāt work with AMD from the start ? Well its there integrity.
AMDās Secure Encrypted Virtualization (SEV) is designed to help protect virtual machines from inadvertent vulnerabilities in typical operating environments. SEV provides what was previously unavailable protection of memory in a virtual environment and is a first step to improving security for virtualization.
AMD is currently working with the ecosystem to protect against vulnerabilities that are more difficult to exploit, such as malicious hypervisor attacks like those recently detailed by German researchers.