AMD's SME/SEV Security Support For EPYC Not Yet Ready On Linux

[phoronix]

Phoronix: AMD's SME/SEV Security Support For EPYC Not Yet Ready On Linux

While AMD announced their EPYC 7000 series CPUs last week, prominent new security features of these high-end processors aren't yet ready with support in the mainline Linux kernel...

http://www.phoronix.com/scan.php?page=news_item&px=AMD-SME-SEV-Epyc

[schmidtbag]

I never really thought about how Epyc's usage may be dramatically limited due to how cutting-edge of a kernel it requires. Distros focused on stability will basically be Epyc-incompatible, unless they backport these security patches.

[agd5f]

We work with enterprise distros to validate our platforms and backport the necessary changes.

[caligula]

I never really thought about how Epyc's usage may be dramatically limited due to how cutting-edge of a kernel it requires. Distros focused on stability will basically be Epyc-incompatible, unless they backport these security patches.

What about Intel's hyper threading issues? Does it also mean that Debian / CentOS etc. users need to prepare for constant crashes with their hardware?

[jrch2k8]

I never really thought about how Epyc's usage may be dramatically limited due to how cutting-edge of a kernel it requires. Distros focused on stability will basically be Epyc-incompatible, unless they backport these security patches.

if you ever wondered why people in business pays RedHat licenses when they can prolly get away for free with something like Centos is because RedHat handle this kind of scenarios(back port drivers, features, security fixes, etc, etc, etc.) for them, in fact it won't be weird if RedHat already support this features in their kernels plus other optimizations that haven't landed on mainline yet for Epic and TR.

Its called support, now for the FOSS distros it make take a bit longer to reach full support tho

[starshipeleven]

I never really thought about how Epyc's usage may be dramatically limited due to how cutting-edge of a kernel it requires. Distros focused on stability will basically be Epyc-incompatible, unless they backport these security patches.

Considerign that there is no software using these extensions anyway, I don't see this as so bad.

[starshipeleven]

What about Intel's hyper threading issues? Does it also mean that Debian / CentOS etc. users need to prepare for constant crashes with their hardware?

That's a microcode issue, so another thing.
Also, that becomes an issue only because Debian does not ship the software to deal with microcode updates by default. Other distros that have a less dumb approach will just push the update and businness as usual.

[torsionbar28]

I never really thought about how Epyc's usage may be dramatically limited due to how cutting-edge of a kernel it requires. Distros focused on stability will basically be Epyc-incompatible, unless they backport these security patches.

Which is exactly what all the enterprise distros have been doing for years. Nothing new about this.

[Jedibeeftrix]

I never really thought about how Epyc's usage may be dramatically limited due to how cutting-edge of a kernel it requires. Distros focused on stability will basically be Epyc-incompatible, unless they backport these security patches.

Well, coming in Q2 2018 we will have Ubuntu 18.04, SLES 15, and likely RHEL 8 some months afterwards.

So AMD have got to hope they get these patches into 4.14 at the latest.

[azdaha]

This is far from over, btw. Kernel 4.17.{0,1,2} have broken DRM if SME is enabled. Linus has reverted a commit that causes this problem, but that resolution hasn't been mainlined yet.

https://kernel.googlesource.com/pub/...a9319507f6f64f