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
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.
I havent upgrade intel-microcode since Meltdown/Spectre intel firmware patches, cos i was afraid they would bringht redundant security cpu cycles over kernel's Meltdown/Spectre already patched. Am I right about this or Should I Upgrade microcode as well?. I dont want to lost any more performance, my cpu is already very down. I guess im asking to myself ..what do you think?
bester69 wrote:STOP 2030 globalists demons, keep the fight for humanity freedom against NWO...
I have not noticed any loss of performance with my Skylake CPU after the latest Debian microcode update, but Intel is giving up providing any microcode updates for many older affected processors--they say it's just not feasible. Your machine may be one of those; those are the ones with "stopped" in the chart: https://newsroom.intel.com/wp-content/u ... idance.pdf
stevepusser wrote:I have not noticed any loss of performance with my Skylake CPU after the latest Debian microcode update, but Intel is giving up providing any microcode updates for many older affected processors--they say it's just not feasible. Your machine may be one of those; those are the ones with "stopped" in the chart: https://newsroom.intel.com/wp-content/u ... idance.pdf
Hi, Steve
Its is Intel Celeron 575 /2Gh,I dont find that model in tables, furthermore here says "status discontinued", so i guess that mean it doesnt matter if i upgrade microcode, cos it wont take any effect. https://ark.intel.com/products/36680/In ... 67-MHz-FSB
Thanks very much, for your Help,
bester69 wrote:STOP 2030 globalists demons, keep the fight for humanity freedom against NWO...