Reduced the accuracy of timers available to javascript, like chrome has. A rather dirty workaround, not a fix.Seventh wrote:Zenwalk linux is claiming firefox have "fixed" spectre and meltdown timing attacks for linux with firefox 58
)
http://someonewhocares.org/hosts/zero/# Bill Allison, Harj Basi, Lance Russhing, Marshall Drew-Brook,
# Leigh Brasington, Scott Terbush, Cary Newfeldt, Kaye, Jeff
# Scrivener, Mark Hudson, Matt Bells, T. Kim Nguyen, Lino Demasi,
# Marcelo Volmaro, Troy Martin, Donald Kerns, B.Patten-Walsh,
# bobeangi, Chris Maniscalco, George Gilbert, Kim Nilsson, zeromus,
# Robert Petty, Rob Morrison, Clive Smith, Cecilia Varni, OleKing
# Cole, William Jones, Brian Small, Raj Tailor, Richard Heritage,
# Alan Harrison, Ordorica, Crimson, Joseph Cianci, sirapacz,
# Dvixen, Matthew Craig, Tobias Hessem, Kevin F. Quinn, Thomas
# Corthals, Chris McBee, Jaime A. Guerra, Anders Josefson,
# Simon Manderson, Spectre Ghost, Darren Tay, Dallas Eschenauer, Cecilia
# Varni, Adam P. Cole, George Lefkaditis, grzesiek, Adam Howard, Mike
# Bizon, Samuel P. Mallare, Leinweber, Walter Novak, Stephen Genus,
# Zube, Johny Provoost, Peter Grafton, Johann Burkard, Magus, Ron Karner,
# Fredrik Dahlman, Michele Cybula, Bernard Conlu, Riku B, Twillers,
# Shaika-Dzari, Vartkes Goetcherian, Michael McCown, Garth, Richard Nairn,
# Exzar Reed, Robert Gauthier, Floyd Wilder, Mark Drissel, Kenny Lyons,
# Paul Dunne, Tirath Pannu, Mike Lambert, Dan Kolcun, Daniel Aleksandersen,
# Chris Heegard, Miles Golding, Daniel Bisca, Frederic Begou, Charles
# Fordyce, Mark Lehrer, Sebastien Nadeau-Jean, Russell Gordon, Alexey
# Gopachenko, Stirling Pearson, Alan Segal, Bobin Joseph, Chris Wall, Sean
# Flesch, Brent Getz, Jerry Cain, Brian Micek, Lee Hancock, Kay Thiele,
# Kwan Ting Chan, Wladimir Labeikovsky, Lino Demasi, Bowie Bailey, Andreas
# Marschall, Michael Tompkins, Michael O'Donnell, José Lucas Teixeira
# de Oliveira, M. Ömer Gölgeli, and Anthony Gelibert for helping to build
# the hosts file.
# Russell O'Connor for OS/2 information
# kwadronaut for Windows 7 and Vista information
# John Mueller and Lawrence H Smith for Mac Pre-OSX information
# Jesse Baird for the Cisco IOS script
i did now.n[i]hologram wrote:Thanks for the info; good to know jessie/686 isn't left astray ^[/i]^
Were you able to check it against the spectre-meltdown-checker that steve shared?
Code: Select all
$ dmesg | grep isolation
$ grep TABLE_ISOLATION /boot/config-$(uname -r)
$ 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
This is exactly the crux of the 32-bit issue: no one knows. I'm going to email the patch developer later and ask what's going on.debiman wrote:as i said before, the kernel version surely is the patched one, but according to these outputs it does not apply to my 32bit intel processor?
thank you, i'd be delighted if you could report back.n_hologram wrote:This is exactly the crux of the 32-bit issue: no one knows. I'm going to email the patch developer later and ask what's going on.
I don't know if it is what you want or not butdebiman wrote:[*]in addition to the 3.16.0-4-686-pae kernel,...
Unfortunately, it isn't. I've already tried the updated 686 kernels against spectre-meltdown-checker.sh, and they are vulnerable to meltdown. The points mentioned in the updated original post should clarify more details. Semi-related: someone mentioned (can't remember where tbh) that the patched pre-4.14.11 patches use an older version of KTPI, so its results in practice may be nebulous.Thorny wrote:I don't know if it is what you want or not but.
> Hi,
> I'm writing to you because I noticed your involement with the KPTI/KAISER
> patches. Across several varieties of linux distributions, users have
> noticed that kpti is impossible to enable because it depends on x86_64.
> Many of us are concerned that we are running 32-bit systems that are
> still vulnerable to meltdown; we are also concerned because it's a
> handful of users who have brought this to light, and major news and
> information from our distros are keeping silent on the topic. We are all
> wondering if you could shed some light: in particular, is x86 vulnerable?
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
sorry, that was a typo.Thorny wrote:I don't know if it is what you want or not but
thank you, n_hologram, and thank you, Thomas (*) for answering, and a big THANK YOU for the unsung heroes that are working on these patches!!!n_hologram wrote:The patch developer confirmed that x86 (32-bit) is still vulnerable. Spread the word, boys and girls:> Hi,
> I'm writing to you because I noticed your involement with the KPTI/KAISER
> patches. Across several varieties of linux distributions, users have
> noticed that kpti is impossible to enable because it depends on x86_64.
> Many of us are concerned that we are running 32-bit systems that are
> still vulnerable to meltdown; we are also concerned because it's a
> handful of users who have brought this to light, and major news and
> information from our distros are keeping silent on the topic. We are all
> wondering if you could shed some light: in particular, is x86 vulnerable?
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
Theo just posted this on the OpenBSD mailing lists:stevepusser wrote:The latest intel-microcode from Buster adds a bit of Spectre mitigation
https://marc.info/?l=openbsd-tech&m=151588857304763&w=2Also, Intel is saying their new microcodes sucks and people should
wait a little.
"Hi, my name is Intel and I'm an cheating speculator".
This is, along with my previous response(s), why I am taking a wait-and-see approach on this one. No point rushing into this low-risk vulnerability in a blind tizzy. It's just the beginning...Head_on_a_Stick wrote:I am quite certain that there will be a concerted effort by Intel and all the vested commercial interests behind the various "big" operating systems (Linux, Windows & OS X) to rubber stamp any "fixes" (ie, software patches designed to overcome a fundamental design flaw in the underlying hardware) and convince the public that everything is OK.
OK, I will install buster microcode in stretch if not such a performance downgrade like patch kernel;stevepusser wrote:The latest intel-microcode from Buster adds a bit of Spectre mitigation to the script output for my i5-6200u.
There's also a newer amd64-microcode that adds some mitigation for AMD Ryzen, but that requires some latest kernel versions that aren't in Debian yet. Liquorix-4.14-13.1 supports the Ryzen microcode, and I'm looking into adding the patch to the MX 4.14.12 kernel backport.
Oh, thank God I've switched to a corporate-backed OS.Head_on_a_Stick wrote:...And here we go:
http://lists.alpinelinux.org/alpine-devel/6022.html
^According to the Alpine Linux developers, the backported fix (as used by Debian stable) is based on the flawed KAISER patch rather than KTPI and it doesn't really work.
Oh dear.
^ Is this a joke?Wheelerof4te wrote:Oh, thank God I've switched to a corporate-backed OS.
Viva La Microsoft!
Not really, Intel have known about the problem since June 2017 and made the commercial operating systems aware of it (under a non-disclosure agreement, of course) back in October 2017.Wheelerof4te wrote:Red Hat and SUSE had patches ready almost instantly
I did not read that the same way, the link says it has "reliability" issues, not that it "does not work" against meltdown?Head_on_a_Stick wrote:...And here we go:
http://lists.alpinelinux.org/alpine-devel/6022.html
^According to the Alpine Linux developers, the backported fix (as used by Debian stable) is based on the flawed KAISER patch rather than KTPI and it doesn't really work.
Oh dear.
please fight the FUD and misinformation.At least some versions of "KAISER", on meltdown-affected hardware, expose the kernel stack to userspace.