Linux 4.14.12 released. AMD no longer has PTI. Full performance

Linux 4.14.12 released. AMD no longer has PTI. Full performance

Other urls found in this thread:

lists.opensuse.org/opensuse-updates/2018-01/msg00000.html
phoronix.com/scan.php?page=article&item=linux-kpti-pcid
lkml.org/lkml/2018/1/4/742)
lkml.org/lkml/2018/1/5/386).
lkml.org/lkml/2018/1/4/610)
lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.html
amd.com/en/corporate/speculative-execution
youtube.com/watch?v=qgiUuTmXyGs
developer.amd.com/amd-secure-memory-encryption-sme-amd-secure-encrypted-virtualization-sev/
twitter.com/AnonBabble

>tfw ryzen

feels good man

intel btfo

Intel BTFO of servers and data centers.
Xeons will be found piled up on the streets.

>tfw bought an intel laptop like 2 weeks ago

Where are the const additions? These variables are so unsafe!

...

>Full performance
>still worse then a gimped Intel chip
lel

>poozen
>feels good man
kek

>muh FPS look it's nothing
>why would you need nore than 4 cores
>muti-core performance? wtf man I just want to play callofduty1!1!xD
>being this mad

>then
You don't belong on this site.

ur late for the party

...

...

...

general desktop usage is unaffected

you werent going to run a big database server on a fucking laptop anyway, were you?

...

...

...

holy shit intel's epic fail of the century and it is only 2.45% down?

these markets are too stable. if something similar happened in crypto that would be total meltdown in just few hours

...

...

...

...

Nice shilling friend, yeah there's really no problem at all, DW about it tbqh makes me sleepy thinking about it

I want to buy a librebooted X200. Should I disable PTI on it? What are the odds of being pwned by meltdown anyhow? It can only READ my kernel memory, not write, so if I don't save any passwords, what's the big deal?

...

It can read the keys you type no problem

>tfw $500 desktop upgrade back in November

Only if it runs in the background. So if I close all tabs with js when typing in passwords I should be fine, right? Also as far as I know spectre could do that too and there is no remedy against that. Am I wrong in believing that meltdown = spectre with access to ring 0?

>tfw 500€ 1800X last year
And people told me it was a waste of money. If I had gotten Intel my 500€ NVMe SSD would be worthless now.

AMD Is RYZEN to the top.

>satisfied with bullshit benchmarks
>intelryzen
shintelfags are blind

You don't get it- the kernel is where the OS stores your passwords cleartext. And your encryption keys. And everything that makes your computer even remotely secure.
HTTPS is broken, all your passwords are available, etc.You could be completely pwned at any time.

No.. javascript is just do demonstrate how large the attack surface is, normal routes if malware implementing this exploit can read anything that stored in virtual memory

>normal routes if malware
Like what? There are no other attack vectors other than js if you have common sense. Do you think somebody is going to poke my ports, or what?

They still need to make sure not to do the silly "retpoline" fix on AMD.

>Like what?
Any remote code execution vulnerability.
Any malicious download.
Anyone that can break HTTPS and inject a malicious download.

Remember that SMBv1 vulnerability last year that let people do remote code execution via SMB even if you weren't sharing any folders?

Anything that has can run code on your cpu has the ability to exploit this bug

This my friend is the answer to the problems present
average joe does not need to have concern

Yes, and how could malicious code possibly execute without me running an exe or being cucked by js?

>Any remote code execution vulnerability.
How? How do you talk to a random machine on the net and just say "hey, execute this piece of code, will you please?" Especially with firewalls and NAT.

>Anyone that can break HTTPS and inject a malicious download.
Has this ever happened to end users? Aside from that one time some guy in Belarus redirected all BGP traffic through a single node of course.

>>Any remote code execution vulnerability.
>How? How do you talk to a random machine on the net and just say "hey, execute this piece of code, will you please?" Especially with firewalls and NAT.
NAT punching is possible or Skype and WebRTC wouldn't work. Also IPv6 gives every box a public address again. Unless you've actively configured your edge device to be a firewall besides being a NAT device (spoiler: most people haven't), your ass is wide open.
>>Anyone that can break HTTPS and inject a malicious download.
>Has this ever happened to end users?
Comcast routinely injects JavaScript into page loads to warn people about nearing or exceeding their data cap.

THIS CAN'T BE HAPPENING

Actually, while they may not have PTI, the newest microcode update for Ryzen entirely _disables_ branch prediction. When this gets upstream, Ryzen will take a significant hit too.

>Comcast routinely injects JavaScript into page loads to warn people about nearing or exceeding their data cap.
lmao
The state of the U.States

user, you should change jayz with s. burke in that pasta.

Source? Sounds like bullshit to me. Every processor that disables branch prediction would be much more secure but would also take a huge hit.

2nd

>nvidia driver and prime still not working

It's a SUSE-specific patch.

>NAT punching is possible or Skype and WebRTC wouldn't work. Also IPv6 gives every box a public address again. Unless you've actively configured your edge device to be a firewall besides being a NAT device (spoiler: most people haven't), your ass is wide open.

Everything you are saying is wrong and makes you sound like an idiot.

Really? Huh. Thought it would be mainlined.
It's worth noting that Intel also released a microcode patch that allows it to be selectively disabled, don't know about that though.

Yeah I already saw that patch yesterday. It's misleading to say that it'll be rolled out everywhere. It's just one option for mitigation and it's a good option to have for paranoia cases but it won't exactly be rolled out everywhere (especially once the more fine grained compiler/microcode mitigations are rolled out)

spectre

The patch was posted at lists.opensuse.org/opensuse-updates/2018-01/msg00000.html

Not an Intel shill, but
phoronix.com/scan.php?page=article&item=linux-kpti-pcid

I know, see There's no way AMD is gonna roll that out to everyone just like there's no way Intel will roll out something similar.

Unless I've lost my mind, Intel rolled up some sort of microcode update allowing parts of the branch predictor to be disabled. Windows 10 uses this new feature to disable the BTB AFAIK.
Might be losing it here, but I _swear_ I read it yesterday.

There's no way Intel will disable branch prediction for everyone. They will provide options to disable it (and they did as I was reading on the LKML yesterday). it'll be disabled selectively with microcode instructions during sensitive code paths, it won't be disabled all the time.

So it will certainly not "entirely" () disable branch prediction. Both vendors will provide options to do so and will allow it to be disabled during sensitive code paths to mitigate spectre allowing an attackers to break into the kernel or hypervisor.

>allow it to be disabled during sensitive code paths to mitigate spectre allowing an attackers to break into the kernel or hypervisor.
I mean it is especially important to protect against attacks breaking into the kernel or hypervisor but it can of course be applied to other applications as well.

I was talking about AMD's microcode patch in the first post, which isn't selective like the Intel microcode patch AFAIK.

Yes, that's what the Intel patch did.

Apologies for the accidental FUD earlier though.

>I was talking about AMD's microcode patch in the first post, which isn't selective like the Intel microcode patch AFAIK.
No, when I was reading the LKML yesterday they were talking about ways to selectively serialize on AMD just like for Intel and Tom from AMD (the guy who leaked) was reviewing the code. I can try to dig it up but the LKML interface is a piece of shit. May be easier to go through my 4chanx post numbers and looks through the archives.

AMD EPYC is going to grab some serious marketshare with this lmao

more like EPYC marketshare

See this thread from yesterday (lkml.org/lkml/2018/1/4/742) and this one from today (lkml.org/lkml/2018/1/5/386). In the context for the former they had a patch for Intel and were trying to figure out a good way to make it configurable so they could use this separate serialization method for AMD.

Ah.
Thank you, that explains a lot!

No problem. Interestingly according to Tom AMD does not need a microcode update for an efficient serialization option. With the right MSR bit set LFENCE will work.
In contrast Intel does not have an efficient option available without a microcode update. So the only choice without an update is to use a retpoline which actually won't work on skylake and late.
So Intel needs a microcode update to serialize efficiently (and at all on skylake and greater). They added an IBRS instruction (lkml.org/lkml/2018/1/4/610)

my sides

>tfw intel desktop and fell for the thinkpad meme

God dammit. Fuck this. Fuck this shit. I'm selling the finkpad.

>- Add microcode_amd_fam17h.bin (bsc#1068032 CVE-2017-5715)

>This new firmware disables branch prediction on AMD family 17h processor
>to mitigate a attack on the branch predictor that could lead to
>information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715).

good post

No update needed.

We already had this conversation above.
Follow this(v) thread.

Just don't update if you have a secure X86 CPU. (ie: not Intel)

AMD LIED!
RIZEN AFFECTED BY SPECTRE VARIANT 2 TOO!
BRANCHING PREDICTION HAS TO BE DISABLED!

lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.html

""""
This new firmware disables branch prediction on AMD family 17h processor
to mitigate a attack on the branch predictor that could lead to
information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715).
"""

AMD SHILLS BTFO

Everyone is affected by Spectre variant 2. Branch prediction does not have to be disabled, that's one mitigation and there are also others. See retpoline should mitigate variant 2 and LFENCE with the proper MSR bit set should mitigate variant 1

>Everyone is affected by Spectre variant 2.
not what amd said a few days ago.

amd.com/en/corporate/speculative-execution

"""
Variant Two

Branch Target Injection

Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.
"""

im a nigger
whats a pti

Fifteen fucking minutes and the floor would disintegrate as people cash out.

It would be a slaughter.

That's PR to downplay it but everything they said is reasonable.
Differences in the microarchitecture mean it is much more difficult to exploit. There's no PoC. But the theoretical vulnerability still exists so someone will probably figure it out eventually.

...

I don't get it. What's so special about that address?

SEV completely and absolutely flawlessly protects against both S1 and S2, you dumb fuck. EPYC is impenetrable and invulnerable as fuck.

always update

>>tfw segfaults

FTFY

Does gcc still anal rape this kernel on gentoo?

Was fixed half a year ago, you dumb shithead.

Idiot. SEV protects from physical memory attacks. It doesn't stop a program on the CPU reading the memory.
And in a Spectre attack the instructions reading the memory are actually from the correct binary that is supposed to be reading that memory.

>It doesn't stop a program on the CPU reading the memory.
It does, you retard.
See this:
youtube.com/watch?v=qgiUuTmXyGs
They literally show you can't do jack shit when trying to access memory if SEV's there. Absolutely immediate cockblock on all fronts.

Yeah you're an idiot. SEV is transparent to processes running on the CPU.

You're correct that it limits breaking the virtualization barrier, but Spectre is NOT JUST ABOUT VIRTUALIZATION. Virtualization is only one area where Spectre is an issue.
SEV does not prevent a Spectre attack against another application or against the kernel.

It's transparent, but encrypted. You can read the memory, but only the correct process can decrypt it.

The way Spectre works is it tricks the correct process into reading the data for it, as I said And SVE does not have a different key for every process anyway.
developer.amd.com/amd-secure-memory-encryption-sme-amd-secure-encrypted-virtualization-sev/
>Single key is used for encryption of system memory

>You can read the memory
What's the point in watching numbers if you can't scrape jack shit even one single 0?

47 to 43 is more than 8%

That "single key" has it's own internal encryption which changes randomly every time you use it, you dumb fuck.

It doesn't change for every process. In fact it would be impossible for it to change for every process because there's no way for an x86 cpu to know what process is executing. It could potentially have a different key for ring 0 and ring 3 but this still wouldn't matter because of how spectre works.
It's different for every virtual machine. But it doesn't even mitigate a spectre attack because of the way spectre works. You clearly don't understand how spectre works.

>no argument
>histrionic claim
>tripfag
ban

>It's different for every virtual machine
Which is exactly the primary reason why we are so scared of it. Cross-VM data leakage is more worrisome than Intra-VM data leakage.