Meltdown and Spectre Linux kernel status • Hacker News Board

Re: Meltdown and Spectre Linux kernel status

#61

Post by antaviana » Sat, Jan 06, 2018, 5:50 PM UTC

I use AWS instances (multi-tenant). I understand that by now AWS hypervisors have been patched.

Does that fully protect my unpatched AWS instances from this CPU-level issues?

If not, is there any way to protect my AWS instance from a rogue unpatched attacker instance running on the same hypervisor?

In other words, with the current CPUs deployed at AWS, will it be possible for an attacker to simply launch an unpatched instance to steal data from other instances (patched or not) running on the same AWS hypervisor?

I hope not, because the cloud multi-tenant model would be effectively dead until AWS hosts with unaffected CPUs are available.

Re: Meltdown and Spectre Linux kernel status

#62

Post by fizixer » Sat, Jan 06, 2018, 5:52 PM UTC

bonzini wrote: post #52

fizixer wrote: post #32

I'm out of the loop but I heard it's the white hat hackers who exposed the flaw (probably they were at Google?). Is the exposition carefully publicized so the flaw is not exploitable by malicious hackers? Or does Project Zero expose everything, and a malicious hacker can read it and create code that spreads over the internet to harm computers? I hope it's not the second case because that should cause global panic.

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 essentially did not give black hats enough time to fill the missing pieces of the public announcement.

For instance, in the extreme case, the statement "we have discovered a flaw at the hardware/CPU level in such and such chips, and we call it meltdown and spectre", it's pretty obvious the black hats would have no clue what it is. (They may have already discovered it on their own, and may have named the flaws something completely different. Even then they wouldn't know if white-hats discovered what they discovered.)

Re: Meltdown and Spectre Linux kernel status

#63

Post by api » Sat, Jan 06, 2018, 5:55 PM UTC

We applies it to the bare metal DB servers for my.zerotier.com and there is definitely a detectable increase in IO cost. Reducing syscall overhead is going to become even more important.

Re: Meltdown and Spectre Linux kernel status

#64

Post by JdeBP » Sat, Jan 06, 2018, 5:58 PM UTC

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 updates are largely irrelevant to this issue, only being involved in the sense that one way to perform microcode updates is for your machine's firmware to upload the new microcode image file. But that is just one way for that to be done; your operating system can do it, too.

* http://inertiawar.com/microcode/

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

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

Re: Meltdown and Spectre Linux kernel status

#65

Post by craigyk » Sat, Jan 06, 2018, 6:00 PM UTC

lisper wrote: post #48

Xylakant wrote: post #33

Earlier quoted context omitted.

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.

It also consumes lots of CPU to scan memory this way, so just be on the lookout for webpages consuming lots of unexpected CPU.

Re: Meltdown and Spectre Linux kernel status

#66

Post by rhizome » Sat, Jan 06, 2018, 6:05 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.

have you tried dist-upgrade?

Re: Meltdown and Spectre Linux kernel status

#67

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

Tuna-Fish wrote: post #54

lisper wrote: post #48

Earlier quoted context omitted.

> JavaScript ... is a demonstrated attack vector OMG, I didn't know that. Thanks.

JS as an attack vector can be effectively mitigated by denying access to high-precision timers (and a few features that can be used to construct high-precision timers). At least Chrome and Firefox are doing this, so just make sure that you are keeping your browser up to date. If you feel paranoid, you might also want to disable JS by default and only enable by whitelist on any machines that hold particularly sensitiv…

Keeping JavaScript from constructing high-precision timers is going to be a cat and mouse game.

See the "Fantastic Timers" paper. Link to HN discussion: https://news.ycombinator.com/item?id=16080235

Re: Meltdown and Spectre Linux kernel status

#68

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

frazar0 wrote: post #24

fermienrico wrote: post #12

With so much going on - is there a way in linux to know whether my system is patched or not? Similar to the powershell script for Windows?

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

Note that `dmesg` prints from a fixed-size ring buffer, so if your system has significant other output (e.g. if you create and destroy lots of devices or such), it's very possible the boot-time message about page table isolation will have fallen out of the ring buffer.

If you use journald, it by default saves the kernel's ring buffer to disk, so you can use it to check for that message:

sudo journalctl -b -o cat | grep "page table isolation"

Re: Meltdown and Spectre Linux kernel status

#69

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

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 because first it is forbidden and second it is in a branch which will never be executed. At the time of the speculative read the CPU seems not to have enough information to know not to execute that read. Even speculatively.

And that speculative read has a side effect on the cache which is measured by the exploit.

Of course the read is never made visible to the process because later the CPU knows not to bring it into effect. However then it is too late: there is measurable difference in caching times.

Did I understand the way of the attack correctly?

Re: Meltdown and Spectre Linux kernel status

#70

Post by nxc18 » Sat, Jan 06, 2018, 6:08 PM UTC

craigyk wrote: post #65

lisper wrote: post #48

Earlier quoted context omitted.

> JavaScript ... is a demonstrated attack vector OMG, I didn't know that. Thanks.

It also consumes lots of CPU to scan memory this way, so just be on the lookout for webpages consuming lots of unexpected CPU.

In the age of fancy JavaScript webapps, this seems laughable. 2 or 3 tabs in Chrome is enough to turn my laptop into a space heater.