10 ms·

Intel FP security issue

373 points by stevekemp 8y ago

blattimwind 8y ago
The money quote is this: (OpenBSD): "3) post-Spectre rumors suggest that the %cr0 TS flag might not block speculation, permitting leaking of information about FPU state (AES keys?) across protection boundaries." AES-NI is part of the vector/FP units and uses those registers as well.
- mikec3010 8y ago
  I wonder if these "bugs" will create a market for security dongles that perform AES, RSA, etc? That way they aren't black boxes like CPUs that literally have minds of their own these days (IME). I would like to own a USB dongle that took files in and outputted them in encrypted form. Bonus if they were an open spec so you could have various vendors or open source FPGA versions. Bonus if the key load would be airgapped from the PC side, say via QRcode, hex buttons, microSD, Bluetooth with hardware disable switch, or even rfid. Yes that does create some new attack vectors, but these "bugs" make me think that the whole architecture is a rooted, burning trash fire.
  - sandworm101 8y ago
    >>but these "bugs" make me think that the whole architecture is a rooted, burning trash fire. The next architecture should/will have dedicated on-chip space for things like encryption. That we are mixing essential and trivial data in the same space, and expecting neither to leak into each other, is the root of the problem. I wouldn't be suprised if in ten years we are talking about L1 through L3 Cache, with a separate "LX" cache for the important security stuff.
    - bdamm 8y ago
      Absolutely that is future, you are right on. Witness ARM's "trust zone", Intel's SGX, chip vendors all over the place are making secure boot standard even for the lowest end micros. TPMs have been standard in laptops for almost a decade now. It's no longer optional to do key protection.
    - titzer 8y ago
      Well, I doubt it. If anything, Spectre points us in the direction of dedicated, simple, low-power cores that do no speculation for security sensitive tasks. Shared resources is the root of all sidechannel leaks, so my prediction is we will see, or at least should see, IMO, systems with multiple, separate physical chips, and maybe separate physical RAM, to run untrusted or sensitive code.
      - sandworm101 8y ago
        I don't think a separate chip for non-trusted code would work. When I play minecraft I don't want it to be relegated to some sub-chip because it isn't trusted. Conversely, the bits of code running my disk encryption shouldn't be sharing resources with minecraft. So I think the more practical route is dedicated space/chips/resources for security-related stuff, and the big chip for all the less important stuff. Now on a server, with a far greater proportion of security-related tasks, then we may need greater allocation to security. A split between security-specialized with lots of separate protected chips, and general-use CPUs with one bigger chip may be likely.
        shawnz 8y ago
        > When I play minecraft I don't want it to be relegated to some sub-chip because it isn't trusted. Why not relegate the trusted stuff to a sub-chip then? (i.e. TPMs in desktop PCs, or iOS' "secure enclave")
        sandworm101 8y ago
        Because drawing lines between trusted and non-trusted code isn't easy. Sometimes you need/want to dedicate all available processing power to a bit of trusted code (ie booting into windows). But other time you want to do the same for non-trusted (ie minecraft). Separate chips for each means you've basically halved your peak available horsepower (assuming both are of equal power). Rather than draw the line between trusted and not, I'd draw the line between security-related stuff (encryption keys) and everything else. Then the separate secure chip can be relatively small while the big chip remains available for everything else. (I say "chip" but I think it is more likely to be a separate 'core' on a chip, one with it's own cache and ram. It wouldn't need much of either.)
  - newnewpdro 8y ago
    It's one of the use cases for usbarmory [1], which has been around for a while now. [1] http://inversepath.com/usbarmory http://inversepath.com/usbarmory
  - bdamm 8y ago
    Well, yes. There is already a large market for these "security dongles", and many libraries and protocols for interacting with them. They're called HSMs and examples of libraries include PKCS#11, JCE, MCE, and protocols like KMIP. Widely used in the financial sectors, CAs (of course), revenue collection such as tolls, government functions such as passport issuance, and some kinds of industrial control segments, among others. It's long been the case that side-channel attacks can extract key materials out of conventional CPUs. Power analysis alone has been now a decades long science and not going away any time soon, made all the more exciting by the prevalence of RF and the advancement of antennas. Spectre and the like is just another wake-up for those not paying attention e.g. in cloud services. Consider yourself one of the enlightened when it comes to crypto material handling.
    - hamilyon2 8y ago
      Well, I worked with one of proprietary security tokens before. Nothing to be proud of, unpatched software/firmware bugs, zero responsibility of manufacturer and usability mess. The thing is, not only cryptography hardware and software itself should be safe, but whole system should be up-to date and have no weak links, which is hard in practice and few want to pay for it. Makes me think if there is any incentive to do crypto properly or security theater will always prevail?
      - tgtweak 8y ago
        I've had the unfortunate experience of integrating a gemalto network HSM and the broken state of the documentation alone is enough to make you question any engineering inside. It's security through obscurity.
    - 0x0 8y ago
      HSM devices, as I understand it, are designed mostly to protect secrets (keys) and perform asymmetric crypto operations safely but perhaps slowly. The Intel AES-NI, on the other hand, is designed for high speed fast symmetric crypto, with nothing kept secret to the user of the AES-NI instructions.
  - jonknee 8y ago
    No idea if it's good or not, but that sounds very similar to Nitrokey: https://www.nitrokey.com/ https://www.nitrokey.com/
  - ttul 8y ago
    https://www.yubico.com/products/yubikey-hardware/ https://www.yubico.com/products/yubikey-hardware/ These guys are the leaders in small USB crypto keys. Yes their devices offload various crypto routines; and they are cheap.
    - gcb0 8y ago
      they are not cheap as they are not even close to usable out of 2nd factor auth flows. actual hardware acelerators for servers and real world loads are much more expensive though, but you get much more than this. also the interface to yubikeys is a usb hid, much more trivial to exploit than the article's issue.
      - mynameisvlad 8y ago
        Well, firstly, they have HSM-grade hardware available as well. Secondly, they have crypto processors that let you use PGP or PKCS11 certificates with the private key and certificate operations happening on the device, directly integrated into native system utilities. Also, source on them being "much more trivial to exploit than the article's issue"? The only issue I've heard with Yubikey's certificate operations was https://www.yubico.com/keycheck/ https://www.yubico.com/keycheck/ where they also provided anyone affected with a replacement key at no charge.
        gcb0 8y ago
        > less secure vou posted on a thread about one process stealing memory from another using cpu delays. yubi key expose a device (or type as a usb keyboard), which every single user process have access to.
        mynameisvlad 8y ago
        > yubi key expose a device (or type as a usb keyboard), which every single user process have access to So? Are there any actual exploits you'd like to share that take advantage of either of these? Or are you just speaking in hypotheticals? Because in that case, basically everything you do on any computer that isn't airgapped (and even that can be exploited) is going to theoretically be exploitable.
  - amluto 8y ago
    There’s already a TPM in most computers, and the TPM can do this for you. Be careful, though: there are real TPMs (actual chips built by companies that, in theory, know how to build secure-ish hardware) and there are firmware-emulated TPMs. I think that Intel and AMD both offer the latter. Intel calls its offering “platform trust technology”. I take that to mean “please trust our platform even though there is sometimes a web server running on the same chip as the so-called TPM”.
    - SXX 8y ago
      > I think that Intel and AMD both offer the latter. Have no clue on Intel, but for AMD there is basically separate ARM core within CPU so it's has TrustZone built in. Is it just a web server too? I truly curious.
      - ZeikJT 8y ago
        I don't think they meant that the TPM itself runs a webserver. I believe what they mean was that the emulated version runs on the cpu itself, which means that if the system is also running a webserver then any cpu vulnerabilities would compromise the security of the emulated TMP.
        amluto 8y ago
        No, more like the former. As I understand it, the emulated TPM runs on the Intel ME, which can also run a webserver.
    - jandrese 8y ago
      Using a TPM for generic crypto operations is mostly outside of what they were designed to do. Real hardware TPMs tend to be very slow so they're not really useful for encrypting/decrypting network traffic, they're really supposed to be used to sign messages and verify checksums. They are also supposed to support full on trusted computing, but since it was designed by crypto nerds the trusted computing stuff is almost entirely useless. It completely blocks the CPU while running and is very slow so the practical use cases are very hard to find.
  - deleted 8y ago
    [deleted]
  - dboreham 8y ago
    Crypto was never supposed to be done on the main CPU. We're all using what is essentially the dev test implementation of pkcs#11 etc.
  - hamilyon2 8y ago
    Well, I worked with one of proprietary security tokens before. Nothing to be proud of, unpatched software/firmware bugs, zero responsibility of manufacturer and usability mess. The thing is, not only cryptography hardware and software itself should be safe, but whole system should be up-to date and have no weak links, which is hard in practice and few want to pay for it. Makes me think if there is any incentive to do crypto properly or security theater will always prevail?
    - sofaofthedamned 8y ago
      Had the same with HSM vendors - poorly patched versions of OpenSSL to talk to it (no upstream patches), functionality missing, months between vulns in OpenSSL and their version getting fixed - hopeless industry tbf.
  - mrsteveman1 8y ago
    The Pi Zero can do this as a USB client device for a host PC, including the QRCodes with the Pi camera, buttons/switches, and a small touchscreen for host-isolated verification and pin entry. Beaglebone Black (possibly also Pocket Beagle) can do it too, and the am335x does have some minimal crypto acceleration. They're not high performance, they aren't "security focused" hardware, nor are they perfect fit for the task, but they're reasonably well understood and broadly available. The Pi Zero does have a closed "GPU" firmware, but there is an effort[1] to run open firmware on it. However if you expect the host to attack the device, USB OTG (i.e. Linux USB gadget drivers) may not be a good choice, you may want to access it via network instead and that opens up more choices (though most will not be as small). The other alternatives are basically going to be micro-controllers, for example FST-01[2]/Gnuk[3], and FPGAs which are still more of a black box than CPUs at the moment. [1] https://github.com/christinaa/rpi-open-firmware https://github.com/christinaa/rpi-open-firmware [2] http://wiki.seeedstudio.com/FST-01/ http://wiki.seeedstudio.com/FST-01/ [3] https://wiki.debian.org/GNUK https://wiki.debian.org/GNUK
  - myself248 8y ago
    Isn't this what smartcards were supposed to do for us?
JStanton617 8y ago
So Intel tried to shut *BSD out of the process again (like they did for the original Spectre/Meltdown) so they didn't feel they had to respect any embargo?
- superflyguy 8y ago
  Eh? An embargo is where you share information with someone on the grounds they don't release it until a certain date. If you come by the information some other way then clearly you're not a party to the embargo.
  - Dylan16807 8y ago
    You can respect an embargo even if you got your information elsewhere.
    - tedunangst 8y ago
      The existence of the embargo is usually a secret as well. Hard to play the game when you're not told the rules.
    - throwaway2048 8y ago
      why would you? The language being used makes it sound like somehow openbsd is breaking agreements. Considering this appears to be the result of the false perception that OpenBSD breaks embargos they are a party too, its important to fight this loose usage of words.
      - tjoff 8y ago
        In the vast majority of cases it is the prudent way to go about it and not doing it (with intent) is often reckless and a dick move well deserved of criticism. This/these cases however might be an exception. I fully agree that one should be careful of propagating such false perceptions about OpenBSD (or any other entity).
        8y ago
stryk 8y ago
Can anyone breakdown the impact and severity of this in more digestible terms for those of us not that deeply technical?
- arbitrage 8y ago
  In the words of Bruce Schneier, "attacks only get better over time". It's basically another aspect of the branch-speculation bugs, not fixed by the original fixes.
  - nine_k 8y ago
    AFAICT it's not related to OOO execution, but rather to not cleaning normally accessible state after normal execution. No timers or tricky memory reads needed.
    - Symmetry 8y ago
      Yeah, probably if I'm understanding it right. This one seems less correlated with OoO than Meltdown or Spectre. It looks like you're just issuing a load based on FP register state you shouldn't touch. The system eventually notices it needs to have issued an exception based on the access to the FP register and eventually does quash the load within the core but the the load has already gone out to the memory hierarchy where you can see its effects on cache levels even though it never completes. Larger cores are harder to stop all at once than smaller cores so being OoO should correlate with being vulnerable but basically any pipelined processor that can throw an interrupt on register access could theoretically be vulnerable to something like this.
      - caf 8y ago
        I think you probably do need to execute the should-fault FP access in a not-executed speculatively executed branch (à la Meltdown), so that the exception doesn't actually fire and the kernel doesn't reload your own FP state. (Since you can only learn a small part of the state each time, you need to have the other processes state remain in the FPU while you repeat the process to learn the entire AES key or whatever).
amluto 8y ago
Linux hasn’t used CR0.TS for some time. I removed it a while back because manipulating TS is very very slow. (I am not part of any process with respect to this, embargoed or otherwise.) Edit: the upstream commit is 58122bf1d856a4ea9581d62a07c557d997d46a19, called “x86/fpu: Default eagerfpu=on on all CPUs”, and it landed in early 2016. Greg K-H just submitted backports to all older supported kernels.
- jwilk 8y ago
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=58122bf1d856a4ea9581d62a07c557d997d46a19 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- ericseppanen 8y ago
  Wasn't 212b02125f3 ("x86, fpu: enable eagerfpu by default for xsaveopt") sufficient protection for everyone on a modern CPU?
  - tgtweak 8y ago
    Eagerfpu seems to mitigate it, but some confirmation would be good here.
  - hansendc 8y ago
    That commit disables the lazy mode by default on processors supporting the XSAVEOPT instruction. But, it's possible to override that default with the eagerfpu= kernel command-line option, or that a hypervisor has masked out support for that instruction even on hardware with XSAVEOPT support. The point is: although relatively unlikely, it is still _possible_ that you need some mitigation even if you have newer hardware (Sandybridge or newer is where XSAVEOPT first showed up, I believe). Disclaimer: I work on Linux at Intel.
- yuhong 8y ago
  AFAIK the entire idea dates back to the days of the 80286/80287 (and 80386/80387) when accessing the coprocessor was slow, and a TSS switch (Linux used it until the late 1990s) set that bit for you.
0x006A 8y ago
an empire built on sand...
- striking 8y ago
  Hah, I get it. Because silicon is made of a particular kind of sand.
- PedroBatista 8y ago
  Literally and figuratively.
- hart_russell 8y ago
  built
notaplumber 8y ago
Dragonfly went a little further with this as well.. very precarious future ahead for us, I think.. http://lists.dragonflybsd.org/pipermail/commits/2018-June/672325.html http://lists.dragonflybsd.org/pipermail/commits/2018-June/67...
- koolba 8y ago
  I find it amazing how clean the diff for something like this is within the BSD source tree: http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/9474cbef7fcb61cd268019694d94db6a75af7dbe http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/9474...
  - tomxor 8y ago
    :) Some people go to great lengths to make commit history produce nice clean diffs... although I doubt anyone ever reads mine. Rebase, squash and split, your future self will thank you!
  - bonzini 8y ago
    Here's the Linux patch for this: https://patchwork.kernel.org/patch/10202865/ https://patchwork.kernel.org/patch/10202865/ It was done in February for Spectre ("variant 2"). Strange that Dragonfly is only starting now to clear registers.
- throwaway2048 8y ago
  I wonder if even this will be enough, it seems that modern x86 has hundreds/thousands of non externally visible hidden registers it uses for fast store/load (rather than a call to cache/ram). https://en.wikipedia.org/wiki/Register_renaming https://en.wikipedia.org/wiki/Register_renaming
  - caf 8y ago
    Once the architectural registers are zeroed in a path that can't be speculatively skipped, the other values in the register file are dead and can't be exposed.
pstuart 8y ago
Does this impact AMD as well? If not, might this bring further performance parity between the chipmakers?
- greglindahl 8y ago
  Linux appears to have patched things to avoid this problem on Intel and AMD more than 2 years ago, with the reasoning being that modern CPUs are fast in "eager" mode and "lazy" is not needed. So no, no performance difference for AMD as a result of this issue.
  - bonzini 8y ago
    It's not just that modern CPUs are fast in eager mode; also str* and mem* functions nowadays use the FPU (via SSE/AVX) and the dynamic loader (ld.so) uses them. Therefore Linux's heuristics switched to preloading the FPU anyway for most processes, even before the program code started running.
jokoon 8y ago
I am not a security expert, but I am still able to understand the low level of how software works. Yet I have been always mesmerized how hard it is to understand security stuff. Maybe it is because I don't find it interesting, as I am more interested in creative stuff like gaming. Honestly it has been maybe 10 since I've abandoned the idea of caring about security. I just do what is minimal: passwords, avoid sketchy websites, not keeping sensitive files, using trustworthy software, etc. Security is just too hard now. Maybe manufacturers like intel are to blame, and obviously there MUST be some political will to make sure that most electronics are insecure to give an advantage to intelligence agencies. Because ultimately when I first heard about the sony rootkit, and lately about the HD firmware worm, I was really feeling powerless and outdated. I really think that even for a guy like me, who can write software, to not be able to protect myself efficiently against those attacks, and to tell non-programmers that "no I cannot hack people's computers", is starting to make me feel like an idiot. As years go by it seems that electronics seem more and more vulnerable, and I still feel completely unable to defend myself against it. Even politically I'm sure that designing a completely secure computer would be a taboo subject because people would argue that it could help the bad guys, and I'm sure that politically, one could not design such a device with success. The whole "I don't care since I have nothing to hide" is really a fair excuse to show that I'm not capable of defending myself, and I will let others go at their cyber wars without me caring at all. For now the security of individuals seems to be lost, and I fear that one day it won't only be state actors that use security for policing, it will be petty criminals. If cyber chaos ensues nobody will use computers anymore, and they might even become banned from possession.
deleted 8y ago
[deleted]

373 points by stevekemp 8y ago

The money quote is this: (OpenBSD): "3) post-Spectre rumors suggest that the %cr0 TS flag might not block speculation, permitting leaking of information about FPU state (AES keys?) across protection boundaries." AES-NI is part of the vector/FP units and uses those registers as well.

mikec3010 8y ago
I wonder if these "bugs" will create a market for security dongles that perform AES, RSA, etc? That way they aren't black boxes like CPUs that literally have minds of their own these days (IME). I would like to own a USB dongle that took files in and outputted them in encrypted form. Bonus if they were an open spec so you could have various vendors or open source FPGA versions. Bonus if the key load would be airgapped from the PC side, say via QRcode, hex buttons, microSD, Bluetooth with hardware disable switch, or even rfid. Yes that does create some new attack vectors, but these "bugs" make me think that the whole architecture is a rooted, burning trash fire.
- sandworm101 8y ago
  >>but these "bugs" make me think that the whole architecture is a rooted, burning trash fire. The next architecture should/will have dedicated on-chip space for things like encryption. That we are mixing essential and trivial data in the same space, and expecting neither to leak into each other, is the root of the problem. I wouldn't be suprised if in ten years we are talking about L1 through L3 Cache, with a separate "LX" cache for the important security stuff.
  - bdamm 8y ago
    Absolutely that is future, you are right on. Witness ARM's "trust zone", Intel's SGX, chip vendors all over the place are making secure boot standard even for the lowest end micros. TPMs have been standard in laptops for almost a decade now. It's no longer optional to do key protection.
  - titzer 8y ago
    Well, I doubt it. If anything, Spectre points us in the direction of dedicated, simple, low-power cores that do no speculation for security sensitive tasks. Shared resources is the root of all sidechannel leaks, so my prediction is we will see, or at least should see, IMO, systems with multiple, separate physical chips, and maybe separate physical RAM, to run untrusted or sensitive code.
    - sandworm101 8y ago
      I don't think a separate chip for non-trusted code would work. When I play minecraft I don't want it to be relegated to some sub-chip because it isn't trusted. Conversely, the bits of code running my disk encryption shouldn't be sharing resources with minecraft. So I think the more practical route is dedicated space/chips/resources for security-related stuff, and the big chip for all the less important stuff. Now on a server, with a far greater proportion of security-related tasks, then we may need greater allocation to security. A split between security-specialized with lots of separate protected chips, and general-use CPUs with one bigger chip may be likely.
      - shawnz 8y ago
        > When I play minecraft I don't want it to be relegated to some sub-chip because it isn't trusted. Why not relegate the trusted stuff to a sub-chip then? (i.e. TPMs in desktop PCs, or iOS' "secure enclave")
        sandworm101 8y ago
        Because drawing lines between trusted and non-trusted code isn't easy. Sometimes you need/want to dedicate all available processing power to a bit of trusted code (ie booting into windows). But other time you want to do the same for non-trusted (ie minecraft). Separate chips for each means you've basically halved your peak available horsepower (assuming both are of equal power). Rather than draw the line between trusted and not, I'd draw the line between security-related stuff (encryption keys) and everything else. Then the separate secure chip can be relatively small while the big chip remains available for everything else. (I say "chip" but I think it is more likely to be a separate 'core' on a chip, one with it's own cache and ram. It wouldn't need much of either.)
- newnewpdro 8y ago
  It's one of the use cases for usbarmory [1], which has been around for a while now. [1] http://inversepath.com/usbarmory http://inversepath.com/usbarmory
- bdamm 8y ago
  Well, yes. There is already a large market for these "security dongles", and many libraries and protocols for interacting with them. They're called HSMs and examples of libraries include PKCS#11, JCE, MCE, and protocols like KMIP. Widely used in the financial sectors, CAs (of course), revenue collection such as tolls, government functions such as passport issuance, and some kinds of industrial control segments, among others. It's long been the case that side-channel attacks can extract key materials out of conventional CPUs. Power analysis alone has been now a decades long science and not going away any time soon, made all the more exciting by the prevalence of RF and the advancement of antennas. Spectre and the like is just another wake-up for those not paying attention e.g. in cloud services. Consider yourself one of the enlightened when it comes to crypto material handling.
  - hamilyon2 8y ago
    Well, I worked with one of proprietary security tokens before. Nothing to be proud of, unpatched software/firmware bugs, zero responsibility of manufacturer and usability mess. The thing is, not only cryptography hardware and software itself should be safe, but whole system should be up-to date and have no weak links, which is hard in practice and few want to pay for it. Makes me think if there is any incentive to do crypto properly or security theater will always prevail?
    - tgtweak 8y ago
      I've had the unfortunate experience of integrating a gemalto network HSM and the broken state of the documentation alone is enough to make you question any engineering inside. It's security through obscurity.
  - 0x0 8y ago
    HSM devices, as I understand it, are designed mostly to protect secrets (keys) and perform asymmetric crypto operations safely but perhaps slowly. The Intel AES-NI, on the other hand, is designed for high speed fast symmetric crypto, with nothing kept secret to the user of the AES-NI instructions.
- jonknee 8y ago
  No idea if it's good or not, but that sounds very similar to Nitrokey: https://www.nitrokey.com/ https://www.nitrokey.com/
- ttul 8y ago
  https://www.yubico.com/products/yubikey-hardware/ https://www.yubico.com/products/yubikey-hardware/ These guys are the leaders in small USB crypto keys. Yes their devices offload various crypto routines; and they are cheap.
  - gcb0 8y ago
    they are not cheap as they are not even close to usable out of 2nd factor auth flows. actual hardware acelerators for servers and real world loads are much more expensive though, but you get much more than this. also the interface to yubikeys is a usb hid, much more trivial to exploit than the article's issue.
    - mynameisvlad 8y ago
      Well, firstly, they have HSM-grade hardware available as well. Secondly, they have crypto processors that let you use PGP or PKCS11 certificates with the private key and certificate operations happening on the device, directly integrated into native system utilities. Also, source on them being "much more trivial to exploit than the article's issue"? The only issue I've heard with Yubikey's certificate operations was https://www.yubico.com/keycheck/ https://www.yubico.com/keycheck/ where they also provided anyone affected with a replacement key at no charge.
      - gcb0 8y ago
        > less secure vou posted on a thread about one process stealing memory from another using cpu delays. yubi key expose a device (or type as a usb keyboard), which every single user process have access to.
        mynameisvlad 8y ago
        > yubi key expose a device (or type as a usb keyboard), which every single user process have access to So? Are there any actual exploits you'd like to share that take advantage of either of these? Or are you just speaking in hypotheticals? Because in that case, basically everything you do on any computer that isn't airgapped (and even that can be exploited) is going to theoretically be exploitable.
- amluto 8y ago
  There’s already a TPM in most computers, and the TPM can do this for you. Be careful, though: there are real TPMs (actual chips built by companies that, in theory, know how to build secure-ish hardware) and there are firmware-emulated TPMs. I think that Intel and AMD both offer the latter. Intel calls its offering “platform trust technology”. I take that to mean “please trust our platform even though there is sometimes a web server running on the same chip as the so-called TPM”.
  - SXX 8y ago
    > I think that Intel and AMD both offer the latter. Have no clue on Intel, but for AMD there is basically separate ARM core within CPU so it's has TrustZone built in. Is it just a web server too? I truly curious.
    - ZeikJT 8y ago
      I don't think they meant that the TPM itself runs a webserver. I believe what they mean was that the emulated version runs on the cpu itself, which means that if the system is also running a webserver then any cpu vulnerabilities would compromise the security of the emulated TMP.
      - amluto 8y ago
        No, more like the former. As I understand it, the emulated TPM runs on the Intel ME, which can also run a webserver.
  - jandrese 8y ago
    Using a TPM for generic crypto operations is mostly outside of what they were designed to do. Real hardware TPMs tend to be very slow so they're not really useful for encrypting/decrypting network traffic, they're really supposed to be used to sign messages and verify checksums. They are also supposed to support full on trusted computing, but since it was designed by crypto nerds the trusted computing stuff is almost entirely useless. It completely blocks the CPU while running and is very slow so the practical use cases are very hard to find.
- deleted 8y ago
  [deleted]
- dboreham 8y ago
  Crypto was never supposed to be done on the main CPU. We're all using what is essentially the dev test implementation of pkcs#11 etc.
- hamilyon2 8y ago
  Well, I worked with one of proprietary security tokens before. Nothing to be proud of, unpatched software/firmware bugs, zero responsibility of manufacturer and usability mess. The thing is, not only cryptography hardware and software itself should be safe, but whole system should be up-to date and have no weak links, which is hard in practice and few want to pay for it. Makes me think if there is any incentive to do crypto properly or security theater will always prevail?
  - sofaofthedamned 8y ago
    Had the same with HSM vendors - poorly patched versions of OpenSSL to talk to it (no upstream patches), functionality missing, months between vulns in OpenSSL and their version getting fixed - hopeless industry tbf.
- mrsteveman1 8y ago
  The Pi Zero can do this as a USB client device for a host PC, including the QRCodes with the Pi camera, buttons/switches, and a small touchscreen for host-isolated verification and pin entry. Beaglebone Black (possibly also Pocket Beagle) can do it too, and the am335x does have some minimal crypto acceleration. They're not high performance, they aren't "security focused" hardware, nor are they perfect fit for the task, but they're reasonably well understood and broadly available. The Pi Zero does have a closed "GPU" firmware, but there is an effort[1] to run open firmware on it. However if you expect the host to attack the device, USB OTG (i.e. Linux USB gadget drivers) may not be a good choice, you may want to access it via network instead and that opens up more choices (though most will not be as small). The other alternatives are basically going to be micro-controllers, for example FST-01[2]/Gnuk[3], and FPGAs which are still more of a black box than CPUs at the moment. [1] https://github.com/christinaa/rpi-open-firmware https://github.com/christinaa/rpi-open-firmware [2] http://wiki.seeedstudio.com/FST-01/ http://wiki.seeedstudio.com/FST-01/ [3] https://wiki.debian.org/GNUK https://wiki.debian.org/GNUK
- myself248 8y ago
  Isn't this what smartcards were supposed to do for us?

JStanton617 8y ago

So Intel tried to shut *BSD out of the process again (like they did for the original Spectre/Meltdown) so they didn't feel they had to respect any embargo?

superflyguy 8y ago
Eh? An embargo is where you share information with someone on the grounds they don't release it until a certain date. If you come by the information some other way then clearly you're not a party to the embargo.
- Dylan16807 8y ago
  You can respect an embargo even if you got your information elsewhere.
  - tedunangst 8y ago
    The existence of the embargo is usually a secret as well. Hard to play the game when you're not told the rules.
  - throwaway2048 8y ago
    why would you? The language being used makes it sound like somehow openbsd is breaking agreements. Considering this appears to be the result of the false perception that OpenBSD breaks embargos they are a party too, its important to fight this loose usage of words.
    - tjoff 8y ago
      In the vast majority of cases it is the prudent way to go about it and not doing it (with intent) is often reckless and a dick move well deserved of criticism. This/these cases however might be an exception. I fully agree that one should be careful of propagating such false perceptions about OpenBSD (or any other entity).
      - 8y ago

stryk 8y ago

Can anyone breakdown the impact and severity of this in more digestible terms for those of us not that deeply technical?

arbitrage 8y ago
In the words of Bruce Schneier, "attacks only get better over time". It's basically another aspect of the branch-speculation bugs, not fixed by the original fixes.
- nine_k 8y ago
  AFAICT it's not related to OOO execution, but rather to not cleaning normally accessible state after normal execution. No timers or tricky memory reads needed.
  - Symmetry 8y ago
    Yeah, probably if I'm understanding it right. This one seems less correlated with OoO than Meltdown or Spectre. It looks like you're just issuing a load based on FP register state you shouldn't touch. The system eventually notices it needs to have issued an exception based on the access to the FP register and eventually does quash the load within the core but the the load has already gone out to the memory hierarchy where you can see its effects on cache levels even though it never completes. Larger cores are harder to stop all at once than smaller cores so being OoO should correlate with being vulnerable but basically any pipelined processor that can throw an interrupt on register access could theoretically be vulnerable to something like this.
    - caf 8y ago
      I think you probably do need to execute the should-fault FP access in a not-executed speculatively executed branch (à la Meltdown), so that the exception doesn't actually fire and the kernel doesn't reload your own FP state. (Since you can only learn a small part of the state each time, you need to have the other processes state remain in the FPU while you repeat the process to learn the entire AES key or whatever).

amluto 8y ago

Linux hasn’t used CR0.TS for some time. I removed it a while back because manipulating TS is very very slow. (I am not part of any process with respect to this, embargoed or otherwise.) Edit: the upstream commit is 58122bf1d856a4ea9581d62a07c557d997d46a19, called “x86/fpu: Default eagerfpu=on on all CPUs”, and it landed in early 2016. Greg K-H just submitted backports to all older supported kernels.

jwilk 8y ago
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=58122bf1d856a4ea9581d62a07c557d997d46a19 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
ericseppanen 8y ago
Wasn't 212b02125f3 ("x86, fpu: enable eagerfpu by default for xsaveopt") sufficient protection for everyone on a modern CPU?
- tgtweak 8y ago
  Eagerfpu seems to mitigate it, but some confirmation would be good here.
- hansendc 8y ago
  That commit disables the lazy mode by default on processors supporting the XSAVEOPT instruction. But, it's possible to override that default with the eagerfpu= kernel command-line option, or that a hypervisor has masked out support for that instruction even on hardware with XSAVEOPT support. The point is: although relatively unlikely, it is still _possible_ that you need some mitigation even if you have newer hardware (Sandybridge or newer is where XSAVEOPT first showed up, I believe). Disclaimer: I work on Linux at Intel.
yuhong 8y ago
AFAIK the entire idea dates back to the days of the 80286/80287 (and 80386/80387) when accessing the coprocessor was slow, and a TSS switch (Linux used it until the late 1990s) set that bit for you.

0x006A 8y ago

an empire built on sand...

striking 8y ago
Hah, I get it. Because silicon is made of a particular kind of sand.
PedroBatista 8y ago
Literally and figuratively.
hart_russell 8y ago
built

notaplumber 8y ago

Dragonfly went a little further with this as well.. very precarious future ahead for us, I think.. http://lists.dragonflybsd.org/pipermail/commits/2018-June/672325.html http://lists.dragonflybsd.org/pipermail/commits/2018-June/67...

koolba 8y ago
I find it amazing how clean the diff for something like this is within the BSD source tree: http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/9474cbef7fcb61cd268019694d94db6a75af7dbe http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/9474...
- tomxor 8y ago
  :) Some people go to great lengths to make commit history produce nice clean diffs... although I doubt anyone ever reads mine. Rebase, squash and split, your future self will thank you!
- bonzini 8y ago
  Here's the Linux patch for this: https://patchwork.kernel.org/patch/10202865/ https://patchwork.kernel.org/patch/10202865/ It was done in February for Spectre ("variant 2"). Strange that Dragonfly is only starting now to clear registers.
throwaway2048 8y ago
I wonder if even this will be enough, it seems that modern x86 has hundreds/thousands of non externally visible hidden registers it uses for fast store/load (rather than a call to cache/ram). https://en.wikipedia.org/wiki/Register_renaming https://en.wikipedia.org/wiki/Register_renaming
- caf 8y ago
  Once the architectural registers are zeroed in a path that can't be speculatively skipped, the other values in the register file are dead and can't be exposed.

pstuart 8y ago

Does this impact AMD as well? If not, might this bring further performance parity between the chipmakers?

greglindahl 8y ago
Linux appears to have patched things to avoid this problem on Intel and AMD more than 2 years ago, with the reasoning being that modern CPUs are fast in "eager" mode and "lazy" is not needed. So no, no performance difference for AMD as a result of this issue.
- bonzini 8y ago
  It's not just that modern CPUs are fast in eager mode; also str* and mem* functions nowadays use the FPU (via SSE/AVX) and the dynamic loader (ld.so) uses them. Therefore Linux's heuristics switched to preloading the FPU anyway for most processes, even before the program code started running.

jokoon 8y ago

I am not a security expert, but I am still able to understand the low level of how software works. Yet I have been always mesmerized how hard it is to understand security stuff. Maybe it is because I don't find it interesting, as I am more interested in creative stuff like gaming. Honestly it has been maybe 10 since I've abandoned the idea of caring about security. I just do what is minimal: passwords, avoid sketchy websites, not keeping sensitive files, using trustworthy software, etc. Security is just too hard now. Maybe manufacturers like intel are to blame, and obviously there MUST be some political will to make sure that most electronics are insecure to give an advantage to intelligence agencies. Because ultimately when I first heard about the sony rootkit, and lately about the HD firmware worm, I was really feeling powerless and outdated. I really think that even for a guy like me, who can write software, to not be able to protect myself efficiently against those attacks, and to tell non-programmers that "no I cannot hack people's computers", is starting to make me feel like an idiot. As years go by it seems that electronics seem more and more vulnerable, and I still feel completely unable to defend myself against it. Even politically I'm sure that designing a completely secure computer would be a taboo subject because people would argue that it could help the bad guys, and I'm sure that politically, one could not design such a device with success. The whole "I don't care since I have nothing to hide" is really a fair excuse to show that I'm not capable of defending myself, and I will let others go at their cyber wars without me caring at all. For now the security of individuals seems to be lost, and I fear that one day it won't only be state actors that use security for policing, it will be petty criminals. If cyber chaos ensues nobody will use computers anymore, and they might even become banned from possession.

deleted 8y ago

[deleted]