7 ms·

The AMD Branch (Mis)Predictor Part 2: Where No CPU Has Gone Before

152 points by g0xA52A2A 5y ago

RcouF1uZ4gsC 5y ago
SPS Theorem Pick two: Shared Physical Hardware Performance Security
- BuckRogers 5y ago
  How does that relate to what Apple has with the M and A-series chips? They seem to have all 3.
- mjevans 5y ago
  Pick, __at most__, two
CorrectHorseBat 5y ago
Too bad Grsecurity isn't able to work together with upstream, their security knowledge seems to be legit.
- staticassertion 5y ago
  Alternatively phrased, too bad upstream isn't able to work with Grsecurity.
  - throwawaylinux 5y ago
    grsecurity has a vested interest in having (or being seen to have) better security than upstream. Maybe upstream is able to work with hundreds of different and competing companies and thousands of different people and clashing personalities and opinions, but they just happen to irrationally refuse to treat grsecurity fairly. Or maybe it's the simpler explanation that has more obvious motives.
    - wahern 5y ago
      As I recall, one aspect of the tension originated from Linus' express hostility to pure security mitigations. IOW--and I don't know if this is the case today, especially after Spectre--Linus and a large part of the community were resistant to mitigations and code refactors that didn't actually add functional behavior, and especially if they were visible to userspace, harming backward compatibility. But those types of patches were precisely what grsecurity was pushing. So you basically had a fundamental clash of philosophies (independent of the clash of personalities) about whether the work grsecurity was doing was even valid from a software engineering standpoint. Arguably because of the relentless onslaught of exploits and growing enterprise influence, the Linux community slowly relented, but never with a mea culpa, AFAIK. A similar dynamic played out with /dev/urandom, where the Linux community and subsystem maintainers were adamant that the existing blocking and entropy accounting behaviors were crucial to security and non-negotiable. But now look where things stand--both are gone after 10-15+ years of debate. Again, without any mea culpas. Ditto for sandbox-friendly interfaces. Once upon a time any grievance that an interface which relied on /proc, /dev, or similar was suboptimal from a sandboxing standpoint (kernel surface area, headaches with chroots, etc) was met with derision. Eventually we got getrandom(2), and other recent application interfaces, like process descriptors, were revised so they were usable without /proc or similar. You could see alot of this play out on Slashdot, HN, etc as commenters frequently parroted Linux developers' talking points and assertions. There's plenty of blame to go around.
      - throwawaylinux 5y ago
        Many security mitigations have been merged into the kernel for a long time, probably longer than grsecurity has been around, but certainly something like NX-bit you could use as an example which was around the same time as early grsec (early 2000s). Sure Linus has been hostile or funny about such things at times, but that has not prevented him from being convinced or them from being merged.
    - staticassertion 5y ago
      Right, that's why they gave away their work for free for decades?
- nix23 5y ago
  Too Bad Linus once called them Clowns [3]...but hey there's also [1] and [2] ;) 1: https://hardenedbsd.org/ https://hardenedbsd.org/ 2: https://www.openbsd.org/ https://www.openbsd.org/ 3: https://www.spinics.net/lists/kernel/msg2540934.html https://www.spinics.net/lists/kernel/msg2540934.html 2008 (Linus): >>I think the OpenBSD crowd is a bunch of [self-stimulating] monkeys 2019 (Greg KH): >>OpenBSD was right on disabling hyper-threading
  - loeg 5y ago
    HardenedBSD are clowns. OpenBSD has some good ideas, some clownish ideas, but as a user you cannot separate the two and as a developer community, they aren't interested in reducing the clown factor. GRSecurity also has some great ideas and some silly.
    - nix23 5y ago
      >HardenedBSD are clowns. Ahh that's why OPNsense uses it? But hey you write like a real professional in that field so i believe you, instead the people who actually work day in day out on a professional firewall product. Maybe you have to acknowledge that there is just one clown here ;)
      - loeg 5y ago
        I can't speak to OPNsense's judgment. I am a real professional in that field -- I've worked on FreeBSD in the past, and interacted with HBSD folks professionally.
cwillu 5y ago
The final pithy quote about how a prominent linux developer claimed no cpu would ever do such a thing, loses some of its impact when you realize that a _more_ prominent linux developer replied saying “I think, when it comes to speculative execution, our general expectation that CPUs don't do idiotic things got somewhat weakened in the past year or so ...”
- throwawaylinux 5y ago
  > linux developer This goes to show you that the software and digital logic design space is very different, and you should not assume any amount of experience and knowledge in one will prepare you for the realities of the other. Sure it seems astounding that a CPU would speculate not-taken over a static, direct, unconditional branch. Surely no sane logic designer would ever do such a thing! When you realize doing that might require more logic in a downstream stage after fetch and after the branch was decoded, and from there you need more control logic and wires going to other stages and logic to re-steer the pipeline in possibly a different manner or stage than would otherwise be required, and all that requires validation and verification (which can easily become a multiplicative effort), and if doing all of that did not bring you performance gains that outweighed the cost, and if you didn't understand the possible security implication or considered it to also not be worth the cost, then actually it's quite understandable for a reasonable implementation to behave this way. Even the second quote smells a bit like dunning kruger. Everything has bugs or misfeatures, especially with hindsight. Everyone (including Linus and many other kernel developers) thought that the massive speculation capability and correspondingly astounding performance results on privilege domain crossing for Intel CPUs was the duck's nuts back before spectre/meltdown. And they certainly didn't foresee or discover the security issues with doing that. (EDIT Disclaimer: Am linux developer and armchair microarchitect)
  - Someone 5y ago
    Indeed. If unconditional branches are rare enough it may not be worth the cost. Also, it’s not like software designers don’t waste cycles. In many languages, for example, arguments to log statements are evaluated even if logging is disabled. There sometimes is the hope that the runtime will figure that out and move that inside the if logging is enabled check, but that’s only a hope (COBOL had the ALTER statement for efficiently handling such things, but that’s being frowned upon :-)) Also: a conditional branch can be always taken, for example when the software does an if cpu supports instruction extension at startup, sets a flag accordingly, and later branches depending on that flag. That, too, is a case where the CPU will speculatively execute what, to it, may look like garbage. So, you have to make sure speculative execution handles that.
B1FF_PSUVM 5y ago
Somehow the "Final remarks" section reminded me of the more paranoid "wheels within wheels" Frank Herbert fiction. Not pleasantly, the FH fiction wasn't, either.
Lascaille 5y ago
That's a great article. I do worry sometimes that something is up with CPU development, that we're tending towards more and more complicated designs with workflows that are very hard to analyse and simulate even for the designers themselves, but the actual workload execution ability performance per core isn't shifting upwards all that much, and then weird mitigations have to be applied that reduce that execution ability in practice. Something makes me think that perhaps a different design paradigm should prevail, with particular attention paid to segregation of workloads and of core partitioning, perhaps an abandoning of hyperthreading and even to the extent of having 100% physical separation of cores and their caches. But I'm very much not an expert in the field. A little birdie inside of me every now and then wakes up and whispers 'is it a coincidence that these design paradigms are yielding so many vulnerabilities?'
- timschmidt 5y ago
  https://millcomputing.com/ https://millcomputing.com/ springs to mind.
  - colejohnson66 5y ago
    The Mill architecture is vaporware. It’s been what? A decade? And there’s not even an FPGA demo yet? Not to mention that the whole idea of the Mill requires a “sufficiently smart compiler”. We tried VLIW (based on the same compiler ideals) with the Itanium and it was a major flop.
    - Lascaille 5y ago
      Itanium had a decent service life and a reasonable install base. It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. The Itanium platform was totally unaffected by Spectre/Meltdown type attacks, you may note.
      - toast0 5y ago
        > It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. Intel didn't want to make 64-bit x86, but the market prefered amd64 over itanium.
divyekapoor 5y ago
Very well done.
userbinator 5y ago
To my knowledge none of these side-channels, even the original ones several years ago, have been exploited practically in the wild. IMHO gathering the amount of detail needed to attempt such an attack, as exemplified by the demos that have been given, would itself be prohibitively difficult. Thus the impact of yet another one remains negligible to a personal computer user, but of course the cloud providers would be super-paranoid about it. It's worth noting that the memory protection scheme, introduced with the 286, was never intended to be a strong security barrier, but instead a means of isolating bugs and making them easier to debug.
- joe_guy 5y ago
  While not an in the wild big, I was a disbeliever that it could even be exploited from a browser, but just last year Google proved me wrong https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html?m=1 https://security.googleblog.com/2021/03/a-spectre-proof-of-c...
  - userbinator 5y ago
    If you have a precise enough timing and the machine is quiet enough, then yes you could always do it given enough time, but the question then becomes how to interpret the data that you do manage to read. Keys look like random data, and passwords are probably recognisable with enough semiautomated effort; but even if you manage to isolate those "needles in the haystack", you still have next to no idea what "lock" the key is for.
    - Groxx 5y ago
      I suppose this may be one unintended point in a crappy antivirus's favor: by slowing down everything and causing a ton of CPU noise, it might make these kinds of things harder to exploit.
    - Karliss 5y ago
      > Key looks like random data Not always. When using AES algorithm the key gets expanded and the expanded form can be distinguished from random data. Combination of RSA private key and public parameters should also be distinguishable from random data due to integer multiplication properties RSA uses. There are tools for searching encryption keys in program memory using such tricks to recognize them. Such tools would typically be used when a program like game or DRM media player runs on attacker controlled computer, but in theory would also help when fragments of memory can be leaked from a server due to side channel attacks or bugs like heart bleed.
throwawaylinux 5y ago
AMD is supposed (or does) have very good branch predictors. What's interesting to me is they don't do a re-steering of the wrong prediction well before later instructions are issued to the back end. Maybe their BTB is that good that they didn't see it worth investing in the control logic for it.
jimmaswell 5y ago
I went AMD for the first time with my new laptop. Some 8 core Ryzen. Games crash all the time, not sure if it'd the architecture's fault, and I can't properly virtualize Windows 98 (which I like to just for fun/nostalgia) apparently due to the architecture. I feel like I'm sticking with Intel from now on like my old gut instinct said to.
- jquery 5y ago
  With respect to games crashing, it's almost certainly not the architecture's fault. Far more likely is a system configuration or driver issue. I had more issues with my previous Intel build than my current Zen2 Ryzen (64 core TR). I have almost no issues with virtualization or gaming now. That said, my hardware is rarely pushed to its limits so that might be a factor. As an aside, given how Intel squandered its near-monopoly for years until AMD came up from behind and kicked 'em in the pants, I'll be sticking with AMD out of principle. I'm especially upset at some of the really dirty tricks Intel pulled in the past.
  - BuckRogers 5y ago
    To share the other side of the coin. Your experience, while valid, is not actually the norm from what I've read and experienced. I had 4 Ryzen chips since the initial launch in 2017 and none of them were as stable or fast as my current 8-core Intel system. All subsystems tested faster as well, including storage performance. I'm someone who buys and has the latest and greatest side by side. Random IOPS is off the charts faster on Intel my 1:1 tests between real-world system with the same drive. I had mediocre (but suitable) experiences with Athlon chips 22 years ago, with the same basic outcome: great CPUs, mediocre platform (chipset engineering etc). I understand your emotions about AMD and Intel, you may not be "wrong". I have no strong feelings on that, just want what works. But for holistic engineering my 40 years of PC building experience is persuasive towards Intel products.
  - vardump 5y ago
    "With respect to games crashing, it's almost certainly not the architecture's fault." Indeed. Especially for "AAA" games designed to run on major AMD-based consoles such as Xbox and Playstation. Those games might actually be slightly more likely to be broken on Intel systems!
morpheuskafka 5y ago
What does "code gadget" mean in this context?
- rodgerd 5y ago
  If you're very clever (unlike me) and you break into a modern running system, you'll find that there are a lot of protections to stop you just inserting your own code and running it. Smart people will look at the current executable code in the system, and work out how to manipulate the existing executable code to build the attacker's programs (return oriented programming); the identified chunks are called gadgets.
- gpderetta 5y ago
  A code gadget is any pre-existing string of binary code in an executable that by chance happens to have some specific properties that make it possible to be repurposed by an attacker, usually by jumping in the middle of it. IIRC the term was introduced with the Return Oriented Programming style of attacks and reused for spectre-like speculation attacks.
deleted 5y ago
[deleted]
unixbane 5y ago
the funny part is that PCs are shown to be unusuable for security sensitive things as usual and all this research will be used to optimize video games

152 points by g0xA52A2A 5y ago

RcouF1uZ4gsC 5y ago

SPS Theorem Pick two: Shared Physical Hardware Performance Security

BuckRogers 5y ago
How does that relate to what Apple has with the M and A-series chips? They seem to have all 3.
mjevans 5y ago
Pick, __at most__, two

CorrectHorseBat 5y ago

Too bad Grsecurity isn't able to work together with upstream, their security knowledge seems to be legit.

staticassertion 5y ago
Alternatively phrased, too bad upstream isn't able to work with Grsecurity.
- throwawaylinux 5y ago
  grsecurity has a vested interest in having (or being seen to have) better security than upstream. Maybe upstream is able to work with hundreds of different and competing companies and thousands of different people and clashing personalities and opinions, but they just happen to irrationally refuse to treat grsecurity fairly. Or maybe it's the simpler explanation that has more obvious motives.
  - wahern 5y ago
    As I recall, one aspect of the tension originated from Linus' express hostility to pure security mitigations. IOW--and I don't know if this is the case today, especially after Spectre--Linus and a large part of the community were resistant to mitigations and code refactors that didn't actually add functional behavior, and especially if they were visible to userspace, harming backward compatibility. But those types of patches were precisely what grsecurity was pushing. So you basically had a fundamental clash of philosophies (independent of the clash of personalities) about whether the work grsecurity was doing was even valid from a software engineering standpoint. Arguably because of the relentless onslaught of exploits and growing enterprise influence, the Linux community slowly relented, but never with a mea culpa, AFAIK. A similar dynamic played out with /dev/urandom, where the Linux community and subsystem maintainers were adamant that the existing blocking and entropy accounting behaviors were crucial to security and non-negotiable. But now look where things stand--both are gone after 10-15+ years of debate. Again, without any mea culpas. Ditto for sandbox-friendly interfaces. Once upon a time any grievance that an interface which relied on /proc, /dev, or similar was suboptimal from a sandboxing standpoint (kernel surface area, headaches with chroots, etc) was met with derision. Eventually we got getrandom(2), and other recent application interfaces, like process descriptors, were revised so they were usable without /proc or similar. You could see alot of this play out on Slashdot, HN, etc as commenters frequently parroted Linux developers' talking points and assertions. There's plenty of blame to go around.
    - throwawaylinux 5y ago
      Many security mitigations have been merged into the kernel for a long time, probably longer than grsecurity has been around, but certainly something like NX-bit you could use as an example which was around the same time as early grsec (early 2000s). Sure Linus has been hostile or funny about such things at times, but that has not prevented him from being convinced or them from being merged.
  - staticassertion 5y ago
    Right, that's why they gave away their work for free for decades?
nix23 5y ago
Too Bad Linus once called them Clowns [3]...but hey there's also [1] and [2] ;) 1: https://hardenedbsd.org/ https://hardenedbsd.org/ 2: https://www.openbsd.org/ https://www.openbsd.org/ 3: https://www.spinics.net/lists/kernel/msg2540934.html https://www.spinics.net/lists/kernel/msg2540934.html 2008 (Linus): >>I think the OpenBSD crowd is a bunch of [self-stimulating] monkeys 2019 (Greg KH): >>OpenBSD was right on disabling hyper-threading
- loeg 5y ago
  HardenedBSD are clowns. OpenBSD has some good ideas, some clownish ideas, but as a user you cannot separate the two and as a developer community, they aren't interested in reducing the clown factor. GRSecurity also has some great ideas and some silly.
  - nix23 5y ago
    >HardenedBSD are clowns. Ahh that's why OPNsense uses it? But hey you write like a real professional in that field so i believe you, instead the people who actually work day in day out on a professional firewall product. Maybe you have to acknowledge that there is just one clown here ;)
    - loeg 5y ago
      I can't speak to OPNsense's judgment. I am a real professional in that field -- I've worked on FreeBSD in the past, and interacted with HBSD folks professionally.

cwillu 5y ago

The final pithy quote about how a prominent linux developer claimed no cpu would ever do such a thing, loses some of its impact when you realize that a _more_ prominent linux developer replied saying “I think, when it comes to speculative execution, our general expectation that CPUs don't do idiotic things got somewhat weakened in the past year or so ...”

throwawaylinux 5y ago
> linux developer This goes to show you that the software and digital logic design space is very different, and you should not assume any amount of experience and knowledge in one will prepare you for the realities of the other. Sure it seems astounding that a CPU would speculate not-taken over a static, direct, unconditional branch. Surely no sane logic designer would ever do such a thing! When you realize doing that might require more logic in a downstream stage after fetch and after the branch was decoded, and from there you need more control logic and wires going to other stages and logic to re-steer the pipeline in possibly a different manner or stage than would otherwise be required, and all that requires validation and verification (which can easily become a multiplicative effort), and if doing all of that did not bring you performance gains that outweighed the cost, and if you didn't understand the possible security implication or considered it to also not be worth the cost, then actually it's quite understandable for a reasonable implementation to behave this way. Even the second quote smells a bit like dunning kruger. Everything has bugs or misfeatures, especially with hindsight. Everyone (including Linus and many other kernel developers) thought that the massive speculation capability and correspondingly astounding performance results on privilege domain crossing for Intel CPUs was the duck's nuts back before spectre/meltdown. And they certainly didn't foresee or discover the security issues with doing that. (EDIT Disclaimer: Am linux developer and armchair microarchitect)
- Someone 5y ago
  Indeed. If unconditional branches are rare enough it may not be worth the cost. Also, it’s not like software designers don’t waste cycles. In many languages, for example, arguments to log statements are evaluated even if logging is disabled. There sometimes is the hope that the runtime will figure that out and move that inside the if logging is enabled check, but that’s only a hope (COBOL had the ALTER statement for efficiently handling such things, but that’s being frowned upon :-)) Also: a conditional branch can be always taken, for example when the software does an if cpu supports instruction extension at startup, sets a flag accordingly, and later branches depending on that flag. That, too, is a case where the CPU will speculatively execute what, to it, may look like garbage. So, you have to make sure speculative execution handles that.

B1FF_PSUVM 5y ago

Somehow the "Final remarks" section reminded me of the more paranoid "wheels within wheels" Frank Herbert fiction. Not pleasantly, the FH fiction wasn't, either.

Lascaille 5y ago

That's a great article. I do worry sometimes that something is up with CPU development, that we're tending towards more and more complicated designs with workflows that are very hard to analyse and simulate even for the designers themselves, but the actual workload execution ability performance per core isn't shifting upwards all that much, and then weird mitigations have to be applied that reduce that execution ability in practice. Something makes me think that perhaps a different design paradigm should prevail, with particular attention paid to segregation of workloads and of core partitioning, perhaps an abandoning of hyperthreading and even to the extent of having 100% physical separation of cores and their caches. But I'm very much not an expert in the field. A little birdie inside of me every now and then wakes up and whispers 'is it a coincidence that these design paradigms are yielding so many vulnerabilities?'

timschmidt 5y ago
https://millcomputing.com/ https://millcomputing.com/ springs to mind.
- colejohnson66 5y ago
  The Mill architecture is vaporware. It’s been what? A decade? And there’s not even an FPGA demo yet? Not to mention that the whole idea of the Mill requires a “sufficiently smart compiler”. We tried VLIW (based on the same compiler ideals) with the Itanium and it was a major flop.
  - Lascaille 5y ago
    Itanium had a decent service life and a reasonable install base. It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. The Itanium platform was totally unaffected by Spectre/Meltdown type attacks, you may note.
    - toast0 5y ago
      > It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. Intel didn't want to make 64-bit x86, but the market prefered amd64 over itanium.

divyekapoor 5y ago

Very well done.

userbinator 5y ago

To my knowledge none of these side-channels, even the original ones several years ago, have been exploited practically in the wild. IMHO gathering the amount of detail needed to attempt such an attack, as exemplified by the demos that have been given, would itself be prohibitively difficult. Thus the impact of yet another one remains negligible to a personal computer user, but of course the cloud providers would be super-paranoid about it. It's worth noting that the memory protection scheme, introduced with the 286, was never intended to be a strong security barrier, but instead a means of isolating bugs and making them easier to debug.

joe_guy 5y ago
While not an in the wild big, I was a disbeliever that it could even be exploited from a browser, but just last year Google proved me wrong https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html?m=1 https://security.googleblog.com/2021/03/a-spectre-proof-of-c...
- userbinator 5y ago
  If you have a precise enough timing and the machine is quiet enough, then yes you could always do it given enough time, but the question then becomes how to interpret the data that you do manage to read. Keys look like random data, and passwords are probably recognisable with enough semiautomated effort; but even if you manage to isolate those "needles in the haystack", you still have next to no idea what "lock" the key is for.
  - Groxx 5y ago
    I suppose this may be one unintended point in a crappy antivirus's favor: by slowing down everything and causing a ton of CPU noise, it might make these kinds of things harder to exploit.
  - Karliss 5y ago
    > Key looks like random data Not always. When using AES algorithm the key gets expanded and the expanded form can be distinguished from random data. Combination of RSA private key and public parameters should also be distinguishable from random data due to integer multiplication properties RSA uses. There are tools for searching encryption keys in program memory using such tricks to recognize them. Such tools would typically be used when a program like game or DRM media player runs on attacker controlled computer, but in theory would also help when fragments of memory can be leaked from a server due to side channel attacks or bugs like heart bleed.

throwawaylinux 5y ago

AMD is supposed (or does) have very good branch predictors. What's interesting to me is they don't do a re-steering of the wrong prediction well before later instructions are issued to the back end. Maybe their BTB is that good that they didn't see it worth investing in the control logic for it.

jimmaswell 5y ago

I went AMD for the first time with my new laptop. Some 8 core Ryzen. Games crash all the time, not sure if it'd the architecture's fault, and I can't properly virtualize Windows 98 (which I like to just for fun/nostalgia) apparently due to the architecture. I feel like I'm sticking with Intel from now on like my old gut instinct said to.

jquery 5y ago
With respect to games crashing, it's almost certainly not the architecture's fault. Far more likely is a system configuration or driver issue. I had more issues with my previous Intel build than my current Zen2 Ryzen (64 core TR). I have almost no issues with virtualization or gaming now. That said, my hardware is rarely pushed to its limits so that might be a factor. As an aside, given how Intel squandered its near-monopoly for years until AMD came up from behind and kicked 'em in the pants, I'll be sticking with AMD out of principle. I'm especially upset at some of the really dirty tricks Intel pulled in the past.
- BuckRogers 5y ago
  To share the other side of the coin. Your experience, while valid, is not actually the norm from what I've read and experienced. I had 4 Ryzen chips since the initial launch in 2017 and none of them were as stable or fast as my current 8-core Intel system. All subsystems tested faster as well, including storage performance. I'm someone who buys and has the latest and greatest side by side. Random IOPS is off the charts faster on Intel my 1:1 tests between real-world system with the same drive. I had mediocre (but suitable) experiences with Athlon chips 22 years ago, with the same basic outcome: great CPUs, mediocre platform (chipset engineering etc). I understand your emotions about AMD and Intel, you may not be "wrong". I have no strong feelings on that, just want what works. But for holistic engineering my 40 years of PC building experience is persuasive towards Intel products.
- vardump 5y ago
  "With respect to games crashing, it's almost certainly not the architecture's fault." Indeed. Especially for "AAA" games designed to run on major AMD-based consoles such as Xbox and Playstation. Those games might actually be slightly more likely to be broken on Intel systems!

morpheuskafka 5y ago

What does "code gadget" mean in this context?

rodgerd 5y ago
If you're very clever (unlike me) and you break into a modern running system, you'll find that there are a lot of protections to stop you just inserting your own code and running it. Smart people will look at the current executable code in the system, and work out how to manipulate the existing executable code to build the attacker's programs (return oriented programming); the identified chunks are called gadgets.
gpderetta 5y ago
A code gadget is any pre-existing string of binary code in an executable that by chance happens to have some specific properties that make it possible to be repurposed by an attacker, usually by jumping in the middle of it. IIRC the term was introduced with the Return Oriented Programming style of attacks and reused for spectre-like speculation attacks.

deleted 5y ago

[deleted]

unixbane 5y ago

the funny part is that PCs are shown to be unusuable for security sensitive things as usual and all this research will be used to optimize video games