Personal computing discussed
Moderators: renee, Flying Fox, morphine
Glorious wrote:captaintrav wrote:If I'm understanding things properly, the mitigation for Meltdown is going to have more of a performance impact if your processor doesn't support process context identifiers, which means Haswell and newer, but Wikipedia says it was introduced with Westmere. Maybe just for certain SKUs before Haswell. Maybe time to finally ditch Sandy Bridge?
Haswell introduced INVPCID (http://www.felixcloutier.com/x86/INVPCID.html), which helps significantly: If you can't directly select which PCID to flush everything is much more awkward, complicated, and onerous for performance.
Without it, the current patchset might not actually even be trying to use PCIDs on Ivy-Bridge and older: this was all thrown together very rapidly and all this confusion, rhetoric and hyperbole means I'd have to go and look myself basically.
SuperSpy wrote:I'm guessing that bug has something to so with AV makers injecting their DLLs into every process. But I don't see what they could be doing that would break when kernel memory is unmapped.
Peter Bright @ Arstechnica wrote:There are a couple of wrinkles. During testing, Microsoft found that some anti-virus software tries to do undocumented, unsupported things with kernel memory, and these things break when dual page tables are used. Accordingly, dual page tables won't be used when third-party anti-virus is installed, until and unless that anti-virus software sets a specific registry key to indicate that it supports dual page tables.
Ryu Connor wrote:Never underestimate how bad AV software is.
Ryu Connor wrote:The Meltdown fix does activate, but the CPU lacks PCID and INVPCID instructions. Given that this poor T7500 can't even handle YouTube 1080p decoding, I'm not sure the performance hit the Meltdown patch gives is worth the bit of defense in depth provided. On a machine this old, what useful objective benchmarks could I run to quantify the performance hit?
chuckula wrote:I would put it this way: What tasks was the machine performing prior to Meltdown and can it perform them post Meltdown?
Ryu Connor wrote:chuckula wrote:I would put it this way: What tasks was the machine performing prior to Meltdown and can it perform them post Meltdown?
To be fair, I'm mostly asking "for Science!" This machine represents the worst possible case.
For me this box is a guinea pig and it will continue to perform that unpleasant task.
Ryu Connor wrote:https://docs.google.com/spreadsheets/d/184wcDt9I9TUNFFbsAVLpzAtckQxYiuirADzf3cL42FQ/htmlview?sle=true#gid=0
A managed list of AV vendors who have or haven't set the correct registry key in Windows to receive the KPTI patch.
just brew it! wrote:We're having a meeting here at work in 30 minutes to discuss potential impacts of Meltdown/Spectre and their mitigations on the security and performance of our product. This is gonna be fun.
Ryu Connor wrote:The Meltdown fix does activate, but the CPU lacks PCID and INVPCID instructions. Given that this poor T7500 can't even handle YouTube 1080p decoding, I'm not sure the performance hit the Meltdown patch gives is worth the bit of defense in depth provided. On a machine this old, what useful objective benchmarks could I run to quantify the performance hit?
All of our cloud services are affected by updates required to mitigate the Meltdown vulnerability.
just brew it! wrote:Why would we not want people to link to other sites?
chuckula wrote:SuperSpy wrote:Brief write-up of the major players responses by Ars' Peter Bright: https://arstechnica.com/gadgets/2018/01 ... -about-it/
The ARS article is pretty comprehensive and not particularly mouth-breathing crazy, which is somewhat refreshing since too many sites have decided that clickbaitiness is more important than a rational discussion (incidentally, TR has also been very fact-based and level headed in its reporting).
Captain Ned wrote:If the scary impact numbers discussed for virtualization workloads are only 50% correct, Meltdown mitigation is still going to have a MAJOR impact on the financial services industry. Since financial services HATE to spend money on anything that doesn't directly generate income (a/k/a IT, where no one ever got/gets fired for buying Intel), physical boxen are running well past 75% CPU load to maximize virtual server capacity, generally without spare physical box capacity that can be rapidly spun up.
Captain Ned wrote:So, my Day Job response won't be the textbook "patch NOW!!!!!!". We've lived with this vulnerability for almost 25 years; waiting a week or two for Meltdown patch stability and resource minimization won't be the end of the world.
Captain Ned wrote:On another note something this insidious and technically "sweet" has all of my TLA-senses tingling, as in potential TLA input into early 1990s design decisions.
the wrote:Captain Ned wrote:When I did remote hosting, security patches (unless absolutely critical with exploits in the wild) never got patched immediately. Test/dev would get it immediately, followed by staging a week later and then production a week late/next maintenance window as appropriate. Currently I have only heard of proof-of-concept attacks for Meltdown so they'd be following normal procedure and likely stopping at staging systems due to bugsSo, my Day Job response won't be the textbook "patch NOW!!!!!!". We've lived with this vulnerability for almost 25 years; waiting a week or two for Meltdown patch stability and resource minimization won't be the end of the world.
Kougar wrote:It does raise an interesting point, what's the earliest generation Intel can make the hardware changes in? Cascade Lake this year? Intel elected to not make the changes in Coffee Lake nor Sky-X so it must not be a quick fix.
DancinJack wrote:Kougar wrote:It does raise an interesting point, what's the earliest generation Intel can make the hardware changes in? Cascade Lake this year? Intel elected to not make the changes in Coffee Lake nor Sky-X so it must not be a quick fix.
No way. We're looking at likely a multi-year hardware solution. Intel said Cascade Lake was Q4'18. I think we're too far along already for them to make hardware changes unless they really want to deal with a delay. They MIGHT be able to get something into Ice Lake, though Intel said it had already taped-in middle of 2017.
DancinJack wrote:Then again, my above assumptions have no idea when Intel really found out about this. Maybe they've known for a good six months or a year internally. I'm still putting my money on Ice Lake being the first, unless Intel thinks it's worth the money to do it for Cascade Lake, and the accompanying Xeons.
chuckula wrote:As I keep postponing a long overdue upgrade, I still use a Core2 as my main desktop computer. I mostly use it for everyday tasks (web, email, office), some image editing and game and also run a Plex server in the background.I'm updating a Core2 machine that's actually used for real stuff (not high-performance work but real work) once the updated 4.9 LTS kernel finishes testing in my distro. I'm sure I could show an issue with a synthetic benchmark but I'll see how the box performs for its day job after the update.
Captain Ned wrote:On another note something this insidious and technically "sweet" has all of my TLA-senses tingling, as in potential TLA input into early 1990s design decisions.
Redocbew wrote:It does have that feeling to it, sort of like the substitution tables in DES which just popped up out of nowhere and couldn't be derived mathematically.
Kougar wrote:Are they just hoping for $20 coupons to be used against a future Intel CPU?
Kougar wrote:It does raise an interesting point, what's the earliest generation Intel can make the hardware changes in? Cascade Lake this year? Intel elected to not make the changes in Coffee Lake nor Sky-X so it must not be a quick fix.
the wrote:The bugs first discovery being six months old is one of the reasons why patches were already well into development and awaiting release on January 9th. The reason everything happened last week is that people were looking into the Linux patches and noticing a few oddities (release notes under NDA etc.) but being moved into mainstream release.
the wrote:Intel will likely push Cascade Lake into 2019 due to this bug or simply cancel it in favor Cannon Lake-SP in 2019 which is still on the roadmap last I heard. The rumors are pointing toward Cascade Lake as being a Sky Lake-SP update still on 14 nm due to delays in 10 nm production. One big new feature in Cascade Lake was to fix to support Optane DIMMS, a feature Intel removed at the last minute for Sky Lake-SP due to a bug found in validation. I see it as incredibly unwise to release Cascade Lake and Optane DIMMs if it is still susceptible to Meltdown or Spectre.
the wrote:(And a bit of tin foil battery, Intel's keynote is on January 8th were as the NDAs for Meltdown and Spectre were originally scheduled for release on January 9th. It is easy to speculate that that was negotiated by Intel but the 9th date was likely asked for by Microsoft to coincide with their traditional patch Tuesday release schedule.)