https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stoc... https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ Lev just tweeted the above links. This is annoying, it means rebooting all systems with Intel CPUs for which security is important and also ongoing performance loss for all modern systems with Intel CPUs. People who care about performance not security (EG gamers and people who mostly do compiles) could run in a less secure mode (run an old kernel or maybe a newer kernel patched to turn off this security feature). I guess the lesson from this and the previous security issues is to just avoid Intel CPUs. It's what Intel's CEO expects us to do.
Hi Russell, all
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
Lev just tweeted the above links. This is annoying, it means rebooting all systems with Intel CPUs for which security is important and also ongoing performance loss for all modern systems with Intel CPUs.
A nuisance indeed, most hosted VMs will be impacted - with the % performance loss, companies may need to scale up or out additionally, incurring extra cost. This won't create happiness.
People who care about performance not security (EG gamers and people who mostly do compiles) could run in a less secure mode (run an old kernel or maybe a newer kernel patched to turn off this security feature).
This raises the interesting question: will distros start to provide separate kernel packages for Intel and AMD CPUs. I'd guess they will, as the performance hit of the KPTI workaround is significant. I use AMD desktops and servers at my home office, and naturally I'd like to keep the performance they deliver. While I'm quite capable of compiling my own kernel, I tend to not bother with that in recent years. Regards, Arjen.
On 03/01/18 16:11, Arjen Lentz via luv-main wrote:
This raises the interesting question: will distros start to provide > separate kernel packages for Intel and AMD CPUs. I'd guess they will, as the performance hit of the KPTI workaround is significant. They won't need to, as the mitigation is loaded at runtime and AMD's provided kernel patch prevents the slow KPTI workaround from being loaded when AMD CPUs are detected.
Cheers, Andrew
On Wednesday, 3 January 2018 4:32:25 PM AEDT Andrew Pam wrote:
On 03/01/18 16:11, Arjen Lentz via luv-main wrote:
This raises the interesting question: will distros start to provide > separate kernel packages for Intel and AMD CPUs. I'd guess they will, as the performance hit of the KPTI workaround is significant.
They won't need to, as the mitigation is loaded at runtime and AMD's provided kernel patch prevents the slow KPTI workaround from being loaded when AMD CPUs are detected.
Naturally the kernel can recognise which CPU it's running on and do appropriate things. Changes or similar scope are made at run-time for other purposes (EG SIMD instructions and the recent kernel changes that broke compatability with older libc). But there is a reasonable use case for systems that don't need such kernel security. A significant portion of Linux systems are single user workstations. For such a system you have one UID that deals with all the data from the Internet (and is therefore at risk of compromise) which also has access to all secrets (Internet banking passwords, GPG keys, ssh keys, etc). On such a single-user workstation the UID in question is generally used to access root via sudo or similar, and therfore an attacker who gets that UID can get root with a little patience and not much skill. For such a single user workstation (like the systems most of us use to post to this list) the new kernel won't provide any real benefit. Now there are some things that could be done to improve security of single- user workstations. For starters encourage users to use a different session for tasks that need root access, even CTRL-ALT-F1 to get a text console will do. Things like ssh keys could be accessed by a setgid program, so have ~/.ssh a symlink to /var/lib/ssh/$USER and have /var/lib/ssh only accessible by the ssh group. Then mail clients could use a local proxy that stores the IMAP/SMTP password and only sends it to the server so the password can't be stolen by a local user compromise. Such techniques could make regular user compromise on a single-user workstation inadequate to get all access. But at the moment for attacking a single-user workstation there's no real need for root.
On Wed, Jan 3, 2018, at 6:29 PM, Russell Coker via luv-main wrote:
On Wednesday, 3 January 2018 4:32:25 PM AEDT Andrew Pam wrote:
On 03/01/18 16:11, Arjen Lentz via luv-main wrote:
This raises the interesting question: will distros start to provide > separate kernel packages for Intel and AMD CPUs. I'd guess they will, as the performance hit of the KPTI workaround is significant.
They won't need to, as the mitigation is loaded at runtime and AMD's provided kernel patch prevents the slow KPTI workaround from being loaded when AMD CPUs are detected.
Naturally the kernel can recognise which CPU it's running on and do appropriate things. Changes or similar scope are made at run-time for other purposes (EG SIMD instructions and the recent kernel changes that broke compatability with older libc).
But there is a reasonable use case for systems that don't need such kernel security. A significant portion of Linux systems are single user workstations. For such a system you have one UID that deals with all the data from the Internet (and is therefore at risk of compromise) which also has access to all secrets (Internet banking passwords, GPG keys, ssh keys, etc). On such a single-user workstation the UID in question is generally used to access root via sudo or similar, and therfore an attacker who gets that UID can get root with a little patience and not much skill. For such a single user workstation (like the systems most of us use to post to this list) the new kernel won't provide any real benefit.
I *strongly* disagree. Modern machines sandbox a *lot*, and we trust a web browser to protect our documents from malicious javascript, and these processes are much more constrained than general random processes running as that uid. You could also use these vulnerabilities to get further than you otherwise could. e.g. a web server running in a very constrained SELinux environment could break out of that and get access to things it's not meant to be able to.
On Thursday, 4 January 2018 11:44:17 AM AEDT Stewart Smith via luv-main wrote:
On Wed, Jan 3, 2018, at 6:29 PM, Russell Coker via luv-main wrote:
On Wednesday, 3 January 2018 4:32:25 PM AEDT Andrew Pam wrote:
On 03/01/18 16:11, Arjen Lentz via luv-main wrote:
This raises the interesting question: will distros start to provide > separate kernel packages for Intel and AMD CPUs. I'd guess they will, as the performance hit of the KPTI workaround is significant.
They won't need to, as the mitigation is loaded at runtime and AMD's provided kernel patch prevents the slow KPTI workaround from being loaded when AMD CPUs are detected.
Naturally the kernel can recognise which CPU it's running on and do appropriate things. Changes or similar scope are made at run-time for other purposes (EG SIMD instructions and the recent kernel changes that broke compatability with older libc).
But there is a reasonable use case for systems that don't need such kernel security. A significant portion of Linux systems are single user workstations. For such a system you have one UID that deals with all the data from the Internet (and is therefore at risk of compromise) which also has access to all secrets (Internet banking passwords, GPG keys, ssh keys, etc). On such a single-user workstation the UID in question is generally used to access root via sudo or similar, and therfore an attacker who gets that UID can get root with a little patience and not much skill. For such a single user workstation (like the systems most of us use to post to this list) the new kernel won't provide any real benefit.
I *strongly* disagree. Modern machines sandbox a *lot*, and we trust a web browser to protect our documents from malicious javascript, and these processes are much more constrained than general random processes running as that uid.
Since I wrote that previous message more information has come out which makes it seem that these problems are more serious than I initially believed. So I agree with you now. As a general rule applying security fixes ASAP is going to be a reasonable option.
You could also use these vulnerabilities to get further than you otherwise could. e.g. a web server running in a very constrained SELinux environment could break out of that and get access to things it's not meant to be able to.
I recommend applying all security fixes to servers. They are open for attack 24*7. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Wed, Jan 03, 2018 at 03:11:02PM +1000, Arjen Lentz wrote:
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
A nuisance indeed, most hosted VMs will be impacted - with the % performance loss, companies may need to scale up or out additionally, incurring extra cost. This won't create happiness.
it won't be too big a deal if you have another VM host (AMD, or an Intel running the patched kernel) to live-migrate running instances to. then reboot (or replace) the machine when it has no VMs left running on it...and start live-migrating some or all of the VMs back to it. migration is still likely to breach any contract requiring five-9s or better uptime, unless the VMs are running off shared storage like iscsi or drbd (the bulk of the time required for a live-migration is saving the current state and copying the VM's disk images). A good VM hosting service should, IMO, already by set up for this kind of HA live migration anyway. craig -- craig sanders <cas@taz.net.au>
On Wed, Jan 3, 2018, at 7:53 PM, Craig Sanders via luv-main wrote:
On Wed, Jan 03, 2018 at 03:11:02PM +1000, Arjen Lentz wrote:
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
A nuisance indeed, most hosted VMs will be impacted - with the % performance loss, companies may need to scale up or out additionally, incurring extra cost. This won't create happiness.
it won't be too big a deal if you have another VM host (AMD, or an Intel running the patched kernel) to live-migrate running instances to.
then reboot (or replace) the machine when it has no VMs left running on it...and start live-migrating some or all of the VMs back to it.
migration is still likely to breach any contract requiring five-9s or better uptime, unless the VMs are running off shared storage like iscsi or drbd (the bulk of the time required for a live-migration is saving the current state and copying the VM's disk images).
A good VM hosting service should, IMO, already by set up for this kind of HA live migration anyway.
Exactly. The only thing you may notice is the associated performance hit. You do need a new kernel too though, which does mean a reboot has to happen of the VM, but any system needing five-9s uptime has redundancy to handle that in a rolling fashion too.
On 04/01/18 11:46, Stewart Smith via luv-main wrote:
Exactly. The only thing you may notice is the associated performance hit.
This might help with the performance issues: https://www.usenix.org/legacy/events/osdi10/tech/full_papers/Soares.pdf Cheers, Andrew
On Thu, Jan 4, 2018, at 11:48 AM, Andrew Pam wrote:
On 04/01/18 11:46, Stewart Smith via luv-main wrote:
Exactly. The only thing you may notice is the associated performance hit.
This might help with the performance issues:
https://www.usenix.org/legacy/events/osdi10/tech/full_papers/Soares.pdf
Interesting.... of course, that's a solution for the future as it's not in mainline kernels yet :)
On 4 January 2018 10:46:18 am AEST, Stewart Smith via luv-main <luv-main@luv.asn.au> wrote:
The only thing you may notice is the associated performance hit.
Which was my whole point. Reportedly up to 30%, which has consequences for online capacity and thus will incur extra cost to mitigate.
You do need a new kernel too though, which does mean a reboot has to happen of the VM, but any system needing five-9s uptime has redundancy to handle that in a rolling fashion too.
Haha. You're funny. And I think you know better, too. In the real world: Should, yes. Has, rarely. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 04/01/18 12:12, Arjen Lentz via luv-main wrote:
Reportedly up to 30%, which has consequences for online capacity and thus will incur extra cost to mitigate.
Postgres benchmarks with KPTI: https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3.... Cheers, Andrew
Hi Andrew On 4 January 2018 11:58:40 am AEST, Andrew Pam <andrew@sericyb.com.au> wrote:
On 04/01/18 12:12, Arjen Lentz via luv-main wrote:
Reportedly up to 30%, which has consequences for online capacity and thus will incur extra cost to mitigate.
Postgres benchmarks with KPTI: https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3....
Ya i saw, useful. So those show 7-17% performance loss, depending on use scenario, and connecting method. That will require adjustments in capacity for online environments. Regards, Arjen. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Thursday, 4 January 2018 12:13:14 PM AEDT Arjen Lentz via luv-main wrote:
On 4 January 2018 11:58:40 am AEST, Andrew Pam <andrew@sericyb.com.au> wrote:
On 04/01/18 12:12, Arjen Lentz via luv-main wrote:
Reportedly up to 30%, which has consequences for online capacity and
thus will incur extra cost to mitigate.
Postgres benchmarks with KPTI: https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3 .anarazel.de Ya i saw, useful. So those show 7-17% performance loss, depending on use scenario, and connecting method.
That will require adjustments in capacity for online environments.
That message doesn't mention the complexity of the operations and how they might compare with other operations. Ideally a database server will have indexes that match all queries and everything should complete with little CPU time. But if you have some CPU intensive operations then the performance loss will be decreased. A server running seriously CPU intensive tasks like BOINC or coin mining probably won't have any measurable overhead. I wonder what the overhead will be for gaming? If you have the video memory mapped then there shouldn't be many system calls so the cost might be minimal. I wonder how many online games have security issues anyway... -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 03.01.18 15:11, Arjen Lentz via luv-main wrote:
This raises the interesting question: will distros start to provide separate kernel packages for Intel and AMD CPUs. I'd guess they will, as the performance hit of the KPTI workaround is significant.
I use AMD desktops and servers at my home office, and naturally I'd like to keep the performance they deliver.
Sadly, the AMD cpus have a variant of the Intel Management Engine lurking under the hood, with a further unknown vulnerability level, just like Intel. (Oh, OK, the Remote Elevation of Privilege bug (SA-00075) is known, but the rest aren't - yet.) Erik
from the tail end of the theregister article... *PS: It appears 64-bit ARM Linux kernels will also get <https://lwn.net/Articles/740393/> a set of KAISER patches, completely splitting the kernel and user spaces, to block attempts to defeat KASLR. We'll be following up this week.* On 3 January 2018 at 20:03, Erik Christiansen via luv-main < luv-main@luv.asn.au> wrote:
On 03.01.18 15:11, Arjen Lentz via luv-main wrote:
This raises the interesting question: will distros start to provide separate kernel packages for Intel and AMD CPUs. I'd guess they will, as the performance hit of the KPTI workaround is significant.
I use AMD desktops and servers at my home office, and naturally I'd like to keep the performance they deliver.
Sadly, the AMD cpus have a variant of the Intel Management Engine lurking under the hood, with a further unknown vulnerability level, just like Intel. (Oh, OK, the Remote Elevation of Privilege bug (SA-00075) is known, but the rest aren't - yet.)
Erik _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
-- Dr Paul van den Bergen
On 04/01/18 09:48, Paul van den Bergen via luv-main wrote:
from the tail end of the theregister article...
/*PS:* It appears 64-bit ARM Linux kernels will also get <https://lwn.net/Articles/740393/> a set of KAISER patches, completely splitting the kernel and user spaces, to block attempts to defeat KASLR. We'll be following up this week./
Sparc64 and S390 on the other hand are completely immune to this particular issue due to enhanced security by design. :) Cheers, Andrew
On Wed, Jan 3, 2018, at 4:11 PM, Arjen Lentz via luv-main wrote:
This raises the interesting question: will distros start to provide separate kernel packages for Intel and AMD CPUs. I'd guess they will, as the performance hit of the KPTI workaround is significant.
There's a kernel command line parameter as well as suitable runtime patching and configuration so that it "just works" correctly for folk. https://lkml.org/lkml/2017/12/27/2 is the patch for AMD. At least for the pagetable fun. It's important to note that there's more than one issue being disclosed, and reading https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-ne... is a good idea.
On Wed, Jan 3, 2018, at 2:35 PM, Russell Coker via luv-main wrote:
https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stoc...
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
Lev just tweeted the above links. This is annoying, it means rebooting all systems with Intel CPUs for which security is important and also ongoing performance loss for all modern systems with Intel CPUs.
People who care about performance not security (EG gamers and people who mostly do compiles) could run in a less secure mode (run an old kernel or maybe a newer kernel patched to turn off this security feature).
As long as they *never* run interpreted code, e.g. JavaScript, then *maybe* that's okay. Even if you're mostly doing compiles, you do trust the MMU to isolate those processes, so you probably need the fix too.
Russell Coker via luv-main wrote:
https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stoc...
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
Lev just tweeted the above links. This is annoying, it means rebooting all systems with Intel CPUs for which security is important and also ongoing performance loss for all modern systems with Intel CPUs.
Well it seems Intel has been very naughty https://www.theregister.co.uk/2018/01/04/intels_spin_the_registers_annotatio... But then again perhaps, "every-modern processor has-unfixable security flaws" https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-every-modern-pr... regards Rohan McLeod
Quoting Rohan McLeod (rhn@jeack.com.au):
Well it seems Intel has been very naughty https://www.theregister.co.uk/2018/01/04/intels_spin_the_registers_annotatio...
Intel has a long history of trying to dissemble and misdirect their way out of paying for grave CPU flaws. Remember the 'Pentium Processor Invalid Instruction Erratum' of 1997, exposing all Intel Pentium and Pentium MMX CPUs to remote security attack, stopping them in their tracks if they can be induced to run processory instruction 'F0 0F C7 C8'? No, of course you don't. That's why Intel gave it the mind-numbingly boring official name Pentium Processor Invalid Instruction Erratum', hoping to replace its popular names 'F00F bug' and 'Halt-and-Catch Fire bug'. That's also why Intel's judo-move response was to create an information page stating that it had dealt with the CPU bug by linking to each of the various x86 OS vendors' bug-fix pages. 'Here, we fixed the grave defect in our CPU by sitting on our asses and letting software coders work around our error.' The press, of course, cooperated by simply pointing people to Intel's page and implying that Intel 'developed a fix'. That's what they're going to do this time, too, I'm sure of that. My page about the F00F bug. 'F00F Bug' on http://linuxmafia.com/kb/Hardware/ (See in particular my dissection of Intel's spin-control tactics a year after the scandal broke.) -- Cheers, « Le doute n'est pas une état bien agréable, mais Rick Moen l'assurance est un état ridicule. » ("Doubt is not rick@linuxmafia.com a pleasant condition, but certainty is absurd.') McQ! (4x80) -- Voltaire
Rick Moen via luv-main wrote:
Quoting Rohan McLeod (rhn@jeack.com.au):
Well it seems Intel has been very naughty https://www.theregister.co.uk/2018/01/04/intels_spin_the_registers_annotatio... Intel has a long history of trying to dissemble and misdirect their way out of paying for grave CPU flaws. Remember the 'Pentium Processor Invalid Instruction Erratum' of 1997, exposing all Intel Pentium and Pentium MMX CPUs to remote security attack, stopping them in their tracks if they can be induced to run processory instruction 'F0 0F C7 C8'?
No, of course you don't. That's why Intel gave it the mind-numbingly boring official name Pentium Processor Invalid Instruction Erratum', hoping to replace its popular names 'F00F bug' and 'Halt-and-Catch Fire bug'.
That's also why Intel's judo-move response was to create an information page stating that it had dealt with the CPU bug by linking to each of the various x86 OS vendors' bug-fix pages. 'Here, we fixed the grave defect in our CPU by sitting on our asses and letting software coders work around our error.'
The press, of course, cooperated by simply pointing people to Intel's page and implying that Intel 'developed a fix'. That's what they're going to do this time, too, I'm sure of that.
My page about the F00F bug. 'F00F Bug' on http://linuxmafia.com/kb/Hardware/ (See in particular my dissection of Intel's spin-control tactics a year after the scandal broke.)
Thanks for the reply Rick; as these day it is unusual for anyone to reply to my emails ; though this has advantages as well as dis-advantages :-| ; regards Rohan McLeod
On Fri, Jan 05, 2018 at 03:14:28PM +1100, Rohan McLeod wrote:
as these day it is unusual for anyone to reply to my emails ;
I find your messages extremely difficult to read because of the bizarre formatting. It obviously makes sense to you and follows your own rules, but to me it seems like arbitrary and random insertion of newlines, semi-colons, and other punctuation in some inscrutable logic that bears no resemblance to the common standards of how most people format text or use punctuation. This is not a criticism of the content - usually you post things worth reading, but it's a huge effort to decipher them. craig -- craig sanders <cas@taz.net.au>
Craig Sanders via luv-main wrote:
On Fri, Jan 05, 2018 at 03:14:28PM +1100, Rohan McLeod wrote:
as these day it is unusual for anyone to reply to my emails ; I find your messages extremely difficult to read because of the bizarre formatting. It obviously makes sense to you and follows your own rules, but to me it seems like arbitrary and random insertion of newlines, semi-colons, and other punctuation in some inscrutable logic that bears no resemblance to the common standards of how most people format text or use punctuation.
This is not a criticism of the content - usually you post things worth reading, but it's a huge effort to decipher them.
craig
Thanks Craig I appreciate your honesty and the clarity of your typography; I think we discussed all this before and I am still uninclined to change my ways :-) regards Rohan McLeod
-- craig sanders <cas@taz.net.au> _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
hi this email is quoted on /. and credited to this list https://hardware.slashdot.org/story/18/01/05/142201/when-f00f-bug-hit-20-yea... Steve On 05/01/18 08:57, Rick Moen via luv-main wrote:
Quoting Rohan McLeod (rhn@jeack.com.au):
Well it seems Intel has been very naughty https://www.theregister.co.uk/2018/01/04/intels_spin_the_registers_annotatio...
Intel has a long history of trying to dissemble and misdirect their way out of paying for grave CPU flaws. Remember the 'Pentium Processor Invalid Instruction Erratum' of 1997, exposing all Intel Pentium and Pentium MMX CPUs to remote security attack, stopping them in their tracks if they can be induced to run processory instruction 'F0 0F C7 C8'?
No, of course you don't. That's why Intel gave it the mind-numbingly boring official name Pentium Processor Invalid Instruction Erratum', hoping to replace its popular names 'F00F bug' and 'Halt-and-Catch Fire bug'.
That's also why Intel's judo-move response was to create an information page stating that it had dealt with the CPU bug by linking to each of the various x86 OS vendors' bug-fix pages. 'Here, we fixed the grave defect in our CPU by sitting on our asses and letting software coders work around our error.'
The press, of course, cooperated by simply pointing people to Intel's page and implying that Intel 'developed a fix'. That's what they're going to do this time, too, I'm sure of that.
My page about the F00F bug. 'F00F Bug' on http://linuxmafia.com/kb/Hardware/ (See in particular my dissection of Intel's spin-control tactics a year after the scandal broke.)
Quoting Steve Roylance (roylance@corplink.com.au):
hi
this email is quoted on /. and credited to this list
https://hardware.slashdot.org/story/18/01/05/142201/when-f00f-bug-hit-20-yea...
And, you know, the previous time I was on Slashdot, it was on account of Sam Varghese's excellent writing, too. (Darn you, Sam! ;-> ) Sam doesn't toot his own horn, so it's left to me to point out the gentleman's consistently good work on IT Wire, https://www.itwire.com/ (not to mention any number of other places). -- Cheers, "A recursive .sig Rick Moen Can impart wisdom and truth. rick@linuxmafia.com Call proc signature() McQ! (4x80) -- WalkingTheWalk on Slashdot
participants (10)
-
Andrew Pam -
Arjen Lentz -
Craig Sanders -
Erik Christiansen -
Paul van den Bergen -
Rick Moen -
Rohan McLeod -
Russell Coker -
Steve Roylance -
Stewart Smith