Welp: https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
> A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug.
> Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down.
> A spokesperson for Intel was not available for comment
Weren't they now.
If in an argument I told someone last month "what if there was a bug in the processor design", I would be laughed out the room.
Well. There we go.
@rysiek If bugs didn't exist, I wouldn't have a job. :)
@nicseltzer @rysiek Hear, hear!
@nicseltzer exactly.
@rysiek "It's not a processor bug" is up there with "it's not a compiler bug" - a necessary mantra when learning, right up until what you learn is that, welp, sometimes it is.
@rook @rysiek With things like https://authors.library.caltech.edu/83266/ showing up, I'm less confident in that these days.
@bob and not a kernel oops at that
@rysiek Brilliant ... now I'll have to build my own kernel without this patchset if I want to keep the current performance
@MightyPork current performance and vulnerability, that is. ;)
I mean, if you have a machine that is not Internet-connected, only runs 100% verified software, *and* has only one user, sure. But otherwise not applying this patchset is asking for pain, IMVHO.
@rysiek I really don't believe my home PC will be hit by this - being a Linux and behind multiple layers of ad-blockers and filters. For things like shared hosting though, it's a very different story
@MightyPork My gut feeling is: yes your home PC will be hit by this, *unless* it is disconnected from Teh Intertubes and runs 100% verified software. :)
This seems to be a bug that allows userland to read kernel memory. I.e. your adblocker could be reading your kernel memory.
But I am happy to be proven wrong.
@MightyPork so, "nopti" kernel arg is now a thing:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5aa90a84589282b87666f92b6c3c917c8080a9bf
@rysiek that article is so misleading and ambiguous that i literally cant even. I assume their talking about the MMU timing attack from CCC? That affects EVERY architecture tested. Table look up timing attacks are a thing
@Fuego It is not clear to me what they are referencing. Their analysis seems fine-ish to me, based on available info. I mean, the bug is under embargo, AMD claims it's not affecting their CPUs... lying about that would be a really bad idea.
What are the misleading parts?
@rysiek I’m implying they have no idea what the consequences and probable fixes are of the bug not that they are lying. If they are referencing the MMU timing attack which much of it makes me think they are, then the misleading parts are all of it.
They way they portray it is nonsensical. They dont understand when kaslr is and is not useful....
@Fuego @rysiek The original blog post is way better written than The Reg's breathless ripoff of it.
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table
@rysiek The patches look like they are protecting against the mmu attack only for kaslr when it is useless anyhow and not user space aslr where it is useful.
It is NOT paging out the kernel. This attack is present in amd but not across rings.
The entire article is a fuck. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5aa90a84589282b87666f92b6c3c917c8080a9bf
@Fuego thanks!
@rysiek it seems like they are mistaking an attack that tells you only if a page happens to be mapped or not at a given virtual memory address with an arbitrary kernel memory peek. The attack is the former and not very severe or useful.
@rysiek It's a wonder computers work at all.🙃
@davidk01 do they, though? Do they?.. ;)
@rysiek i wouldn't want to be available for comment either...
@twitter I would definitely be available for drinks, however.
@rysiek how many drinks to put the pr spin on things?
@twitter all of them
@rysiek Good lord. That and Management Extensions.
But it's funny how the cloud systems are scrambling to fix this when the owner of the cloud can still read everyone's kernel RAM. Somehow THAT huge security hole doesn't worry the cloud owners.
@natecull they are the ones who can read RAM so why do they care?
They do care about cloud users being able to read kernel mem though, for obvious reasons.
@Wolf480pl @rysiek There ARE claimed ways (from the chipmakers, eg Intel) of putting 'secure enclaves' into the chips such that the owners of the hardware CAN'T access RAM, even in Ring 0 or -1 or whatever hypervisors / Intel ME gives access to.
But, um. One, how much do we trust the chipmakers? And two, how do we get encrypted data into and out of this 'secure RAM' through insecure RAM?
It's maybe possible, but it seems really awkward, and still a big trust point being the chip makers.
@Wolf480pl @rysiek Yep. It all just seems like piling on more and more complexity to solve an unsolveable problem.
Corporations want cheap cheap compute!
They also want privacy, or *should*.
It's hard. More and more businesses just don't want to run their own physical datacenters. Air conditioning and power costs a lot. They just want to make the whole cost center go away. Amazon's right there.
We've kinda gone right back to the IBM days, now with Amazon as IBM.
@rysiek but intel will still get the biggest market share because MUH SPEED
@rysiek
Bad year to be an Intel user... 
Also, another *Very* good reason to use bare metal whenever possible.
> There were rumors of a severe hypervisor bug – possibly in Xen – doing the rounds at the end of 2017. It may be that this hardware flaw is that rumored bug: that hypervisors can be attacked via this kernel memory access cockup, and thus need to be patched, forcing a mass restart of guest virtual machines.