4 ms·

The main thing is "Why undocumented?", not threat model and physical or remote exploit.

by MrXOR 8y ago

CodeWriter23 8y ago
> The main thing is "Why undocumented?", not threat model and physical or remote exploit. No, the main thing is if VISA is for qualifying chips on the production line, why don’t they burn a fuse permanently disabling it on chips that pass QA?
- MrXOR 8y ago
  Yet another main question, because ...
- smalley 8y ago
  VISA isn't for qualifying chips as much as it is for debugging chips including customer returns. Long ago access to limited versions of the signals was given to some customers under NDA and customers had the ability to set customer fuses which would prevent Intel from unlocking the debug features. There's also an unsupressable "debug enabled" bit hardwire to a lot of these functions if I remember so the parent system can always see if somebody turned on the debug functions. Turning on debug functions also usually had the effect of disabling/corrupting important key material. This said, its basically a giant signal mux system run into a main block, you'd be pretty limited on what preselected signals are available at a time. People were also reasonably careful not to give entire busses of signals at once.
userbinator 8y ago
Testing/debugging features are intended for internal use only and can expose proprietary information about their implementation, so only Intel and possibly some motherboard manufacturers are allowed the knowledge. Speaking of documentation, while not fully open, Intel/AMD are already ahead of many others when it comes to documenting things. Look at the SoCs used in smartphones and tablets, or the infamous Raspberry Pi. AFAIK, Intel is not in the business of making secure cryptoprocessors like the ones used in payment cards and SIMs, but once again even with those you are very unlikely to find public documentation --- everything is NDA'd. That said, don't get me wrong, I'm not advocating for leaving things undocumented; just explaining how it usually turns out that way.
- 0815test 8y ago
  > Intel is not in the business of making secure cryptoprocessors like the ones used in payment cards and SIMs They have entered a rather comparable space with stuff like TPM and SGX (and are largely using it for nefarious, consumer-hostile stuff like DRM and remote code attestation, of course).
  - hedora 8y ago
    You can also use SGX for privacy-preserving enclaves, which makes the combined existence and secrecy of this debugging stack more concerning. Unless there are countermeasures that we don’t know about, this is a huge backdoor for such systems. With DRM, the attackers afe consumers. With enclaves, the attackers are Intel and government intelligence agencies.
    - 0815test 8y ago
      SGX always involved trusting Intel. It was Intel basically telling a third party "yup, this machine is running the binary code you expect it to be running". Which is exactly why it's nefarious, of course - a third-party has no business forcing me to run their proprietary binaries on my own machine in order to access their service. If they want that kind of trust, they're still free to establish that by sending me a physical dedicated-use device that can authenticate itself to whatever service they care about.
      - dTal 8y ago
        Hm, while I completely agree about not wanting proprietary garbage on my machine, I'm not sure about this logic. A third party can stipulate anything it likes, in order to use their service - you're always free not to use that service. Arguably, the ability to certify that you, the user, are indeed running the code you say you are is a feature provided to you, rather than a restriction imposed upon you. Not a feature I have interest in using, but nevertheless it's possible to frame it that way around. The fact that such code tends to be proprietary is (again, very arguably) besides the point.
dooglius 8y ago
Based on the name, the tool likely makes it easy for others to figure out low-level details of processor implementations that Intel would prefer be trade secrets.
0815test 8y ago
Why undocumented? Because Intel is not RISC-V or even Arm. Do you expect other chip makers to document every internal detail of their chips? And yes, as chips grow in internal complexity, bugs like this one become inevitable - so perhaps we should be insisting on fully-documented designs.
- smolder 8y ago
  There was nothing inevitable about this particular one, unless you mean it at the level of "people will always make mistakes and there's nothing you can do about it"

The main thing is "Why undocumented?", not threat model and physical or remote exploit.

by MrXOR 8y ago

The main thing is "Why undocumented?", not threat model and physical or remote exploit.

> The main thing is "Why undocumented?", not threat model and physical or remote exploit. No, the main thing is if VISA is for qualifying chips on the production line, why don’t they burn a fuse permanently disabling it on chips that pass QA?

MrXOR 8y ago
Yet another main question, because ...
smalley 8y ago
VISA isn't for qualifying chips as much as it is for debugging chips including customer returns. Long ago access to limited versions of the signals was given to some customers under NDA and customers had the ability to set customer fuses which would prevent Intel from unlocking the debug features. There's also an unsupressable "debug enabled" bit hardwire to a lot of these functions if I remember so the parent system can always see if somebody turned on the debug functions. Turning on debug functions also usually had the effect of disabling/corrupting important key material. This said, its basically a giant signal mux system run into a main block, you'd be pretty limited on what preselected signals are available at a time. People were also reasonably careful not to give entire busses of signals at once.

userbinator 8y ago

Testing/debugging features are intended for internal use only and can expose proprietary information about their implementation, so only Intel and possibly some motherboard manufacturers are allowed the knowledge. Speaking of documentation, while not fully open, Intel/AMD are already ahead of many others when it comes to documenting things. Look at the SoCs used in smartphones and tablets, or the infamous Raspberry Pi. AFAIK, Intel is not in the business of making secure cryptoprocessors like the ones used in payment cards and SIMs, but once again even with those you are very unlikely to find public documentation --- everything is NDA'd. That said, don't get me wrong, I'm not advocating for leaving things undocumented; just explaining how it usually turns out that way.

0815test 8y ago
> Intel is not in the business of making secure cryptoprocessors like the ones used in payment cards and SIMs They have entered a rather comparable space with stuff like TPM and SGX (and are largely using it for nefarious, consumer-hostile stuff like DRM and remote code attestation, of course).
- hedora 8y ago
  You can also use SGX for privacy-preserving enclaves, which makes the combined existence and secrecy of this debugging stack more concerning. Unless there are countermeasures that we don’t know about, this is a huge backdoor for such systems. With DRM, the attackers afe consumers. With enclaves, the attackers are Intel and government intelligence agencies.
  - 0815test 8y ago
    SGX always involved trusting Intel. It was Intel basically telling a third party "yup, this machine is running the binary code you expect it to be running". Which is exactly why it's nefarious, of course - a third-party has no business forcing me to run their proprietary binaries on my own machine in order to access their service. If they want that kind of trust, they're still free to establish that by sending me a physical dedicated-use device that can authenticate itself to whatever service they care about.
    - dTal 8y ago
      Hm, while I completely agree about not wanting proprietary garbage on my machine, I'm not sure about this logic. A third party can stipulate anything it likes, in order to use their service - you're always free not to use that service. Arguably, the ability to certify that you, the user, are indeed running the code you say you are is a feature provided to you, rather than a restriction imposed upon you. Not a feature I have interest in using, but nevertheless it's possible to frame it that way around. The fact that such code tends to be proprietary is (again, very arguably) besides the point.

dooglius 8y ago

Based on the name, the tool likely makes it easy for others to figure out low-level details of processor implementations that Intel would prefer be trade secrets.

0815test 8y ago

Why undocumented? Because Intel is not RISC-V or even Arm. Do you expect other chip makers to document every internal detail of their chips? And yes, as chips grow in internal complexity, bugs like this one become inevitable - so perhaps we should be insisting on fully-documented designs.

smolder 8y ago
There was nothing inevitable about this particular one, unless you mean it at the level of "people will always make mistakes and there's nothing you can do about it"