Hacker News Reader

Comment by revelation | Hacker News Reader

No ones hiding anything, this patchset was developed in the open for many many months. The hysteria and intrigue in this random tumblr blog is completely superfluous. It's a hardware bug anyway.

Here is a good hint to when something is not being embargoed: there is a paper and a public demonstration.

View on HN

The patchset being developed in the open, and the rationale for the development being done in the way it is, are two very different things.

But no one is hiding the bug this "fixes". If this bug + something else can be a hypervisor escape, well that's too bad for the AWS of this world, but I don't see how this patchset would leak the "something else" we don't know about?

It's not unusual for folks implementing popular OSs to get heads up that some sort of Significant Security Issue is being discussed by other vendors, including receiving advice.

I consider this newsworthy because many very good security engineers in my feed agree it is.

No, not AWS. Xen was called safe. All the other KVM providers and normal linux servers in Intel are called out. arm, sparc, s390 were called out as safe, as they provide two seperate translation table registers, only intel provides only one.

I don't think ARM64 works the way you think it does. On s390, there's a register for user-initiated access and a register for kernel-initiated access. On ARM64 (AIUI), there's a register for low (user) addresses and a register for high (kernel) addresses. So kASLR timing leaks on s390 shouldn't happen in the first place unless the TLB tagging itself is rather silly, but ARM64 has no inherent protection.

What ARM64's system does provide is a much simpler way to do a PTI-style pagetable split by twiddling the high address register at entry and exit.

Isn’t Amazon moving off of Xen? Perhaps their involvement is limited to those working on their new KVM-based hypervisor? They also recently dropped their dedicated host requirement for HIPAA customers (to catch up with GCP).

What do you think this fixes? Tiny info leak about kernel addresses? There are still other more reliable ways to get that (even if there is active work to remove those), and I don't believe this would yield to a semi-rushed patch with 5% mean and sometimes 30% performance degradation impact enabled by default, with Linus himself expecting to be backported (rarely to never seen on a change of this importance, and would make no sense given older kernels are even more full of simpler kaddr info leak)

This fixes something bigger than Intel could not fix by microcode update...

Will you apologize for saying this if an embargo is lifted? It seems very likely to me that there is an embargo.

Looks like I'm apologizing. Sorry, I was wrong.

Where is the paper and public demonstration in this case?

https://gruss.cc/files/kaiser.pdf

As the article says, rushing through a change this large with a performance penalty just to fix KASLR is very unlikely. KASLR is a fairly weak protection that has been broken many times (particularly on Windows – and yet Windows is still rolling out a similar patch).

Its even worse than that. KASLR is only a mitigation, not an architectural protection (and "breaking KASLR" does not gives you an exploit by itself, you have to find another bug), so there is absolutely no way Linus would consider that just fixing KALSR command the (somehow rushed) inclusion of this patch, moreover enabled by default...

It sounds like Intel, Google and Amazon are hiding something. Wouldn't want customers thinking that cloud computing is fundamentally insecure now would we?

Well Intel for one manufactures the insecure CPUs..

This will be merged for 4.16, when there is no 4.15 release yet. No idea what your cloud computing companies run but it's not 4.15-dirty, and backporting this monster is a great recipe for a nightly emergency when it goes OOPS.

edit: it isn't even merged yet.

It is being backported to 4.14, and presumably earlier kernel too.

Sure, with the appropriate baking time. But I don't see a cloud company taking an intermediate version of this patchset, backporting it themselves and then sending it out to all their customers in a hurry.

Why not? Isn't that what they should do in case of a kernel security issue?

Yep. The kernel maintainers are being so aggressive with this that I'll be very concerned if there isn't a major security issue coming down the pipe. I know that Linux is considered fast and loose in various circles of old-school hackers, and granted, but merging this type of fundamental change into stable is not normal. There's something brewing here that is pushing this to completion.

Like the backports here?

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

Go test!

I agree, they're very scary. Also, watch out: a kernel with PTI on will not function in KVM-emulated secure boot mode until a KVM fix gets backported as well.

Some of these patches are already on stable marked kernels. In fact, I'm already running them. There was also an issue where some different default GCC flags hardened gentoo uses was causing the kernel to not be able to boot.

If it is hardware Microsoft also will be patching.

They did - the article mentioned it several times.

https://twitter.com/aionescu/status/930412525111296000

Reply on news.ycombinator.com