Meltdown - Intel CPU design flaw affecting all OS platforms

Head_on_a_Stick · 2018-01-10 06:50:06

jr2 wrote:

so there's nothing in the pipeline for 32bit?

I have absolutely no idea, sorry.

Perhaps ask on the mailing lists?

I don't even have any 32-bit hardware to test, unfortunately.

Sun For Miles · 2018-01-10 09:18:49

Head_on_a_Stick wrote:

In other news: jessie is fixed
Update && upgrade everybody!

Woohoo! Finally a good reason to restart my workstation.

che@lab:~$ grep PAGE_TABLE /boot/config-$(uname -r)
CONFIG_PAGE_TABLE_ISOLATION=y
che@lab:~$ uname -r
3.16.0-5-amd64
che@lab:~$

obscurant · 2018-01-10 19:33:33

Head_on_a_Stick wrote:

32-bit systems are exploitable so yes, they are twisting
In other news: jessie is fixed
Update && upgrade everybody!

My system won't boot to the desktop after this update. It gets to the login and stops at an empty terminal screen.

Booting into kernel 3.16.0-4 works fine though. It's 3.16.0-5 that has the issue.

Should I try removing and reinstalling the newer kernel? Tips on how to do that correctly?

ohnonot · 2018-01-10 20:56:38

stevep wrote:

What's the thinking about 32-bit users? The KPTI patches only work on the 64-bit kernel, and processors in 32-bit mode still do the same speculation, right? So are they just twisting in the wind for now?

is it possible to get some definite info on this (i did try)?
i have a 32bit jessie machine. it now is updated to the 3.16.51-3+deb8u1 kernel that is marked fixed on this list.
on that page, i see no indication that it would apply only to 64bit systems?
i also had a quick look on the meltdown paper, nothing on '32' there either.

i see no indication that the fix wouldn't apply to 32bit systems.

Head_on_a_Stick · 2018-01-10 21:54:55

obscurant wrote:

My system won't boot to the desktop after this update. It gets to the login and stops at an empty terminal screen

Can you switch to another TTY (<Ctrl>+<Alt>+F3) and login from there?

Does the desktop start normally if you run `startx`?

ohnonot wrote:

i see no indication that the fix wouldn't apply to 32bit systems

Can you please share the output of

grep TABLE_ISO /boot/config-$(uname -r)

If this is an Arch system then post

zgrep TABLE_ISO /proc/config.gz

Thanks!

glittersloth · 2018-01-10 22:04:57

ohnonot wrote:

stevep wrote:
What's the thinking about 32-bit users? The KPTI patches only work on the 64-bit kernel, and processors in 32-bit mode still do the same speculation, right? So are they just twisting in the wind for now?
is it possible to get some definite info on this (i did try)?
i have a 32bit jessie machine. it now is updated to the 3.16.51-3+deb8u1 kernel that is marked fixed on this list.
on that page, i see no indication that it would apply only to 64bit systems?
i also had a quick look on the meltdown paper, nothing on '32' there either.
i see no indication that the fix wouldn't apply to 32bit systems.

Maybe this; https://github.com/speed47/spectre-meltdown-checker

obscurant · 2018-01-10 22:25:15

Head_on_a_Stick wrote:

obscurant wrote:
My system won't boot to the desktop after this update. It gets to the login and stops at an empty terminal screen
Can you switch to another TTY (<Ctrl>+<Alt>+F3) and login from there?
Does the desktop start normally if you run `startx`?

No, it's a black screen (with only a blinking terminal cursor), that accepts no input. I can only ctrl-alt-del to reboot.

I didn't try a different TTY though.

edit: TTY worked, used startx and was able to see that the NVIDIA kernel module fails to initialize.

IMO, I somehow borked the kernel, and reinstalling it would probably fix the issue.

Last edited by obscurant (2018-01-10 22:34:24)

Head_on_a_Stick · 2018-01-10 22:36:46

obscurant wrote:

the NVIDIA kernel module fails to initialize

If you are not using the stock nouveau drivers or the NVidia drivers from the Debian repositories then you will have to reinstall the drivers every time the kernel is updated.

I would strongly recommend sticking with the nouveau drivers unless you have a specific requirement for the non-free version as the latter can be quite troublesome.

obscurant · 2018-01-10 23:47:34

Head_on_a_Stick wrote:

obscurant wrote:
the NVIDIA kernel module fails to initialize
If you are not using the stock nouveau drivers or the NVidia drivers from the Debian repositories then you will have to reinstall the drivers every time the kernel is updated.
I would strongly recommend sticking with the nouveau drivers unless you have a specific requirement for the non-free version as the latter can be quite troublesome.

Thanks. I manually install the non-free drivers. Haven't tried nouveau drivers yet, as the non-free have worked so well. About the only plus with it is getting the GPU output in conky, which has served no real purpose.

ohnonot · 2018-01-11 20:29:27

Head_on_a_Stick wrote:

Can you please share the output of
grep TABLE_ISO /boot/config-$(uname -r)
If this is an Arch system then post
zgrep TABLE_ISO /proc/config.gz
Thanks!

thanks.
on archlinux, i get "CONFIGPAGETABLE_ISOLATION=y", on my 32bit jessie with

uname -rv
3.16.0-5-686-pae #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08)

i get nothing

glittersloth wrote:

Maybe this; https://github.com/speed47/spectre-meltdown-checker

sudo ./spectre-meltdown-checker.sh 
Spectre and Meltdown mitigation detection tool v0.27

Checking for vulnerabilities against live running kernel Linux 3.16.0-5-686-pae #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) i686

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO 
> STATUS:  VULNERABLE  (only 23 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  NO 
*   Kernel compiled with a retpoline-aware compiler:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  NO 
* PTI enabled and active:  NO 
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer

i'm guessing it's still vulnerable, despite the kernel being updated (and marked fixed)?

problem is, i still don't have any hard info on this.

Head_on_a_Stick · 2018-01-12 06:58:54

ohnonot wrote:

on my 32bit jessie with
uname -rv
3.16.0-5-686-pae #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08)
i get nothing

Best stick to that PineBook from now on then, eh?

Last edited by Head_on_a_Stick (2018-01-12 07:05:43)

martix · 2018-01-12 13:07:05

Don't we all just love Intel? ]:D 8o ]:D

Look at the recent news: "Finnish firm detects new Intel security flaw - the flaw had nothing to do with the "Spectre" and "Meltdown" vulnerabilities recently found in the micro-chips that are used in almost all computers, tablets and smartphones today. Rather, it was an issue within Intel Active Management Technology (AMT), which is commonly found in most corporate laptops, and allows an attacker to take complete control over a user's device in a matter of seconds."

There is a simple AMT check code here.

ohnonot · 2018-01-13 08:38:26

Head_on_a_Stick wrote:

ohnonot wrote:
on my 32bit jessie with
uname -rv
3.16.0-5-686-pae #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08)
i get nothing
Best stick to that PineBook from now on then, eh?

This is a real problem.
Given your obsession with computer security (and your position of responsibility at these forums), I don't understand how you can joke about it.
Also, it isn't even funny.

on topic:
i spent a half hour searching the web for references to meltdown, its fix for linux, and 32 bit architecture.
there's very little hard info, and not much opinion either.
here's what i think is the situation:

meltdown affects all intel cpus since 1995 - that must include 32 bit architecture => 32bit computers are vulnerable.
the kernel fix applies to 64bit architectures only.
it is unclear whether a (different) fix for 32bit is possible, whether someone's working on it or even considering it a priority.
in addition to the kernel mentioned above, i tried Linux 4.9.0-0.bpo.5-686-pae #1 SMP Debian 4.9.65-3+deb9u2~bpo8+1 (2017-01-05) i686 & reran the spectre-meltdown-checker, with identical results: all 3 vulnerabilities are not fixed.

links:
https://security-tracker.debian.org/tra … -2017-5754
https://github.com/speed47/spectre-melt … /issues/58
https://www.neowin.net/news/ubuntu-will … anuary-9th
https://security.stackexchange.com/ques … -platforms

of course all this is about meltdown only and doesn't address the Spectre Vulnerability...

Head_on_a_Stick · 2018-01-13 12:56:11

ohnonot wrote:

Given your obsession with computer security (and your position of responsibility at these forums), I don't understand how you can joke about it.

Humour is a natural human response to a fundamentally untenable situation — would you prefer that I wail and gnash my teeth instead? 8o

Anyway, my glib retort contained pertinent advice: the arm64 architecture is unaffected by Meltdown and so can be used as a "safe" alternative.

Thanks for your research, I'm following n_hologram's thread over at fdn and hopefully they will report back with news from the patch developers about 32-bit coverage.

ohnonot wrote:

of course all this is about meltdown only and doesn't address the Spectre Vulnerability...

Yes, IMO Intel deliberately conflated Meltdown & Spectre in an attempt to confuse the public.

The Spectre vulnerability will be with us for a long time (but it is more difficult to exploit).

They are both local vulnerabilities so for a single-user system disabling javascript should eliminate the attack vector.

cloverskull · 2018-01-13 19:50:23

Wow, my virtualized BL is noticeably slower. I haven't used it since December. What a bummer.

Head_on_a_Stick · 2018-01-13 23:09:05

I wrote:

I'm following n_hologram's thread over at fdn and hopefully they will report back with news from the patch developers about 32-bit coverage

The news is back and it's not good:

Patch person wrote:

Yes, 32bit is vulnerable. We haven't yet had time to look into that as the
vast majority of systems, especially the most endangered cloud stuff, runs
64bit. We know about it and the 32bit mitigation has been under discussion
already, but I can't tell at the moment when we are going to have that.
Sorry that I can't tell you better news.
Thanks,
Thomas

http://forums.debian.net/viewtopic.php?p=663711#p663711

:cry:

jr2 · 2018-01-14 04:46:04

People are starting to say that the only way out of this mess is a hardware upgrade - a complete rethink of CPU architecture.

Of course that would mean all old computers are vulnerable, a huge capital outlay for all the companies running servers, and...

...possibly the end of the "hobbyists" like us. Only those who could afford to lay out for new machines would be able to go on playing with Linux, BSD... etc, and all the users in less wealthy counries would be forced to rely on proprietary touchscreen devices.

Quite a desirable outcome for hardware manufacturers and content providers alike - everyone except the poor exploited users.

>> cue for wailing and gnashing of teeth, yes HoaS feel free to join in.

nore · 2018-01-14 06:41:39

jr2 wrote:

...possibly the end of the "hobbyists" like us. Only those who could afford to lay out for new machines would be able to go on playing with Linux, BSD... etc,

Both major vulnerabilities still require physical access to the computer, right? If you keep several devices at home and keep an eye on those that you carry around, change BIOS and AMT passwords, where's the risk, really?

ohnonot · 2018-01-14 08:53:07

Head_on_a_Stick wrote:

They are both local vulnerabilities so for a single-user system disabling javascript should eliminate the attack vector.

wait what, servers (no virtualisation) cannot be attacked from the outside???
sorry if i misunderstand something here; a physical server surely is a single user system?

ok i'm reading up on that right now, search for "server" e.g. [here][1] and [here][2]; it would seem that without virtualisation the problem is somehow smaller(?), and without allowing any outside code to run on the system, there's no danger at all (supposing all my installed software is safe)?

[1]: https://en.wikipedia.org/wiki/Meltdown_ … erability)
[2]: http://www.zdnet.com/article/how-to-pro … d-spectre/

Head_on_a_Stick · 2018-01-14 11:05:55

Bruce Schneier's blog has a nice article about Meltdown/Spectre:

https://www.schneier.com/blog/archives/ … mel_1.html

This bit is probably the most relevant:

This isn't to say you should immediately turn your computers and phones off and not use them for a few years. For the average user, this is just another attack method amongst many. All the major vendors are working on patches and workarounds for the attacks they can mitigate. All the normal security advice still applies: watch for phishing attacks, don't click on strange e-mail attachments, don't visit sketchy websites that might run malware on your browser, patch your systems regularly, and generally be careful on the Internet.

Overall though, the only true long-term solution is open-source hardware — such as RISC-V — which will hopefully become cheap enough for "normal" people to use, the energy savings conferred by such devices should also be taken into consideration.

ohnonot wrote:

servers (no virtualisation) cannot be attacked from the outside?

Yes, that's correct.

I presume you aren't hosting a cloud server running lots of Docker containers for other people in your kitchen, right?

#41 2018-01-10 06:50:06

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#42 2018-01-10 09:18:49

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#43 2018-01-10 19:33:33

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#44 2018-01-10 20:56:38

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#45 2018-01-10 21:54:55

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#46 2018-01-10 22:04:57

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#47 2018-01-10 22:25:15

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#48 2018-01-10 22:36:46

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#49 2018-01-10 23:47:34

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#50 2018-01-11 20:29:27

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#51 2018-01-12 06:58:54

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#52 2018-01-12 13:07:05

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#53 2018-01-13 08:38:26

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#54 2018-01-13 12:56:11

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#55 2018-01-13 19:50:23

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#56 2018-01-13 23:09:05

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#57 2018-01-14 04:46:04

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#58 2018-01-14 06:41:39

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#59 2018-01-14 08:53:07

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

#60 2018-01-14 11:05:55

Re: Meltdown - Intel CPU design flaw affecting all OS platforms

Board footer