In an email to the Linux kernel mailing list over Christmas, AMD said it is not affected. The wording of that message, though, rather gives the game away as to what the underlying cockup is:

AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

A key word here is "speculative." Modern processors, like Intel's, perform speculative execution. In order to keep their internal pipelines primed with instructions to obey, the CPU cores try their best to guess what code is going to be run next, fetch it, and execute it.

It appears, from what AMD software engineer Tom Lendacky was suggesting above, that Intel's CPUs speculatively execute code potentially without performing security checks. It seems it may be possible to craft software in such a way that the processor starts executing an instruction that would normally be blocked – such as reading kernel memory from user mode – and completes that instruction before the privilege level check occurs.

That would allow ring-3-level user code to read ring-0-level kernel data. And that is not good.

The specifics of the vulnerability have yet to be confirmed, and this discussion of its severity is – aptly enough – speculation, but consider this: the changes to Linux and Windows are significant and are being pushed out at high speed. That suggests it's more serious than a KASLR bypass.

Meltdown only affects Intel though.

Spectre doesn't even have patches for it. RIP.

Hardware support for branch target injection mitigation is present: True/False    

This side-channel can be used to determine the values held in system registers that should not be accessible. While it
is undesirable for lower exception levels to be able to access these data values, for the majority of system registers,
the leakage of this information is not material.

Sources from the deep saying that thousands of hackers and evil coders are now crafting their pieces to re-produce Spectre as we speak. Expect chaos for the upcoming months. Intel CEO sold his shares already. LOL.

Spectre is definitely not theoretical, their release included PoC code in both C and Javascript. IMO this is realistically only a real threat for the NodeJS/Javascript/Browser-JS/etc communities where running third-party/untrusted code is a regular practice (think of the npm ecosystem, haha, scary stuff). Spectre gives me access to _my own process' memory_, so if you can imagine being able to arbitrarily dump your own memory, well there you have it. In most cases, including all of my own, I already have access to my own memory in my running processes, which is why this isn't a concern. In the Javascript/NPM (and several others of course), where running other people's code in your process space (or in their PoC case, a browser running JS) you can see that being able to access the parent process memory could be a bad thing security-wise.

Meltdown however is an entirely more scarier thing IMO. I spent yesterday doing a preliminary once-over (since they haven't yet released PoC code for it). I'll summarise by saying: Meltdown gives an unprivileged user the ability to dump the entirety of physical RAM in a machine, bypassing ring0/ring3 protections.

In saying that, I wrote a test case for it and was unable to reproduce it thanks to my missing what they call a "precondition" that is required, which they suggest in a roundabout-way is that the kernel/target memory must reside in the L1 cache in order to circumvent the "race condition" between speculative execution and the privilege check and subsequent interrupt/error/fault. I am still working on it

In summary, Meltdown is way way worse but I have yet to reproduce it...

Reading the whole physical memory is possible without Meltdown and Spectre: one just needs to gain administrator privileges and there’re much easier ways relying on software bugs only, which is more reliable than trying to sneak into a small time window hoping something useful will be in RAM.

The bugs can definitely make some attacks easier but don’t really allow them on their own: one still needs quite strong preconditions (most of which are actual security vulnerabilities). So, I consider them overrated.

I consider that browser JS reading memory to be a very serious problem. There are many things kept in kernel memory that you shouldn't be happy about anyone knowing. Encryption keys are the most prominent target, but also various buffers and whatnot that no website has any business knowing.

And some random code that you download shouldn't have access to other memory either. Not many people can, or do, audit the outgoing data connections so exfiltrating data is usually not a problem for any malicious program.

Spectre doesn't even rely on bugs, in fact it relies on stuff like array bound checks, which is considered "good" code practice. (I wonder if the bound instruction (32-bit only) would help here, if it wasn't so slow)

As for the administrator privileges, privilege escalation exploits are rarer and harder to exploit, usually they also take a lot of time to "warm up" which is noticeable. And they can be patched easily without any performance degradation.

And like I said, I can’t agree that JS case is about Meltdown and Spectre. Browser, in fact, gets source code in a managed language that normally doesn’t allow direct access to any particular address. If, after just-in-time compiling the code, we can reliably produce accesses to arbitrary places in memory, we’ve already lost even before the CPU bugs were discovered.