Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
^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.
Oh, thank God I've switched to a corporate-backed OS.
Viva La Microsoft!
Wheelerof4te wrote:Oh, thank God I've switched to a corporate-backed OS.
Viva La Microsoft!
^ Is this a joke?
At least with the open source operating systems we can see exactly what goes into the patches and can thus evaluate them independently.
With proprietary operating systems the users must trust in the ability of the developers to write a bug-free software abstraction layer with no peer review at all beyond the corporate environment.
It is my understanding that MS have sacked their entire testing department and now instead rely on the Microsoft Insiders Program to garner feedback from paying users...
^It's not a joke. MS has a lot to lose from this, and at least concerning Meltdown and Spectre, the patches have to work. But then again, so does Red Hat, and Novell. Canonical is already doing business in the red zone, so they bided their time.
OTOH, Red Hat and SUSE had patches ready almost instantly.
So yeah, if you need an OS for your PC, choose ones that have something to lose when things go south.
Wheelerof4te wrote:Red Hat and SUSE had patches ready almost instantly
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.
^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.
I did not read that the same way, the link says it has "reliability" issues, not that it "does not work" against meltdown?
The reference link says this:
At least some versions of "KAISER", on meltdown-affected hardware, expose the kernel stack to userspace.
bw123 wrote:please fight the FUD and misinformation
Well for me "works" means "corrects the hardware defect" and the KAISER patch clearly does not do that to the same extent as the KTPI patch.
This is the reason why Alpine Linux (a security-orientated distribution) have decided to switch their stock kernel to the non-LTS version that uses the genuine KTPI patch — they do no consider that the KAISER patch (as used for the LTS kernels) offers the same level of vulnerability mitigation as the KTPI patch and I agree with them.
You are quoting me about RH and SUSE, and post an article about MS and some patch that made some machines unusable. I said they had patches almost instantly when they baceme public...certanly waaay before Debian.
So what if Intel contacted only commercial distros? Isn't that the point I'm making about using corporate OSes? Intel had something to lose if it didn't. It does not have anything to lose when compared to, say, Debian.
Wheelerof4te wrote:So what if Intel contacted only commercial distros?
If Intel and all of the commercial operating systems have been lying to their users since June last year what on Earth makes you think they will stop now?
bw123 wrote:where is the proof that the patch in debian specifically "doesn't really work" ?
The Hacker News thread linked in the mailing list post:
amiuto wrote:Contrary to its marketing, KAISER does not effectively mitigate the old kASLR leaks. PTI very nearly does, and I intend to improve it further once I find some time to do so. I doubt those improvements will get backported to pre-4.14 kernels.
Also:
If you can put pressure on your organization or suppliers to update to 4.14 or better, please do so.
bw123 wrote:where is the proof that the patch in debian specifically "doesn't really work" ?
The Hacker News thread linked in the mailing list post:
amiuto wrote:Contrary to its marketing, KAISER does not effectively mitigate the old kASLR leaks. PTI very nearly does, and I intend to improve it further once I find some time to do so. I doubt those improvements will get backported to pre-4.14 kernels.
Also:
If you can put pressure on your organization or suppliers to update to 4.14 or better, please do so.
I have already suggested that BunsenLabs moves to the Liquorix kernel instead to gain access to the genuine KTPI patch.
You get on here, and make claims about debian Based on one post from a user handle on "Hacker News" okay well, that sounds pretty rush to judgement to believe them over debian kernel developers, but it's your distro.
and I am pretty sure it kpti not KTPI isn't it? Page table Isolation is the thing...
I bet a lot of distros and os vendors and even hardware makers are going to be using fud and misinformation to push their agendas. That really has nothing to do with debian though, so why spread mis-info this way?
Last edited by bw123 on 2018-01-14 19:33, edited 1 time in total.
Wheelerof4te wrote:So what if Intel contacted only commercial distros?
If Intel and all of the commercial operating systems have been lying to their users since June last year what on Earth makes you think they will stop now?
You are very naïve.
So you think they should have announced this MAJOR security flaw for all to see, when there isn't even a fix ready? People have been working on a fix since and only came forward when ready. At least they would have, if someone hasn't leaked the info. You are the one who is very ignorant and naive.
bw123 wrote:According to the changelog "on debian" they added a "nokaiser" switch
Do you have a source for this please?
There is a changelog in /usr/share/doc/linux-image* for every kernel installed, are you even using debian anymore? Your posts in the past have been really excellent, but lately you seem a little off balance with regard to debian.
I haven't used Debian myself for several years, I prefer less complicated operating systems
I do maintain the family laptop though and that's always run Debian stable, I did enable unattended-upgrades once stretch rolled out and I hardly ever touch the box these days. It's wonderful
Hmmm...just did a rebuild of the backported MX 17 4.14.12-2 kernels overnight on generic Stretch pbuilders to add the Ryzen amd64-microcode patch and have the headers pull in libelf-dev, which is still not fixed in Sid. Headaches: some report the Spectre-mitigated 384.111 Nvidia driver just added to stretch-backports won't build on that kernel, but I was able to do so and use it on my Optimus laptop. They had no issue with the Liquorix kernel, though. That kernel isn't in stretch-backports, though.
If that's true about older kernels, are standard Jessie users up the creek with all 32-bit users now?
stevepusser wrote:If that's true about older kernels, are standard Jessie users up the creek with all 32-bit users now?
Well, I wouldn't say that 32-bit users were "up the creek" because the patch developer has committed to work on it, albeit without a timeframe.
Also, the KAISER fix appears to have been used for all kernels not of the 4.14-series so that would mean stretch, jessie and wheezy.
The KAISER patch was originally designed as a strengthened form of KASLR[1] that incorporated more of Grsecurity's work but it does not offer the same level of protection as KPTI, so again I think "up the creek" is perhaps putting it a little strongly.