Meltdown and Spectre Linux kernel status • Hacker News Board

Re: Meltdown and Spectre Linux kernel status

#71

Post by JdeBP » Sat, Jan 06, 2018, 6:09 PM UTC

weinzierl wrote: post #57

> If you rely on any other kernel tree other than 4.4, 4.9, or 4.14 right now, and you do not have a distribution supporting you, you are out of luck. So, if you are running a (still supported) Debian Jessie a simple apt-get upgrade isn't gonna cut it:-(

As the Debian announcement says:

* https://lists.debian.org/debian-security-announce/2018/msg00... (https://news.ycombinator.com/item?id=16076175)

It's not the only operating system where the process is slightly more complex than a kernel update. Windows NT updates require the coöperation of other softwares on one's machine. (-:

* https://news.ycombinator.com/item?id=16076660

Re: Meltdown and Spectre Linux kernel status

#72

Post by nebulous1 » Sat, Jan 06, 2018, 6:09 PM UTC

fermienrico wrote: post #38

frazar0 wrote: 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 say they will release a patch on or before the 9th of January.

They got caught out by the embargo being ended early.

Re: Meltdown and Spectre Linux kernel status

#73

Post by nvus » Sat, Jan 06, 2018, 6:09 PM UTC

A good way Intel could say sorry is to have a new generation hardened cpus at a good price.

Re: Meltdown and Spectre Linux kernel status

#74

Post by frik » Sat, Jan 06, 2018, 6:10 PM UTC

JdeBP wrote: post #64

Santosh83 wrote: post #36

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…

The microcode updates that people have been mentioning are not updates to your motherboard's firmware, EFI or otherwise. They are updates to the code that runs inside your central processor chip , the so-called microcode , that does the work of understanding and enacting processor instructions (in all programs, from the programs in your firmware to the programs that you download and run from the WWW). Firmware update…

As I understand the microcode updates get installed by Linux distros and Windows by updates. Microcodes are loaded by the CPU at every boot.

The question is, how can one check if the CPU already got the microcode update?

Can a OS running inside a VM (over Intel VT ring-1) patch the CPU's microcode? (e.g. Linux host, and Win guest patches CPU's microcode) Nothing seems impossible anymore.

Re: Meltdown and Spectre Linux kernel status

#75

Post by antod » Sat, Jan 06, 2018, 6:10 PM UTC

ComputerGuru wrote: post #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.

It's not supposed to install via "apt upgrade", as that command won't pull in new packages or remove packages. Unlike most, kernel packages can co exist so they are all separate packages. Thus need the extra "apt-get dist-upgrade" or "apt full-upgrade" variants as they are new dependencies.

Re: Meltdown and Spectre Linux kernel status

#76

Post by ghaff » Sat, Jan 06, 2018, 6:14 PM UTC

fizixer wrote: post #62

bonzini wrote: post #52

Earlier quoted context omitted.

It's closer to the second, but: 1) the vulnerability is local, not directly tied to spreading as malware (but these days placing JavaScript in an ad is easier and possibly more effective than a virus...) 2) there is no such thing as "exposition carefully publicized so the flaw is not exploitable by malicious hackers". Just assume that black hats are as smart as white hats or smarter.

> 2) there is no such thing as "exposition carefully publicized so the flaw is not exploitable by malicious hackers". Just assume that black hats are as smart as white hats or smarter. You're missing the point. Not doubting the smartness of black hats, white hats likely took their time to discover the flaw. If you make the details public in a controlled manner and then announce the fixes shortly after, you essentiall…

For one thing, the fixes are up in the Linux kernel for anyone to see.

Re: Meltdown and Spectre Linux kernel status

#77

Post by mwalser » Sat, Jan 06, 2018, 6:15 PM UTC

weinzierl wrote: post #57

> If you rely on any other kernel tree other than 4.4, 4.9, or 4.14 right now, and you do not have a distribution supporting you, you are out of luck. So, if you are running a (still supported) Debian Jessie a simple apt-get upgrade isn't gonna cut it:-(

The debian security announcement for stretch says

> For the oldstable distribution (jessie), this problem will be fixed in a separate update.

You can check https://security-tracker.debian.org/tracker/CVE-2017-5754 whether the KPTI patch has been released for jessie.

Re: Meltdown and Spectre Linux kernel status

#78

Post by codys » Sat, Jan 06, 2018, 6:21 PM UTC

> As for how this was all handled by the companies involved, well this could be described as a textbook example of how NOT to interact with the Linux kernel community properly. The people and companies involved know what happened, and I’m sure it will all come out eventually

I'm looking forward to that story.

Re: Meltdown and Spectre Linux kernel status

#79

Post by JdeBP » Sat, Jan 06, 2018, 6:25 PM UTC

_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…

Timing the L1 cache response for speculatively fetched data that one could not normally access is just one of the problems. It's the one that it is easiest to explain, and it's also the one that the few operating system writers who were told about this tackled first. Hence it is the one that is getting the focus in many discussions.

* https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne... (https://news.ycombinator.com/item?id=16080002)

* https://dev.to/isaacandsuch/how-meltdown-works-28j2 (https://news.ycombinator.com/item?id=16085592)

One of the other problems is tricking the branch predictor into speculatively jumping into code of one's choosing.

* https://newsroom.intel.com/wp-content/uploads/sites/11/2018/... (https://news.ycombinator.com/item?id=16079910)

Re: Meltdown and Spectre Linux kernel status

#80

Post by [deleted] » Sat, Jan 06, 2018, 6:28 PM UTC

fermienrico wrote: post #38

frazar0 wrote: 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]