Cute website about the attack from the researchers: https://meltdownattack.com/

Basically, any program's memory can be read and tampered with, additional security *will* slow down processing (think of it like a military checkpoint on the road)
The overhead is estimated to be 20% to 30%

should I still do an intel build or is this big enough of an issue to do a ryzen build instead?

Its up to 50% in IO heavy server workloads. This is absolutely disastrous for Intel.

i'd wait for benchmarks honestly, especially given how...optimized tf2 is

According to: https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html , AMD and ARM are also affected. I'd wait a week or two to see how it pans out.

Correct.

In theory it shouldn't change much for TF2, although TF2 does weird shit with the TLB too so it could be either better or worse.
Generally games won't be affected much.
https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests

In general though it is rather annoying and fucks filesystems completely.
https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

Don't confuse Spectre and Meltdown.

Meltdown = fix is coming, but causes slowdown = Intel only
Spectre = everyone is fucked, but difficult to exploit = shown to work on Intel, only works on AMD within the same process or with specific non-default settings = no fix yet

It's affected by Spectre (but everything is affected by it, even though it's silly difficult to exploit).
Meltdown (the easy and rapey one) is Intel-specific.

https://i.imgur.com/q2ri8JS.png

from what i read AMD is only seriously affected in the FX PRO niche series

so can any1 whos a tech wiz put all this in laymans terms for us uneducated folk who r worried about our system security?

a friend told me to use this https://downloadcenter.intel.com/download/27150?v=t to check if my pc should be affected, can anyone confirm or deny if its a valid assessment?

in simple terms, this bug allows a program on a computer to access all of the memory on a computer without having to ask, meaning that it can see anything on your computer, including passwords, sensitive information, or anything else it might want. And because this is a hardware bug and not a software one, it affects literally everything with this hardware in it, including banking websites, google, amazon, or in short: everything. This means that an attacker can take any information that they want from anywhere that they want, and that's really really extraordinarily bad.

that is unrelated to Meltdown or Spectre, the attacks in this thread. But it's never a bad idea to make sure that you aren't vulnerable to security holes, and if you are, how to mitigate them.

-

It heavily depends on the application itself. After applying the software patch, the performance is worse for practically every system call (i.e. the really low-level kernel functions), as the user-space memory has to be explicitly separated from the kernel-space memory. So the performance impact will be seen mainly on servers (they use a lot of connect() syscall, for example). On client computers, it can be noticeable from time to time, but not during every-day use.

-

What worries me the most, though, is that for ten years all the passwords, secret keys, etc. could be as well public. Technically, anybody could exploit any system, read all the secrets, all without any fingerprints or traces. I wonder how much NSA paid Intel for doing that.

It is live for Linux already. I don't know when it's out for Windows, though.

Check whether your anti virus is compatible with Microsoft's patch, otherwise it may not be pushed out via Windows Update:

https://support.microsoft.com/en-us/help/4072699/important-information-regarding-the-windows-security-updates-released

So where the fuck does it say which AVs are compatible?

It's not that easy, you still need the malicious code to be executed in the first place.

And I doubt the NSA was involved at all. They could never pay them enough to compensate for the effect this will have on their sales.

It was simply a design decision of "page faults will be thrown at retirement anyway so why bother checking?".
Intel probably never changed that because AMD patented the checking iirc and AMD only does it because it prevents bullshit data from being cached and is rather cheap, not because of security concern.

I can understand why Microsoft don't want to disclose it, but some guy made a Google doc to track this information:

https://docs.google.com/spreadsheets/d/184wcDt9I9TUNFFbsAVLpzAtckQxYiuirADzf3cL42FQ/htmlview?sle=true#gid=0

Other links to vendor KBs etc.
https://www.reddit.com/r/sysadmin/comments/7o2h3n/summary_of_useful_links_and_info_for/

Remember that this only works around one vulnerability and more fixes should be coming which decrease performance slightly more.

EDIT: here's Intel's statement https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

That's just the usual trifecta of
"It's not a bug"
"Everyone got it"
"It's not as bad as you think"

For example

actually means "yes you can read kernel data".

Right now the status is:
Variant 1 (Spectre/bounds check bypass):
Patchable, use conditionals instead of branches.
Relies on kernel-mode (so in the OS) interpreters or JITs executing the code so as soon as those are patched it's fixed.
May not even work with default configs on AMD.
Should not affect performance noticeably, especially if you're not using anything that's affected anyway.

Variant 2 (Spectre/branch target injection):
Patchable, don't use indirect jumps or prevent speculation on them or if possible invalidate the branch predictor on a context switch.
Depends on the specific branch predictor (CPU hardware). Intel Haswell has been proven to be affected and ARM says it also affects all Cortex cores. AMD claims theirs won't be vulnerable to it, but they are the only ones that actually know the inner workings of their hardware so it's difficult to verify.
The brute force patch Linux will use for now will affect performance, but I don't know by how much. Future patches might reduce the impact.

Variant 3 (Meltdown/rogue data cache load):
Patchable, flush TLB on every context switch.
Depends on the specific architecture. Might affect anything newer than the Pentium I from Intel (except Itanium and first gen Atom). According to ARM themselves only the Cortex-A75 is affected. AMD claims they are immune and so far it looks like it.
This is the one everyone is talking about. The performance impact depends on what you're doing. Pure number crunching won't see a noticeable change but for example file accesses will slow down rather significantly.
Unlike Spectre where multiple patches may still happen to close new security holes or to lessen the performance impact this will be more or less final. Unaffected CPUs may be added to whitelists later but if your is affected then it's going to stay like this.

Also from the press release

JITs are common in some cases (ex. JavaScript), and don't have to be kernel level. Though, you are right about BPF JIT, which is disabled by default on Linux. Not sure if Windows has its own variant of this.

If Intel wanted to do something about Meltdown(or Spectre for that matter) on an architectural level, would they have to delay a product family like Ice Lake, or would there still be enough time to change it before tape-out if we assumed it would launch in say Q1 2019?

They don't have to be but that doesn't matter.
For the attack to work the executed code needs to be able access the data you want to leak. So if you're not in kernel mode an attack on the kernel will fail because the data is never accessed either a) because the permission check fails (AMD/ARM) or b) because the fix for Meltdown has already flushed the TLB and the adress isn't known.

Sure you can use it to gain access to data in your own process but that's a bit redundant. If your own program contains malicious code and uses it to leak its own data to itself, well, you've achieved nothing.
If you're running untrusted javascript code via JIT in the same process as some sensitive information you might want update your JIT to use conditional bound checks. On the other hand you're running untrusted javascript code via JIT in the same process as some sensitive information so you deserve everything that happens to you.

Spectre isn't really fixable on an architectural level. Even in order cores are affected if the pipeline is long enough.
Ice Lake should have taped out by now. It's a matter of steppings and yields now. Changing when permissions are checked (before the loaded value appears vs at retirement) affects basically the whole CPU and at the point that Intel learned about the flaw they were most likely unable to change it. There's also the matter of AMDs patents so it might be quite a while before they fix it. If I'm correct it would be quite difficult to even get it into Tiger Lake (Ice Lake refresh). If they can still get it fixed on Sapphire Rapids, the architecture after that (2020+), which they are already working on because development takes ~4 years, then they might consider themselves lucky.

ethically probably not

Not sure what the point of this response was, I wasn't trying to disagree with you that extensively, nor does your defense make sense. The possibility of browser exploitation should not be dismissed and the proper preventative measures should be taken to mitigate it. https://support.google.com/faqs/answer/7622138 (see Google Chrome listing)

I wasn't sure where you were going with pointing out that JITs exist outside of the kernel.

Well I wanted to point out the difference between the "shit's on fire" situation that is leaking kernel data from userspace with default configs (Intel) or non-default config or a more sophisticated variation (AMD) and the eternal dumpster fire that is browser security with javascript. Because the former will be fixed soon, the latter will only be fixed when javascript etc. are running in a seperate process. That's the reason why that feature exists.
On second though if this is what it takes to make site isolation the default then sure, go ahead and warn as many as you can.

So this is what ESEA has been using after the Bitcoin fiasco