Effectively restricting OSes has to be done by the system integrator, e.g., by using Secure Boot to verify a boot stage's SW signature against a read-only set of known hashes. An OS on its own cannot change this - it doesn't get loaded until AFTER secure boot verifies it. If it could retroactively change Secure Boot's set of known hashes, then Secure Boot would be worthless. TPM is not Secure Boot.
The article states, "Starting with Windows 10, the operating system automatically initializes and takes ownership of the TPM." Here, initialization happens at OS boot time, and ownership means that the OS manages access to the hardware component (as is the typical responsibility of an OS). More generally, memory/registers that are not read-only (i.e., written only once by the HW designer or system integrator, e.g., a stage-0 bootloader) and is accessible by the CPU is configurable by whatever OS is running (having been initialized by the earlier bootloader). This is a simplification, but sufficient for now
.
Furthermore, "TPMs are passive: they receive commands and return responses." It's basically an area to do secure computation. It should probably not be storing data between boots (that screams security violation to me, which is entirely antithetical do TPM's purpose).
Bookmarks