|
|
|
|
|
|
by marcan_42
1921 days ago
|
|
|
I'd forgotten tech reporting was just as bad in 1999 as it is today. Here's the important part missing from the article: that serial number is available from userspace, and cannot be intercepted by the kernel in any way. They provided a way to disable it, but not to report, control, or intercept how it is accessed. It is returned by the unprivileged, untrappable* CPUID instruction. Every single UEFI computer sold today has a unique serial number (GUID). There are MAC addresses. There are HDD serial numbers. There are zillions of unique identifiers accessible to the operating system. Various copy protection schemes use one or more of these. But what they all have in common is that they are under the control of the OS. A privacy-conscious OS can forbid access to these identifiers for userspace applications, or can fake them to something else. This is how e.g. sandbox environments like the App Store can force apps to use some kind of "advertising ID" for this stuff, and ensure that apps aren't sneakily fetching some true unique system ID. But with the PIII serial number, userspace apps can fetch it without the OS knowing about it. And the disable bit is a one-time operation, so it is not possible to grant serial number access to some apps and not others. This leads to a situation where any arbitrary unprivileged userspace app can uniquely identify your machine, and where vendors relying on this feature might compel you to leave it enabled (e.g. DRM). Now random apps running under an untrusted user can fingerprint your machine, just because you want to watch Netflix. And that is why this design was utterly broken and a privacy nightmare. Not because it's a unique ID. We have tons of those. * VMs can trap CPUID, but of course VM support came later anyway. |
|
|
On Intel trapping CPUID is also possible without VMs since Ivy Bridge. (Linux exposes it by arch_prctl(ARCH_SET_CPUID))