Intel Processors Hit with LVI Security Vulnerabilities, Mitigation Hits Performance Hard

[mtcn77]

What the heck is ASLR encryption? You do know ASLR is a randomization technique for addresss space layouts and doesn't have anything to do with encryption really, right?

Thank you, right as you said I'm not up for correct terminology.

 

[Aquinus]

Thank you, right as you said I'm not up for correct terminology.

I think @R-T-B's point is that If you're not getting the termanology right, what is supposed to make us think that you actually understand the problem correctly? So let's go through the steps you described:

• We identify targets beforehand(this vulnerability is only the tool, not the means),
• We spoof memory,
• We disable cpu caching,
• We flush caches,
• We access memory first(this is very important to pull it off without concurrent programs reaching for their turn of memory),
• We pull spoofed memory which goes to L3,
• Our accessed memory is in the next sector, however collide+probe somehow makes the sectors enter "probe from access-violate next sector" which is in the next L3 page/word/tag(I haven't figured that part),
• Through magic voila we now have data that is 2^-15 the data we need.

1. Unless you have root access to the machine, you're not going to know where the data your looking for is. So I don't understand how this is a realistic step in a real attack. You also need to know that this memory isn't going to change or move, so there are a lot of baked in assumptions here.
2. What the heck is "spoofing memory"? Are you overwriting memory for something else? Don't you at least need root access to the machine to do that? Something like this would require ring-0 access on the VM host (not even ring -1 access from a VM,) to do something like that across bounds of a VM.
3. Ok, but do you have control to do that from a VM?
4. Ok, but still not sure if you can do this from a VM.
5. How do you plan on preventing that from happening? If it's a server, that's out of your control.
6. Once again, what is this "spoofing" you speak of? Writing to cache has the same kinds of constraints as writing to main memory and you're probably not doing this without ring 0 access.
7. What are you doing that forces the CPU to read from the next page page, word, or tag in cache? An access violation shouldn't scan for another item in cache, it should generate a machine check exception.
8.

 

[lexluthermiester]

I think @R-T-B's point is that If you're not getting the terminology right, what is supposed to make us think that you actually understand the problem correctly?

This sums it up. It's why I didn't respond. He doesn't seem to understand the context of the documentation, nor the practical application of the functionality of the construct of the proposed attack scenario. However, I'll give him credit for trying to understand it as he's putting in way too much effort to be trolling.

 

[mtcn77]

The part that I might have missed is this gentleman was speaking about Intel and told it right away that AMD was too contained with the addition of page attribution tables in zen+ generation. He kept on going at a spectre deliberation, but I couldn't delineate the two. Anyway, you word as good as mine, folks...

 

[lexluthermiester]

The part that I might have missed is this gentleman was speaking about Intel and told it right away that AMD was too contained with the addition of page attribution tables in zen+ generation. He kept on going at a spectre deliberation, but I couldn't delineate the two. Anyway, you word as good as mine, folks...

AMD is completely unaffected by this new problem. The addressing system works a different way with everything AMD has made in the last 12 years. This is exclusively about Intel. At least that's what the data and documentation says.

 

[Aquinus]

The part that I might have missed is this gentleman was speaking about Intel and told it right away that AMD was too contained with the addition of page attribution tables in zen+ generation. He kept on going at a spectre deliberation, but I couldn't delineate the two. Anyway, you word as good as mine, folks...

Sure, but even with hardware vulnerabilities, their usefulness has to be measured in practicality. Spectre is a great example of a vulnerability that has almost zero usefulness beyond an academic paper.

 

[mtcn77]

Sure, but even with hardware vulnerabilities, their usefulness has to be measured in practicality. Spectre is a great example of a vulnerability that has almost zero usefulness beyond an academic paper.

I would advocate the contrary - meltdown is the more lethal vulnerability, but the easiest to patch. Spectre is different which makes it the benchmark vulnerability for this reason.

AMD is completely unaffected by this new problem. The addressing system works a different way with everything AMD has made in the last 12 years. This is exclusively about Intel. At least that's what the data and documentation says.

I was transposing the commentary present for AMD to this argument. Have some sympathy!

We should still keep comparing the two in my opinion cause lvi, as stated before, is pretty much theoretical only. It is a duel between amd spectre and intel spectre-class vulnerabilities.

 

[R-T-B]

AMD is completely unaffected by this new problem.

As far as we know. The docs are careful to state that AMD very well could and maybe even SHOULD be affected by this, they just could not make it happen in practice.

 

[mtcn77]

As far as we know. The docs are careful to state that AMD very well could and maybe even SHOULD be affected by this, they just could not make it happen in practice.

They state even in the white paper that you need meltdown for starters.

 

[HTC]

They state even in the white paper that you need meltdown for starters.

If true, then AMD cannot be affected by this particular vulnerability.

 

[R-T-B]

They state even in the white paper that you need meltdown for starters.

You are correct. Mental failure, lol.

If true, then AMD cannot be affected by this particular vulnerability.

Right.

 

[lexluthermiester]

The docs are careful to state that AMD very well could and maybe even SHOULD be affected by this, they just could not make it happen in practice.

While I'll admit my understanding of how L1/L2/L3 cache actually functions is limited, what I do know strongly suggests that Intel's and AMD's implementations differ enough that a vulnerability for one can not be assumed for the other.

If true, then AMD cannot be affected by this particular vulnerability.

And then there's this.

 

[R-T-B]

While I'll admit my understanding of how L1/L2/L3 cache actually functions is limited, what I do know strongly suggests that Intel's and AMD's implementations differ enough that a vulnerability for one can not be assumed for the other.


And then there's this.

As I admitted, I needed more caffiene/had a brain fart. Somehow got it confused with Spectre briefly.

 

[londiste]

While I'll admit my understanding of how L1/L2/L3 cache actually functions is limited, what I do know strongly suggests that Intel's and AMD's implementations differ enough that a vulnerability for one can not be assumed for the other.

Not just caches, the microarchitectural implementation (and resulting behaviour) of various buffers that are attacked in recent vulnerabilities are different.
Meltdown in particular seems to be a straightforward bug in Intel's design. One that is complex to abuse but still a bug.

 

[mtcn77]

Not just caches, the microarchitectural implementation (and resulting behaviour) of various buffers that are attacked in recent vulnerabilities are different.
Meltdown in particular seems to be a straightforward bug in Intel's design. One that is complex to abuse but still a bug.

Well, the explanation I've got from the expert is that this type of attack has no vector on AMD just because the PSP security processor does not have its own cache to be exploited like SGX.

 

[chaoshusky]

Everyone is still overlooking that a vulnerability much like Meltdown was found to attack AMD CPUs and a "RowHammer" type can attack anything with RAM+CPU so..only Virtual Machine hosts need poop themselves, maybe? Ah well, at least Intel's silicon is of higher quality and can handle its own current and voltage requirements.. In fact anything with a CPU and RAM should be nervous at this rate, my Oscilloscope is worried! The lines on the screen are all wavy.. Oh wait, it's supposed to do that! ^-^

 

[mtcn77]

a vulnerability much like Meltdown was found to attack AMD CPUs

Meltdown or spectre? Meltdown is more prolific and easier to debug. You just fence the user kernel from the system and all is well. Spectre is spoofing the system.

a "RowHammer" type can attack anything with RAM+CPU

Another overgeneralization. A row cycle takes what;

Spoiler: 295ns?

According to this Micron whitepaper, an All-Bank Refresh is issued an average of every 3.9µs and takes 295ns to complete.

Come on now, let's not assume the technology forefront is not armed against stupid ddos attempts...

Spoiler: Same bank refresh

Same Bank Refresh only requires that one bank in each bank group be idle in order for the command to process. The other 12 banks do not have to idle and can continue to operate normally.

Spoiler: Now that ain't much

REFsb commands are issued every 1.95µs but complete in 130ns. Using REFsb reduces the impact on idle latency from 11.2ns to 5ns.

SK-Hynix Plans for Blazing-Fast DDR5-8400 PC Memory

SK Hynix has big plans for DDR5 and intends to extend the standard all the way to DDR5-8400.

www.extremetech.com

 

[lexluthermiester]

Everyone is still overlooking that a vulnerability much like Meltdown was found to attack AMD CPUs and a "RowHammer" type can attack anything with RAM+CPU so..only Virtual Machine hosts need poop themselves, maybe? Ah well, at least Intel's silicon is of higher quality and can handle its own current and voltage requirements.. In fact anything with a CPU and RAM should be nervous at this rate, my Oscilloscope is worried! The lines on the screen are all wavy.. Oh wait, it's supposed to do that! ^-^

Except that you need physical access to exploit that one as well..