You are not logged in.
vinzv wrote:In general the figures of "...30% loss on performance..." haunting through tech press have to be taken with a grain of salt as these are extreme examples. As long as there aren't any in-depth benchmarks I wouldn't rely on any thing circulating.
This is a good point, I'm curious myself. Wondering if huge backup I/O load (rsyncing entire file systems with lots of files) is going to cause noticably degraded performance.
my kernel is now patched, and i see no performance difference.
someone (HoaS?) said performance drops after the patch are worst for virtualisation, which, afaiu, is also where the flaw is at its most dangerous unpatched.
here a list of patched kernels:
http://news.softpedia.com/news/linux-ke … 9215.shtml
Offline
(HoaS?) said performance drops after the patch are worst for virtualisation
https://forums.bunsenlabs.org/viewtopic … 303#p66303
I was just parroting what more expert users on other forums have been saying though.
The kernel in Debian stretch (and Arch) has the sticking-plaster (partial) fix applied, check with:
grep TABLE_ISOLATION /boot/config-$(uname -r)
A patched kernel will report:
CONFIG_PAGE_TABLE_ISOLATION=y
Test for the speed differences by pressing "e" with the BunsenLabs GRUB menuentry highlighted and adding this to the end of the line that starts with "linux":
notpi
Then press <Ctrl>+x (at the same time) to boot the modified entry and disable the protections.
Be warned though: without the KTPI patch, the system is wide open.
All BunsenLabs Hydrogen/Deuterium users are currently vulnerable, sorry.
Last edited by Head_on_a_Stick (2018-01-06 15:14:34)
Offline
someone (HoaS?) said performance drops after the patch are worst for virtualisation, which, afaiu, is also where the flaw is at its most dangerous unpatched.
Epic Games patched their gaming servers leading to more than doubled CPU load: https://www.epicgames.com/fortnite/foru … ity-update
Offline
We heavily rely on cloud services to run our back-end
Yeah, so they're ****ed, basically
The KTPI patch is just a partial fix and Spectre in particular will haunt us for many years (hence the name).
This whole nasty business requires that we all change our basic habits and it really does highlight the need for a fully open-source hardware solution.
Offline
This whole nasty business requires that we all change our basic habits and it really does highlight the need for a fully open-source hardware solution.
Word!
Looking at how Intel is handling the whole issue in terms of PR makes me really mad. Even after such a desaster they still rest on their laurels and I'm convinced that every other of the big names would act exactly like that.
Offline
My two cents, someone just found the backdoors that have been required to be there all along. It is just a matter of time before all machines have to register themselves onto some sort of a blockchain. We may want secure machine but sadly most governments do not.
Offline
We may want secure machine but sadly most governments do not.
The Russian government uses their own implementation of Oracle's OpenSPARC architecture, for reasons that have suddenly become very clear 8)
A custom computer built around an FPGA running the OpenSPARC T2 architecture looks very appealing right now...
Offline
Yeah. That's the other side of the medal. This whole freedom thingy has been around way too long.
Offline
Though self-quoting is not the most polite behaviour I have to do so:
But looking at AMD's driver code quality doesn't make me trust them too far.
Not even 48 hours later:
"Security hole in AMD CPUs' hidden secure processor code revealed ahead of patches"
Seems like AMD is doing their very best to catch up with being as a mess like Intel is. Best quote from the article:
"Now that the 90-day disclosure window has passed seemingly without any action by AMD, details about the flaw have been made public."
Offline
It looks like the new jessie-backports kernel has the KTPI fix applied:
http://metadata.ftp-master.debian.org/c … _changelog
Any BunsenLabs Hydrogen/Deuterium users concerned about the Meltdown vulnerability can switch to that kernel version by following this guide:
https://forums.bunsenlabs.org/viewtopic.php?id=1257
I'm pretty sure that the stock jessie kernel will get this fix backported as it is still under the aegis of the Security Team but it may take a bit.
Last edited by Head_on_a_Stick (2018-01-08 19:21:05)
Offline
It looks like the new jessie-backports kernel has the KTPI fix applied:
I'm not sure how to read this; does it mean all changes to the stretch version apply to the backport version as well?
because I cannot find any reference kpti/kaiser under the ~bpo* headings.
Offline
because I cannot find any reference kpti/kaiser under the ~bpo* headings.
Actually, I think you're right there, sorry everybody!
If anybody with access to a BL system could check that might be useful:
grep TABLE_ISO /boot/config-$(uname -r)
Offline
Checked.
CONFIG_PAGE_TABLE_ISOLATION=y
Patent from 04. Mai 1990: Lattice scheduler method for reducing the impact of covert-channel countermeasures - is this to avoid Spectre? From 1990.
Offline
Checked
Thanks!
Which kernel is that?
EDIT: wheezy's kernel is fixed but we're still waiting for jessie
Last edited by Head_on_a_Stick (2018-01-08 19:21:39)
Offline
is this to avoid Spectre?
No, the Kernel Table Page Isolation (KTPI) patch only protects against Meltdown and provides no protection whatsoever against Spectre.
I think it is also probably worth noting[1] that the KTPI patch is a software abstraction layer designed to overcome an underlying hardware defect and so it can only be as effective as the patch is bug-free. Fingers crossed, eh? 8o
[1] I say "probably" because I raised this point over at bbs.archlinux.org and it seemed to upset several people and caused one of the mods to TGN the thread, which was amusing.
Last edited by Head_on_a_Stick (2018-01-08 20:17:07)
Offline
Which kernel is that?
It's Stretch, 4.9.0-5-amd64. As I recall it was quick, right after the news hit.
Offline
As I recall it was quick, right after the news hit.
Well, that was two months after Ubuntu found out about it[1] and six months after Intel were first aware of the problem so...
What happened to "open source"? :cry:
The OpenBSD developers only found out about it because of traffic on the Linux kernel mailing lists, which is outrageous IMO.
[1] https://wiki.ubuntu.com/SecurityTeam/Kn … 1514323332
2017 Nov 09: the Ubuntu Security team is notified by Intel under NDA
Last edited by Head_on_a_Stick (2018-01-08 19:54:36)
Offline
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?
Offline
32-bit systems are exploitable so yes, they are twisting
In other news: jessie is fixed
Update && upgrade everybody!
Is that for 64-bit only?
On this 32bit laptop, after up{date,grade} just now:
john@bunsen-bv:~$ grep PAGE_TABLE /boot/config-$(uname -r) # ie nothing
john@bunsen-bv:~$ uname -r
3.16.0-5-686-pae
...so there's nothing in the pipeline for 32bit?
Last edited by jr2 (2018-01-10 02:14:37)
normal service will be resumed as soon as possible
Offline