Quantcast

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Major security flaw in ALL intel chip......

2

Comments

  • gervaise1gervaise1 Member EpicPosts: 6,919
    The base links:

    https://spectreattack.com/spectre.pdf
    https://meltdownattack.com/meltdown.pdf

    Reading these indicates that the fundamental issue stems from how computing has developed in the last few years.  As the Spectre paper concludes the drive to maximise performance.

    Both papers make clear that as all manufacturers / developers have gone in the same general direction this a cross-hardware, cross-operating system issue. The fact that something they did worked on one combo and not another, in their opinion, doesn't suggest a given combo is "immune" simply that they hadn't got the "attack" right. 



    What is comforting is that this stuff is pursued by e.g. the EU and fully supported by Intel/Qualcomm/AMD/ARM/MS/Google etc. 


    And its why people should keep their software up-to-date!  (Yes, yes its the Martian conspiracy.) 
    Torvalbartoni33
  • BladeburaibaBladeburaiba Member UncommonPosts: 117
    One of the articles I read suggested that the kernel memory could be read by any process exploiting this vulnerability, including Java which can be embedded in websites.  They suggest this includes sensitive information like passwords and such.

    Why would passwords be kept there?  Are we talking about system passwords that is used to authenticate user logins?  Or is that where passwords and any other information that applications store when you use them, like logging into your banking website?  Why do they store them there, and I suppose that information is not encrypted?
  • RidelynnRidelynn Member EpicPosts: 7,060
    edited January 2018
    FDIV all over again. The sky is falling.

    Is it important to know about? Absolutely. 

    Now that it's known, is it a huge deal? Not really.
    Torval
  • QuizzicalQuizzical Member LegendaryPosts: 22,096
    One of the articles I read suggested that the kernel memory could be read by any process exploiting this vulnerability, including Java which can be embedded in websites.  They suggest this includes sensitive information like passwords and such.

    Why would passwords be kept there?  Are we talking about system passwords that is used to authenticate user logins?  Or is that where passwords and any other information that applications store when you use them, like logging into your banking website?  Why do they store them there, and I suppose that information is not encrypted?
    Passwords would not be stored long-term in kernel memory.  If done properly, passwords shouldn't be stored long-term anywhere.  Rather, you hash a password and store the hash.  The hash itself could be stored in the clear, but given a good password and a good hash function, recovering the password from the hash of it is impractical.

    Rather, when you type in your password, each key press for a character has to go somewhere for the system to know what you typed.  It has to assemble those characters into a password before it can do anything with the password.  A program that can snoop on what is being typed in can see your password that way.  Think more a keylogger than actual password storage.

    Obviously, if you're typing your password into a program, that program needs to be able to see what you're typing in.  The OS kernel can see the keys typed and pass the information along to the active program that needs to see it.  But other, unrelated programs without the proper privileges that happen to be running on the computer at the same time shouldn't be able to see it.  More generally, one program shouldn't be able to arbitrarily see another program's internal memory, though there are some cases where it's allowed.
  • QuizzicalQuizzical Member LegendaryPosts: 22,096
    edited January 2018
    gervaise1 said:
    The base links:

    https://spectreattack.com/spectre.pdf
    https://meltdownattack.com/meltdown.pdf

    Reading these indicates that the fundamental issue stems from how computing has developed in the last few years.  As the Spectre paper concludes the drive to maximise performance.

    Both papers make clear that as all manufacturers / developers have gone in the same general direction this a cross-hardware, cross-operating system issue. The fact that something they did worked on one combo and not another, in their opinion, doesn't suggest a given combo is "immune" simply that they hadn't got the "attack" right. 



    What is comforting is that this stuff is pursued by e.g. the EU and fully supported by Intel/Qualcomm/AMD/ARM/MS/Google etc. 


    And its why people should keep their software up-to-date!  (Yes, yes its the Martian conspiracy.) 
    There are plenty of gradations between vulnerable and immune.  "I believe it's possible" is a long way from "I've demonstrated how to do it".  And a proof of concept is itself a long way from cyber-criminals being able to use it to steal from you.  You can't make computers 100% immune to all possible exploits, but if one system is considerably harder to attack than another, that's a big deal.
    KyleranTorval
  • Solar_ProphetSolar_Prophet Member EpicPosts: 1,956
    bcbully said:
    I bet SHIELD is behind this.
    Hail HYDRA!

    AN' DERE AIN'T NO SUCH FING AS ENUFF DAKKA, YA GROT! Enuff'z more than ya got an' less than too much an' there ain't no such fing as too much dakka. Say dere is, and me Squiggoff'z eatin' tonight!

    We are born of the blood. Made men by the blood. Undone by the blood. Our eyes are yet to open. FEAR THE OLD BLOOD. 

    #IStandWithVic

  • gervaise1gervaise1 Member EpicPosts: 6,919
    Quizzical said:
    gervaise1 said:
    The base links:

    https://spectreattack.com/spectre.pdf
    https://meltdownattack.com/meltdown.pdf

    Reading these indicates that the fundamental issue stems from how computing has developed in the last few years.  As the Spectre paper concludes the drive to maximise performance.

    Both papers make clear that as all manufacturers / developers have gone in the same general direction this a cross-hardware, cross-operating system issue. The fact that something they did worked on one combo and not another, in their opinion, doesn't suggest a given combo is "immune" simply that they hadn't got the "attack" right. 



    What is comforting is that this stuff is pursued by e.g. the EU and fully supported by Intel/Qualcomm/AMD/ARM/MS/Google etc. 


    And its why people should keep their software up-to-date!  (Yes, yes its the Martian conspiracy.) 
    There are plenty of gradations between vulnerable and immune.  "I believe it's possible" is a long way from "I've demonstrated how to do it".  And a proof of concept is itself a long way from cyber-criminals being able to use it to steal from you.  You can't make computers 100% immune to all possible exploits, but if one system is considerably harder to attack than another, that's a big deal.
    Agree. And it would be a big deal. However:

    If they spent x months (say) getting something to work on one but couldn't get that key to work on a different combo after a week (say) of tweaks that doesn't mean that they couldn't develop a key from scratch in x months (say).

    Clearly there was a given level of funding coupled with the impetus to make the information available to interested parties especially as they had proof of concept across all platforms. Also interesting that they were doing this stuff on Haswells - suggesting the initial work pre-dates the latest generation cpus.

    So I totally agree with what you say but its not a conclusion they jump to. The door is there is what they are essentially saying.  
  • QuizzicalQuizzical Member LegendaryPosts: 22,096
    Here's AMD's take on it:

    https://www.amd.com/en/corporate/speculative-execution

    Linus Torvalds is not impressed with Intel's PR statement:

    https://lkml.org/lkml/2018/1/3/797
  • TorvalTorval Member LegendaryPosts: 19,952
    Quizzical said:
    Here's AMD's take on it:

    https://www.amd.com/en/corporate/speculative-execution

    Linus Torvalds is not impressed with Intel's PR statement:

    https://lkml.org/lkml/2018/1/3/797
    Poor Linus. Why isn't it the year of the Linux desktop? Why don't you make your own CPU? Why do we still cling to legacy hardware and software vestiges that haunt us? Linux has as much of that stupid cruft as Microsoft or Apple or BSD. So many questions Linus like why can't you manage your own kernel project better?

    Yeah, ARM64 Linus. You just shot your argument in the head with such a stupid suggestion. It amazes me when such a smart person pops off such dumb shit when their own backyard is such a fucking mess.
    AmazingAvery
    Fedora - A modern, free, and open source Operating System. https://getfedora.org/

    traveller, interloper, anomaly, iteration


  • RidelynnRidelynn Member EpicPosts: 7,060
    Wasn't Linus a contributor on Transmeta? Not that Transmeta really went anywhere, and maybe that's your point.

    Linus is worthy of some admiration, in the same vein as Carmack, Romero, Wozniak, Gates, Hopper, Englebart, Bush, Kay, and other legends in the computer industry.

    He's still entitled to his opinion on things, but yeah, that doesn't necessarily mean his opinion on things (outside of Linux Kernals specifically) really carries any more weight than any other armchair quarterback.
    Torval
  • TorvalTorval Member LegendaryPosts: 19,952
    Ridelynn said:
    Wasn't Linus a contributor on Transmeta? Not that Transmeta really went anywhere, and maybe that's your point.

    Linus is worthy of some admiration, in the same vein as Carmack, Romero, Wozniak, Gates, Hopper, Englebart, Bush, Kay, and other legends in the computer industry.

    He's still entitled to his opinion on things, but yeah, that doesn't necessarily mean his opinion on things (outside of Linux Kernals specifically) really carries any more weight than any other armchair quarterback.
    I'm a huge fan of his (he was an influence in picking this gaming alias actually), but he says some dumb stuff sometimes. It's not like he's completely wrong but it's annoying how he throws out all the other contributing factors that led to what he's upset with so he can craft his point.

    I do get his point but his criticism is way out of line considering the context and all the other factors involved and that the kernel team isn't a model of how to do it right.

    Beyond that the ARM64 comment feels more like a kneejerk response to take a cheap shot at Intel (which deserves it) but it doesn't actually add to moving forward. He's just adding to the noise at this point.

    I had totally forgotten about Transmeta. I'm not sure what he did there or when he worked for them. It's a funny twist of irony that his kernel is GPL and a keystone in the open source movement and all the work, IP, copyrights, and patents were bought by a patent troll company when Transmeta went under. According to wiki they license out the patents on a non-exclusive basis.

    Sometimes when shoots his mouth off it reminds me of the adage that people who live in glass houses shouldn't throw stones.
    Ridelynn
    Fedora - A modern, free, and open source Operating System. https://getfedora.org/

    traveller, interloper, anomaly, iteration


  • QuizzicalQuizzical Member LegendaryPosts: 22,096
    https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

    Just about every Intel processor that has released since Bloomfield in 2008 is affected.  Some of the early Atom CPUs might not be, as speculative execution doesn't make sense on an architecture that doesn't support out of order execution.

    If you want to go all conspiracy theorist like Wizardry, then here's something that should raise eyebrows:

    http://www.businessinsider.com/intel-ceo-krzanich-sold-shares-after-company-was-informed-of-chip-flaw-2018-1

    Apparently Intel's CEO sold as much of the company stock as he was contractually allowed to after learning of the flaw.  It's common for CEOs to set plans to sell stock far in advance so as to avoid allegations of insider trading because something negative happens shortly before they were going to sell the stock anyway.  But he only set his plan to sell the stock about a month before he actually sold it, and well after Google had informed Intel of the problem.
    Torval
  • OzmodanOzmodan Member EpicPosts: 9,726
    Kyleran said:
    Appears AMD is not immune, at least to Spectre attack.

    Jury still seems to be out on AMD and Meltdown.


    AMD is not vulnerable to Meltdown.  I believe from reading the microsoft announcement that their patch affects both cpus.  
  • AmazingAveryAmazingAvery Age of Conan AdvocateMember UncommonPosts: 7,179
    http://www.dsogaming.com/news/windows-10-intel-security-update-is-now-available-six-triple-a-games-tested-in-cpu-bound-scenarios/

    https://www.techspot.com/article/1554-meltdown-flaw-cpu-performance-windows/

    Conclusion, so far

    Well, there you have it. Desktop users have little to worry about in terms of performance loss, particularly gamers. We've yet to test older CPUs, but given the type of workloads we’re seeing impacted by the patch, I don’t think there’s going to be an issue with any desktop hardware, but we’ll certainly report back if there is.

    The reduction in 4K read performance for high speed NVMe drives is a concern and while this shouldn’t impact any games, any application that is sensitive to this might show a reduction in performance. Of course the brief list of applications I tested showed no real reduction in performance period.

    The issue nonetheless remains and is one that has a far bigger potential in affecting servers. It's a serious concern for data centers both on the side of performance and more importantly, security. That's not our area of expertise or interest, so we'll leave that testing to those better equipped to tackle it.

    TorvalRidelynn



  • BladeburaibaBladeburaiba Member UncommonPosts: 117
    Quizzical said:

    Passwords would not be stored long-term in kernel memory.  If done properly, passwords shouldn't be stored long-term anywhere.  Rather, you hash a password and store the hash.  The hash itself could be stored in the clear, but given a good password and a good hash function, recovering the password from the hash of it is impractical.

    *snip*

    Thank you, the whole response filled in some blanks for me.

    Then does this mean a keylogger would be better for the purpose of reading information than this exploit?  I guess getting someone to visit your website would be easier than getting them to install your keylogger though.

    Additionally, this was deemed a hardware issue, but my laymen understanding wants to say this seems more like a software issue.  Is it accurate to say that the software implementation of this "Speculative Execution" feature is allowing the exploit to happen?  Or is it just that the feature itself is inherently risky?

  • RidelynnRidelynn Member EpicPosts: 7,060
    Quizzical said:

    Passwords would not be stored long-term in kernel memory.  If done properly, passwords shouldn't be stored long-term anywhere.  Rather, you hash a password and store the hash.  The hash itself could be stored in the clear, but given a good password and a good hash function, recovering the password from the hash of it is impractical.

    *snip*

    Thank you, the whole response filled in some blanks for me.

    Then does this mean a keylogger would be better for the purpose of reading information than this exploit?  I guess getting someone to visit your website would be easier than getting them to install your keylogger though.

    Additionally, this was deemed a hardware issue, but my laymen understanding wants to say this seems more like a software issue.  Is it accurate to say that the software implementation of this "Speculative Execution" feature is allowing the exploit to happen?  Or is it just that the feature itself is inherently risky?

    Well what Quiz says is true and all,

    But the danger of these particular flaws is, someplace, something has to calculate the hash against a key, and see if it matches.

    This flaw may not get you a plaintext password, but it ~can~ expose hashes and keys, which is all you need to get to a plaintext password.

    It's a huge deal in the server realm, particularly cloud servers. The people who are looking to leverage it won't necessarily be looking for your password on your PC. But imagine if they could get on an Amazon AWS server, or Microsoft Azure server, or a Google data center - all the hundreds/thousands/millions of credentials from one infection.
    Quizzical
  • BladeburaibaBladeburaiba Member UncommonPosts: 117
    Ridelynn said:

    Well what Quiz says is true and all,

    But the danger of these particular flaws is, someplace, something has to calculate the hash against a key, and see if it matches.

    This flaw may not get you a plaintext password, but it ~can~ expose hashes and keys, which is all you need to get to a plaintext password.

    It's a huge deal in the server realm, particularly cloud servers. The people who are looking to leverage it won't necessarily be looking for your password on your PC. But imagine if they could get on an Amazon AWS server, or Microsoft Azure server, or a Google data center - all the hundreds/thousands/millions of credentials from one infection.

    One would hope that information would be encrypted.  However, I worked at a place where we knew that was a huge vulnerability, but the cost of going back and retrofitting encryption was enormous (I was responsible for getting funding for it).

    I am more worried about the government systems.  Honestly, our information is not safe, now especially when this vulnerability.
  • QuizzicalQuizzical Member LegendaryPosts: 22,096
    Quizzical said:

    Passwords would not be stored long-term in kernel memory.  If done properly, passwords shouldn't be stored long-term anywhere.  Rather, you hash a password and store the hash.  The hash itself could be stored in the clear, but given a good password and a good hash function, recovering the password from the hash of it is impractical.

    *snip*

    Thank you, the whole response filled in some blanks for me.

    Then does this mean a keylogger would be better for the purpose of reading information than this exploit?  I guess getting someone to visit your website would be easier than getting them to install your keylogger though.

    Additionally, this was deemed a hardware issue, but my laymen understanding wants to say this seems more like a software issue.  Is it accurate to say that the software implementation of this "Speculative Execution" feature is allowing the exploit to happen?  Or is it just that the feature itself is inherently risky?

    If you're trying to steal someone's password, then yes, a keylogger is a more effective way to do it than a meltdown attack.  Of course, you can't just kindly ask someone to install a keylogger so that you can steal his password and expect much in the way of success.  It takes using some sort of security flaw (if one counts idiot users as a security flaw) to get the keylogger installed in the first place.

    As Ridelynn said, stealing a user's password is hardly the worst of it.  It's far more of a problem for cloud servers with a ton of virtual machines than it is for consumers.
  • QuizzicalQuizzical Member LegendaryPosts: 22,096
    Ridelynn said:

    Well what Quiz says is true and all,

    But the danger of these particular flaws is, someplace, something has to calculate the hash against a key, and see if it matches.

    This flaw may not get you a plaintext password, but it ~can~ expose hashes and keys, which is all you need to get to a plaintext password.

    It's a huge deal in the server realm, particularly cloud servers. The people who are looking to leverage it won't necessarily be looking for your password on your PC. But imagine if they could get on an Amazon AWS server, or Microsoft Azure server, or a Google data center - all the hundreds/thousands/millions of credentials from one infection.

    One would hope that information would be encrypted.  However, I worked at a place where we knew that was a huge vulnerability, but the cost of going back and retrofitting encryption was enormous (I was responsible for getting funding for it).

    I am more worried about the government systems.  Honestly, our information is not safe, now especially when this vulnerability.
    Even if the information is encrypted at rest, it has to be decrypted for someone to do anything useful with it.  The problem with meltdown is that it could let one user see another user's ordinarily encrypted information while its decrypted in memory.
  • WraithoneWraithone Member RarePosts: 3,803
    If you want crazy conspiracy theory, one wonders how long No Such Agency and the Company have known about this?... Not to mention what ever else they are keeping to themselves.
    Ridelynn
    "If you can't kill it, don't make it mad."
  • RidelynnRidelynn Member EpicPosts: 7,060
    Ridelynn said:

    Well what Quiz says is true and all,

    But the danger of these particular flaws is, someplace, something has to calculate the hash against a key, and see if it matches.

    This flaw may not get you a plaintext password, but it ~can~ expose hashes and keys, which is all you need to get to a plaintext password.

    It's a huge deal in the server realm, particularly cloud servers. The people who are looking to leverage it won't necessarily be looking for your password on your PC. But imagine if they could get on an Amazon AWS server, or Microsoft Azure server, or a Google data center - all the hundreds/thousands/millions of credentials from one infection.

    One would hope that information would be encrypted.  However, I worked at a place where we knew that was a huge vulnerability, but the cost of going back and retrofitting encryption was enormous (I was responsible for getting funding for it).

    I am more worried about the government systems.  Honestly, our information is not safe, now especially when this vulnerability.
    Yeah that's the scary part about these vulnerabilities. It doesn't matter if your information is encrypted if the keys get stolen.
  • TorvalTorval Member LegendaryPosts: 19,952
    Ridelynn said:
    Ridelynn said:

    Well what Quiz says is true and all,

    But the danger of these particular flaws is, someplace, something has to calculate the hash against a key, and see if it matches.

    This flaw may not get you a plaintext password, but it ~can~ expose hashes and keys, which is all you need to get to a plaintext password.

    It's a huge deal in the server realm, particularly cloud servers. The people who are looking to leverage it won't necessarily be looking for your password on your PC. But imagine if they could get on an Amazon AWS server, or Microsoft Azure server, or a Google data center - all the hundreds/thousands/millions of credentials from one infection.

    One would hope that information would be encrypted.  However, I worked at a place where we knew that was a huge vulnerability, but the cost of going back and retrofitting encryption was enormous (I was responsible for getting funding for it).

    I am more worried about the government systems.  Honestly, our information is not safe, now especially when this vulnerability.
    Yeah that's the scary part about these vulnerabilities. It doesn't matter if your information is encrypted if the keys get stolen.
    I've seen a bunch of "security experts" recommending people change their passwords using a password manager. Good advice, but think about it for a bit, rushing out to change all your passwords in a fright in the midst of multiple unpatched vulnerabilities.

    It's kind of like changing your password when someone else still has the same hash. No wait, that's exactly what it's like. :lol:
    Octagon7711Aethaeryn
    Fedora - A modern, free, and open source Operating System. https://getfedora.org/

    traveller, interloper, anomaly, iteration


  • Loke666Loke666 Member EpicPosts: 21,441
    Quizzical said:
    Asm0deus said:

    Ryzen not affected. Does this make Ryzen more desirable do you think?
    The question isn't whether it makes Ryzen relatively more appealing, but how much.  It could be anywhere from a rounding error to Ryzen suddenly being the CPU with the best per-core performance.
    Is Ryzen really not affected? My local newspaper said it affected ARM chips and AMD chips as well but didn't specify the models.

    Yeah, I havn't bothered to read up on it myself, havn't gotten much sparetime lately and you usually know this kind of stuff... ;)
  • QuizzicalQuizzical Member LegendaryPosts: 22,096
    Loke666 said:
    Quizzical said:
    Asm0deus said:

    Ryzen not affected. Does this make Ryzen more desirable do you think?
    The question isn't whether it makes Ryzen relatively more appealing, but how much.  It could be anywhere from a rounding error to Ryzen suddenly being the CPU with the best per-core performance.
    Is Ryzen really not affected? My local newspaper said it affected ARM chips and AMD chips as well but didn't specify the models.

    Yeah, I havn't bothered to read up on it myself, havn't gotten much sparetime lately and you usually know this kind of stuff... ;)
    There are multiple attacks, and some people (that is, Intel) wants to run them all together to confuse people.

    Meltdown is a clearer, easier to implement class of attacks that nearly all Intel CPUs of the last decade are vulnerable to, but recent AMD CPUs (including Ryzen, FX series, recent APUs, etc.) are categorically immune to.  Meltdown can be patched away in software, but doing so brings a performance hit, as you have to play games to force the CPU to clear some caches when switching from one user to another or between a user and the kernel.  For consumer use, the performance hit will tend to be minimal (e.g., 1%), but for servers running a lot of virtual machines that need to share time on a CPU without mixing their data together, the performance hit could be huge.  That's the common scenario that led people to cite a 30% performance hit.

    Spectre is a much more nebulous and harder to implement class of attacks.  Thus far, the only public, successful implementation of Spectre on an AMD CPU required changing some kernel settings to not be the default.  There have been successful implementations of Spectre on Intel and ARM CPUs without having to change other system settings, but running the same implementation on an AMD CPU failed.  People vaguely believe that Spectre can be done on AMD CPUs, but that they just haven't gotten the details quite right yet.

    Spectre is not so much a single attack as a new class of attacks.  You can apply a software patch to fix any particular attack in the class that shows up, and with a negligible performance hit.  But you can't make a patch that will categorically fix Spectre entirely.  The only 100% fix for it would be to drop speculative execution entirely, which would require physically replacing the CPUs with other, much slower CPUs.

    Spectre being so hard to implement and so hardware-dependent makes me think that it might never really amount to anything.  Certainly, they should patch to fix any particular example of it that researchers can come up with.  And I'm not saying that Spectre should be ignored; it might end up being a huge problem.  But it wouldn't be surprising if a decade from now, there hasn't been a single significant malware or hacking incident that relied on a Spectre attack.

    In terms of the relative desirability of various hardware, I don't think that Spectre really changes anything.  Meltdown is only marginally relevant to consumer use, and the net advantage to AMD over Intel is basically a rounding error, so it's not a very strong reason to prefer Ryzen over Coffee Lake unless you're doing something very unusual.

    Servers are where Meltdown is a huge deal, and it is a strong reason to favor Epyc over Xeon if you're running a ton of virtual machines.  You probably won't see an official, public announcement of this happening, but it wouldn't be surprising if Amazon or Google or some other company with a huge cloud presence places a huge order for Epyc CPUs that would have been Xeon if not for Meltdown.

    For any future server CPUs that aren't too far along into the design to change it, Intel will presumably fix Meltdown in hardware so that it doesn't need the patch to slow it down.  For such CPUs to show up at retail could easily be 2-3 years away, however, which leaves a lot of time for AMD to sell Epyc CPUs.
    SandmanjwTorvalOzmodanPhry
  • QuizzicalQuizzical Member LegendaryPosts: 22,096
    There is an enormous caveat that I don't entirely understand it, so I might well be getting some detail(s) wrong, but I think that Meltdown goes something like this:

    A program does a system call to get some kernel memory loaded into a CPU's L1 cache, and then the kernel finishes what it was asked to do and returns control to the user program, while still having some kernel memory cached in L1.

    The program then has a for loop that asks the program to compute B[A[x]] repeatedly and do something with it.  It ensures that all of the calls are legitimate and within the bounds of the array except for the last one.  The earlier calls in the for loop are to get speculative execution to guess that the last one will also be legitimate and speculatively execute it until it realizes that it has to abort because it's invalid.

    The last call doing B[A[x]] with x outside the bounds of A tries to access something in kernel memory, then do a table lookup using the value as an address.  Because this speculatively executes, the CPU loads something into L1 cache, and has to evict something else from L1 cache to make room.  Which data it clears out of cache depends on the value of A[x], that is, the data in kernel memory.  Thus, even after speculative execution terminates and says that you're not allowed to see A[x], nor B[A[x]], you can still check to see which values are still in L1 cache by trying to access them and timing to see how long it takes.  If it's still in L1 cache, it will be faster than having to go to L2 cache.

    This can't get you the full 64 bits of A[x] in a single go, but you have time to do a few very fast operations and get some of the bits each time.  After enough iterations, you have all of A[x]--an 8 byte value from kernel memory.  Then you can repeat to try to get another 8 byte value from kernel memory.  Apparently they've got an attack that can read kernel memory at a rate of about 2 KB/sec.

    So why are AMD CPUs immune to this?  If an AMD CPU sees that you have some kernel memory in L1 cache, it decides that user code is not allowed to do speculative execution.  Thus, when you try to compute B[A[x]], it checks to see if A[x] is inside user memory before computing B[A[x]].  When it isn't, it never computes B[A[x]], so it never evicts something from L1 cache to make room for B[A[x]] and the attack completely fails.  Researchers were able to get a similar attack to have one program read the "wrong" memory from the same program on an AMD CPU, but that's not a security problem in itself, as a program is allowed to see all if its own memory.

    AMD CPUs do take some performance hit for refusing to do speculative execution shortly after returning from a system call.  That performance hit is far milder than the solution to fix the security hole on an Intel CPU, however.  On an Intel CPU, the patch is to forcibly clear the entire contents of the L1 cache whenever a kernel returns from a system call so that there is no kernel memory left in L1 cache.  They can do that by loading a bunch of junk to get it cached in L1 until all of the "real" kernel memory that was cached in L1 has been forced out to make room.  You could still run the attack, but instead of it recovering the memory that the kernel is actually using, it would only recover some junk that the kernel intentionally filled L1 cache with before returning from a system call.

    So why aren't AMD CPUs also immune to Spectre?  They don't want to stop speculative execution whenever L1 cache merely has data from different threads or different processes from the same user.  That situation is very, very common, and would cause a huge performance hit if speculative execution were disabled.  Spectre won't allow a program to read kernel memory, but it can allow a program to read another program's memory that it shouldn't have access to.

    Spectre is much harder to get anything useful out of than Meltdown, however.  There are vastly more programs than OS kernels in the world, and it's much harder to know which version of which program with its memory arranged in which way that you're looking at.  The only program data that will be in L1 cache is that which is actively being used--and likely in the process of being changed, anyway.  You also don't have a nice way to get some other program to load the data you want to see into L1 cache, whereas you can easily get kernel memory loaded by doing a system call in the middle of your program to ask the kernel to do something.
    Torval
Sign In or Register to comment.