Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meltdown and Spectre Linux kernel status

kroah.com

Post reply on HN
Print view View original

151–160 of 186 posts

Re: Meltdown and Spectre Linux kernel status

#151

Post by cookiecaper »

ComputerGuru wrote: post #37
chucky_z wrote: post #22

Earlier quoted context omitted.

I think it's naive to think you're completely protected just because code isn't supposed to ever run. It seems as though the simplest and safest piece of mind is to use some extra layers of protection ala SELinux. This won't stop the memory from being accessed, but it has a better chance of stopping things that can exploit the bug(s) in the first place. Revoking TLS certs is probably a little bit on the side of paran…

It’s naive to assume that your system is perfectly secure in preventing unauthorized code from running. But that’s just in general. He is right, though. It would take two vulnerabilities to pwn him: one allowing remote code execution and then another (Spectre/Meltdown) to gain access to privileged data that shouldn’t be available in that context. Too many machines put on too many hats. A single (physical) “secure” se…

Things are definitely getting lost in the panic here. It's going to take several weeks for everyone to get their head on straight, but yes, PTI is only going to be justified in certain situations, and if you don't allow untrusted code to run on your system (most servers), you will probably be fine with just your host CPU patched because no one will get the chance to run the exploit.

Of course, if an attacker uses a remote execution vulnerability to get into the box with user-constrained permissions, this can be used to read guest memory without concern for user limitation, so in that way it's a long-term pernicious threat that will make local exploitation significantly easier, and security-conscious organizations will still opt to use it despite the fact that they don't run untrusted code. Also, since this would allow them to read all memory in the guest, if you have sensitive stuff like database credentials coming into memory, they could be sniffed without requiring further exploitation.

Also, consider that at present, PTI is disabled by default for AMD chips, based on AMD's assurances that Meltdown does not affect them. If you're running in the cloud and your host is AMD-based, you don't need PTI in either the guest or the host.

Re: Meltdown and Spectre Linux kernel status

#152

Post by amluto »

ghaff wrote: post #150
macdice wrote: post #140

Earlier quoted context omitted.

It will be pretty unfortunate if it turns out that the projects that maintain a kernel (FreeBSD, various others) only received notification at Christmas, while various Linux distros (who have to deal with packaging, release, QA but not developing their own kernel patch since that comes from upstream) got a long warning period. It seems that way... Looking forward to reading about how this played out when the dust set…

There is basically no independent upstream (other than a handful of people). Essentially all the kernel developers work for the companies that have distros plus organizations like Intel, Qualcomm, etc. that do a lot of device enablement.

I agree in general. In this particular case, though, a good fraction of the work was done by me and tglx. I'm independent. Tglx is sort of independent.

This is not to diminish the work done upstream by less independent people. Dave Hansen, in particular, is the one who actually got the code to function.

Re: Meltdown and Spectre Linux kernel status

#153

Post by Gracana »

tenken wrote: post #148
Gracana wrote: post #112

Earlier quoted context omitted.

I really dislike the term "responsible disclosure" in this context. I might consider it responsible to notify a software vendor about a vulnerability in their software so they have a chance to issue a fix to their customers before the rest of the world finds out. But this situation is different. These vulnerabilities affect everyone, and only a special few were allowed to prepare in advance. That's just preferential…

The lay public, aka everyone, isn't considered to be experts in this domain to address the issues. Hence, they disclosed to top tier OS distributions and partners. It's similar to the Recalls of Takanas airbags in this regard. The manufacturers are informed and they tell us the consumer to bring in our cars. I'm not qualified to replace an explosive airbag, even though I drive a car daily as a lay person.

There are other OSes and affected companies beyond the ones who were chosen to receive advance warning.

Imagine how it would work out in your airbag analogy if only Toyota and GM knew, and they withheld information for months while they worked on their own fixes, meanwhile the public remains in danger and other automakers have no chance to implement their own recall plans.

Re: Meltdown and Spectre Linux kernel status

#154

Post by pkaye »

Gracana wrote: post #153
tenken wrote: post #148

Earlier quoted context omitted.

The lay public, aka everyone, isn't considered to be experts in this domain to address the issues. Hence, they disclosed to top tier OS distributions and partners. It's similar to the Recalls of Takanas airbags in this regard. The manufacturers are informed and they tell us the consumer to bring in our cars. I'm not qualified to replace an explosive airbag, even though I drive a car daily as a lay person.

There are other OSes and affected companies beyond the ones who were chosen to receive advance warning. Imagine how it would work out in your airbag analogy if only Toyota and GM knew, and they withheld information for months while they worked on their own fixes, meanwhile the public remains in danger and other automakers have no chance to implement their own recall plans.

Can you mention which OS didn't get early enough warning? I'm sure there is some niche ones which may miss out but they are usually not the target of hacking either. And many of the derivative Linux distributions don't do active kernel development and just compile the stock kernel or derive from Red Hat, Ubuntu or others. The more people that are informed early, the more likely it will leak out early.

Re: Meltdown and Spectre Linux kernel status

#155

Post by kazinator »

Xylakant wrote: post #33
lisper wrote: post #26

Someone please correct me if I'm wrong, but both spectre and meltdown seem to me to be local root exploits, not remote vulns. They can be used to break out of (say) a VM into the host hypervisor, and thence into other VMs running on the same hardware, but cannot be used to break into a machine from outside its hardware perimeter. Is that right?

Essentially yes, the exploits require code running on the machine that’s attacked. However, for example JavaScript runs on the local machine and is a demonstrated attack vector. It’s also strictly speaking not a privilege escalation, it’s “see things you’re not supposed to.”, such as all sorts of secrets. The attacker does not gain any write or execution privileges, though.

If one of the secrets you see is the contents of a buffer containing a password, it might then be a privilege escalation.

Re: Meltdown and Spectre Linux kernel status

#156

Post by Gracana »

pkaye wrote: post #154
Gracana wrote: post #153

Earlier quoted context omitted.

There are other OSes and affected companies beyond the ones who were chosen to receive advance warning. Imagine how it would work out in your airbag analogy if only Toyota and GM knew, and they withheld information for months while they worked on their own fixes, meanwhile the public remains in danger and other automakers have no chance to implement their own recall plans.

Can you mention which OS didn't get early enough warning? I'm sure there is some niche ones which may miss out but they are usually not the target of hacking either. And many of the derivative Linux distributions don't do active kernel development and just compile the stock kernel or derive from Red Hat, Ubuntu or others. The more people that are informed early, the more likely it will leak out early.

My particular interest is in OpenBSD, which was not included.

Re: Meltdown and Spectre Linux kernel status

#158

Post by mackal »

Gracana wrote: post #156
pkaye wrote: post #154

Earlier quoted context omitted.

Can you mention which OS didn't get early enough warning? I'm sure there is some niche ones which may miss out but they are usually not the target of hacking either. And many of the derivative Linux distributions don't do active kernel development and just compile the stock kernel or derive from Red Hat, Ubuntu or others. The more people that are informed early, the more likely it will leak out early.

My particular interest is in OpenBSD, which was not included.

There is some drama over OpenBSD and KRACK that may have been why they didn't get told. But that is just pure speculation.

Re: Meltdown and Spectre Linux kernel status

#159

Post by agumonkey »

DSMan195276 wrote: post #85
_nalply wrote: post #69

From my cursory reading I understand it is a cleverly orchestrated timing attack. In other words, if something would need 500 picoseconds you have bit 1, if it is 250 picoseconds instead it is bit 0 (numbers pulled out of thin air). This is made possible because processors execute the read speculatively even if it is actually forbidden. This read causes a cache hit. Of course the read is never brought into effect bec…

Yes, you understand it correctly. The bug is really just that cache hits that are caused by speculative execution do not get invalidated. This is technically a bit of a speed-up, but it leaves information behind about the speculative execution that took place. It is also worth understanding the differences between Spectre and Meltdown, since they are distinct. Spectre refers to reading process memory via measuring ca…

so the perf hit comes from a mandatory cache invalidation instruction added by the patch ?

Re: Meltdown and Spectre Linux kernel status

#160

Post by [deleted] »

Xylakant wrote: post #130
keyme wrote: post #119

Earlier quoted context omitted.

They do apply to WASM. However, these mitigations are hardly air tight. I'd expect new exploits anyways.

All that these mitigations did was disable all obvious precise timers. All you need for a new attack is a novel way to create a precise timer. And since it’s now known how valueable such a timer would be, I’m certain that minds more clever than me will take a shot at this.

[deleted]
Post reply on HN