The "What If" Performance Cost To Kernel Page Table Isolation On AMD CPUs

[Tuxee]

Michael, great work as always!

But Puntigamer? That's a big no-no Gösser is much better

Both pretty mediocre.

[Jabberwocky]

I mean, not having to choose between either greater performance or security is definitely a win for the peace of my mind.

I honestly don't think you will ever top performance and top security in one package. You have to choose one if you really want peace of mind.

Most people running x86 are using an OEM systems (that runs MS Office), running software in the cloud, playing AAA games or watching something in their web browser. These groups do not care about the low level issues around the platform, not enough to really know what is going on. AMD and Intel can't afford the overhead costs that security.

The hardware security bugs we have seen in the past ~5 years are not considered show-stoppers by x86 vendors. Spending money on brand-image delivers a better return on investment and everyone in the industry is doing it even smaller ones like Raspberry Pi Foundation. Heck they take it one step further and Just completely ignore vulnerable hardware don't write anything about it. Only state that older hardware is not vulnerable.

Disclaimer: I am not a low level hardware expert or kernel developer.

It is up to you to search through many useless forum posts and large amount of pull-requests in various repos. You need to find out how it's being mitigated, how the mitigation is being tested, is the mitigation or the test good enough etc... which is impossible for 99% of the customers. This was the most useful thread that I found and I spent a lot of time searching: https://forums.raspberrypi.com/viewt...4166&p=1489935 most other posts are utter garbage whether it's from the community or official posts. It's the best post that I could find but it still missed crucial information. The mitigation discussed was only for BTI (v2) not SSB (v4) the pi4 remained vulnerable for more than 2 years if you used the official distro. AFAIK if you are using EFI boot firmware like many distros that are targeting the pi4 then the SSB mitigation is not applied, that is not mentioned anywhere not by community nor Raspberry Pi Foundation. I stumbled on the information here: https://github.com/raspberrypi/firmware/issues/1451

I'm just glad that we have real experts that are able to find these bugs and mostly reported in an ethical ways. It's not feasible for researchers to investigate every single device. I takes more than one person years to research a single chip. It would be interesting to see what comes from this research in the practical day to day life. Are cloud providers going to take their own approach on this? Will AMD change their response? etc...

[NobodyXu]

I honestly don't think you will ever top performance and top security in one package. You have to choose one if you really want peace of mind.

Most people running x86 are using an OEM systems (that runs MS Office), running software in the cloud, playing AAA games or watching something in their web browser. These groups do not care about the low level issues around the platform, not enough to really know what is going on. AMD and Intel can't afford the overhead costs that security.

The hardware security bugs we have seen in the past ~5 years are not considered show-stoppers by x86 vendors. Spending money on brand-image delivers a better return on investment and everyone in the industry is doing it even smaller ones like Raspberry Pi Foundation. Heck they take it one step further and Just completely ignore vulnerable hardware don't write anything about it. Only state that older hardware is not vulnerable.

Disclaimer: I am not a low level hardware expert or kernel developer.

It is up to you to search through many useless forum posts and large amount of pull-requests in various repos. You need to find out how it's being mitigated, how the mitigation is being tested, is the mitigation or the test good enough etc... which is impossible for 99% of the customers. This was the most useful thread that I found and I spent a lot of time searching: https://forums.raspberrypi.com/viewt...4166&p=1489935 most other posts are utter garbage whether it's from the community or official posts. It's the best post that I could find but it still missed crucial information. The mitigation discussed was only for BTI (v2) not SSB (v4) the pi4 remained vulnerable for more than 2 years if you used the official distro. AFAIK if you are using EFI boot firmware like many distros that are targeting the pi4 then the SSB mitigation is not applied, that is not mentioned anywhere not by community nor Raspberry Pi Foundation. I stumbled on the information here: https://github.com/raspberrypi/firmware/issues/1451

I'm just glad that we have real experts that are able to find these bugs and mostly reported in an ethical ways. It's not feasible for researchers to investigate every single device. I takes more than one person years to research a single chip. It would be interesting to see what comes from this research in the practical day to day life. Are cloud providers going to take their own approach on this? Will AMD change their response? etc...

Researchers don't need to investigate every single device/CPU.

Once they find out a specific CPU model is vulnerable, they can conclude all CPUs using the same architecture is vulnerable.
And they will also be able to easily test other architectures by reusing the script/coding they write.

IMHO I had the exact opposite view on this when it comes to how the manufacturers treat the hardware level bugs.

I think they really put security over performance.

Both spectre or meltdown are extremely hard to exploit for hackers.
Testing access time of memory is hard and its result is going to be quite unstable and just as any hacking, it involves guessing.

So constructing such a program to exploit these CVEs are no easy task.
And unlike CVEs at software levels, such as buffer overflow, use after free, etc, where they is widely used in real world before they were migrated with
technologies such as ASLR, kfence, initialised stack variables, better C standard library functions, etc, these hardware bugs are really hard to exploit and there
is no report on real world attack based on that.

So I would say Intel, AMD and other manufacturers actually paid a lot of attention to this and fixed them (provide micro codes update, kernel patchs and compiler patchs)
quickly and put the security over performance (initial kernel patch actually is more pedantic and lose more performance, you can check these benchmark on this site).

[carewolf]

Is this mostly x86 that has security vulnerabilities and all this never ending exploits, vulnerabilities and side-channel attacks?
Or does ARM have this too?
I wonder if the researchers would find as many vulnerabilities in the Apple M1 processor.
Is it even possible to make a secure CPU that isn't slow?

ARM has them too. Apple's ARM processors even managed to copy the otherwise Intel specific Meltdown bug.

[Teggs]

So I would say Intel, AMD and other manufacturers actually paid a lot of attention to this and fixed them (provide micro codes update, kernel patchs and compiler patchs) quickly...

They pay a lot of attention to these problems, but I would say only sometimes is the mitigation 'quick'. A lot of them don't resolve until or after the researcher forces the vendor's hand.

If I recall the sequence, Spectre was made known at Black Hat 2016 (beginning of August), Google revealed Meltdown and such to x86 vendors in July 2017, and no public disclosure or patch was made available for them until January 2018.

There are a lot of variables in how serious or credible a vulnerability is, how difficult it is to mitigate, how many organisations have to cooperate... but also some people still try to bury things under the rug.

[kiffmet]

Fun fact regarding Graz: The "Cummunist Party of Austria (KPÖ)" has recently won the local elections and now provides the mayor, aswell as the city government. The communist party in Austria was founded after WWII when the Soviets occupied parts of the country, but they were never relevant on a federal level and the same was true for regional politics aswell - at least outside of Graz.
The election result caused a big uproar in the media, but it also has to be said that aside from the name, these aren't communists anymore. They are more akin to social democrats on the mid-left spectrum and successfully improved the locals' living conditions by making sure that there are enough flats (state owned/public property) available to rent for cheap.

Also, try to get your hands on some roasted pumpkin seed oil if you can; it's delicious and a specialty from styria (the state where Graz is).

[kiffmet]

Can't the sidechannel attack be easily mitigated by using a kernel that doesn't have a driver for providing CPU/core power draw information? MSR has been restricted to be root only aswell for some time now.

[GreenReaper]

Somehow, I get the feeling KPTI won't be recommended until AMD has specific hardware changes to assist it, at which point it will suddenly become good practice.

[smitty3268]

Somehow, I get the feeling KPTI won't be recommended until AMD has specific hardware changes to assist it, at which point it will suddenly become good practice.

You say that like it's a bad thing.

[Linuxxx]

I honestly don't think you will ever top performance and top security in one package. You have to choose one if you really want peace of mind.

Then how on earth did Intel achieve these results with Tiger Lake?

https://www.phoronix.com/scan.php?page=article&item=tiger-lake-mitigations&num=1