3 ms·

I don't understand why this matters.. if journalists are trusting random screenshot (or database entry) it could obviously be faked! Forget advanced MSR manipul

by theamk 4y ago

I don't understand why this matters.. if journalists are trusting random screenshot (or database entry) it could obviously be faked! Forget advanced MSR manipulation, one can just photoshop the screenshot, or open in debugger and edit window elements, or binary-patch the executable. Same goes with database entry - I bet the result submission is some HTTPs call which can be mitmproxy-ed and edited. So the real title should have been: "You thought there are 5 ways to fake test results? Nope, there are 6." Not nearly as exciting.

rbanffy 4y ago
CPUID is not designed to be secure, but, if every CPU model had a (directly inaccessible) unique key, it could be used to sign a challenge and prove that CPU is what it's telling the program it is.
- ilyt 4y ago
  Yeah we don't want that. Faking the feature list is quite useful for VMs, if say you have Zen 2 and Zen 3 CPUs in your cluster but still want VMs to be live-migrable between the two
- josefx 4y ago
  Which leads back to the issue that the current top comment mentions. Intel has been caught using vendor Id checks to undermine performance on competing CPUs. Hence keeping the identity mutable may be necessary to protect against very real and very well known bad actors.
- theamk 4y ago
  I suppose, but what would be the use case of this? It definitely won't in the "reliable benchmark" case, as the check could be just patched out.
  - deleted 4y ago
    [deleted]
  - rbanffy 4y ago
    > as the check could be just patched out You could still sign the result with the CPU ID key. But, then, the result can be completely bogus. The benchmark itself would need to be something that can't be faked, but a proof-of-work benchmark would end up being a very synthetic one, and very biased towards a limited set of functions.
- mindslight 4y ago
  The same functionality could and would be abused to make sure you were running a specific version of Internet Explorer on a certain version of Microsoft Windows (or equivalent locked down system) to get access to a website. Freedom relies on the the authority boundaries created by open protocols, and such "remote attestation" schemes would be the death of it.

by theamk 4y ago

rbanffy 4y ago

CPUID is not designed to be secure, but, if every CPU model had a (directly inaccessible) unique key, it could be used to sign a challenge and prove that CPU is what it's telling the program it is.

ilyt 4y ago
Yeah we don't want that. Faking the feature list is quite useful for VMs, if say you have Zen 2 and Zen 3 CPUs in your cluster but still want VMs to be live-migrable between the two
josefx 4y ago
Which leads back to the issue that the current top comment mentions. Intel has been caught using vendor Id checks to undermine performance on competing CPUs. Hence keeping the identity mutable may be necessary to protect against very real and very well known bad actors.
theamk 4y ago
I suppose, but what would be the use case of this? It definitely won't in the "reliable benchmark" case, as the check could be just patched out.
- deleted 4y ago
  [deleted]
- rbanffy 4y ago
  > as the check could be just patched out You could still sign the result with the CPU ID key. But, then, the result can be completely bogus. The benchmark itself would need to be something that can't be faked, but a proof-of-work benchmark would end up being a very synthetic one, and very biased towards a limited set of functions.
mindslight 4y ago
The same functionality could and would be abused to make sure you were running a specific version of Internet Explorer on a certain version of Microsoft Windows (or equivalent locked down system) to get access to a website. Freedom relies on the the authority boundaries created by open protocols, and such "remote attestation" schemes would be the death of it.