Live data from Hacker News

Meltdown and Spectre Linux kernel status

kroah.com

41–50 of 186 posts

Re: Meltdown and Spectre Linux kernel status

#41
This just reminded me: when will Ubuntu (and Debian?) fix apt’s broken kernel update process? I have never seen a kernel update - security or otherwise - installed via a normal “apt update; apt upgrade” on any of our machines, it’s always “the following updates have been held back” and then it’s time to manually use dpkg to install the relevant updates.

Re: Meltdown and Spectre Linux kernel status

#42
post #35

Earlier quoted context omitted.

No, he shouldn’t be seeing that regardless as it doesn’t match the grep regex. I don’t know what, though. Edit: facepalm. Or should that be foot-in-mouth?

It does match the regex. "pti" is a substring in "exception"

Thanks. I feel stupid, I looked that line up, down, and sideways for a match :/

Re: Meltdown and Spectre Linux kernel status

#43
post #24

Earlier quoted context omitted.

A number of ways are listed here [1] 1. With dmesg dmesg -wH | grep 'page tables isolation' 2. With /proc/cpuinfo grep cpu_insecure /proc/cpuinfo && echo "Patched" || echo "Unpatched!" [1] https://askubuntu.com/questions/992137/how-to-check-that-kpt...

Thanks. So apparently, my system: Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-104-generic x86_64) is unpatched! Is it because of LTS version? Most servers run this including mine.

Ubuntu has not released kernel updates for this issue yet.

Re: Meltdown and Spectre Linux kernel status

#44
post #24

Earlier quoted context omitted.

A number of ways are listed here [1] 1. With dmesg dmesg -wH | grep 'page tables isolation' 2. With /proc/cpuinfo grep cpu_insecure /proc/cpuinfo && echo "Patched" || echo "Unpatched!" [1] https://askubuntu.com/questions/992137/how-to-check-that-kpt...

Thanks. So apparently, my system: Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-104-generic x86_64) is unpatched! Is it because of LTS version? Most servers run this including mine.

[deleted]

Re: Meltdown and Spectre Linux kernel status

#45
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?

My understanding is that they require execution on the machine and even systems like node are vulnerable(https://react-etc.net/page/javascript-spectre-meltdown-faq) The big issues is that this is really hard to detect because it blends with what would be normal code patterns. I have read that AV will have trouble with this in heuristics but may pick up on specific strains of code that utilize it. Plus this is a whole new class of vulnerability that people have not thought about yet, it will be interesting, can I make your server do X to expose this(think Heartbleed)

Re: Meltdown and Spectre Linux kernel status

#46
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?

Yes, but arbitrary code execution exploits are some of the most commonly found. If your system interacts with the outside world, or is a multi user system, I would consider it prudent to protect against both Meltdown and other Spectre class exploits whenever possible.

Re: Meltdown and Spectre Linux kernel status

#47

This just reminded me: when will Ubuntu (and Debian?) fix apt’s broken kernel update process? I have never seen a kernel update - security or otherwise - installed via a normal “apt update; apt upgrade” on any of our machines, it’s always “the following updates have been held back” and then it’s time to manually use dpkg to install the relevant updates.

“apt full-upgrade” will upgrade everything. It may also remove packages to fix higher priority dependencies, though I’ve never seen this happen in real life.

Re: Meltdown and Spectre Linux kernel status

#48
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.

> JavaScript ... is a demonstrated attack vector

OMG, I didn't know that. Thanks.

Re: Meltdown and Spectre Linux kernel status

#49

What I'd like to know is how effective are these OS updates (both Linux and Windows) without the associated firmware updates through microcode or BIOS/UEFI flashing. My system is a few years old and I don't expect the OEM to release BIOS/UEFI updates for this model. Will the OS/microcode update still at least partially protect me or will I have to be super-paranoid about apps and javascript for the remainder of this…

I share your concern. Based on my admittedly loose understanding, although the Spectre vulnerability is "more difficult" to exploit, I suspect it's a matter of time before exploits become more common. And the Spectre vulnerability is the one that requires a BIOS/firmware update.

So that's a bit alarming for me since at least one of my several workstations is using a 5+ year old desktop board (an Intel board, ironically) that has been end-of-lifed according to its BIOS downloads support page. Meanwhile, some of the bigger server motherboard vendors (e.g., SuperMicro) are not yet prepared to supply firmware updates for recent motherboards.

Recognizing that the operating system vendors/maintainers are not responsible for our systems' BIOS and hardware, the flippant advice to "talk with your device's vendor" gives me a sinking feeling. (E.g., Microsoft: "Consult with the device manufacturer about the firmware version that has the appropriate update for your CPU.") As a technical person, I am going to find it difficult to bring all of my hardware—especially the older hardware—up to snuff for coping with these vulnerabilities. I fear for people who are less technically inclined.

Post reply on HN