Leaving “gifts” behind on dedicated server hosts
rachelbythebay.com
rachelbythebay.com
Physical separation of the resource pools into equivalence classes or trust zones is just about the only sane way to recycle equipment. You might shelve and reuse equipment for the same customer or set of customers bound by mutually-covering legal agreements and mutual existential risks. You really have to think twice before putting non-trusting tenants together and consider the worst case. A proper service offering for sensitive workloads should involve decommissioning plans.
Promoting or demoting hardware between classes is difficult. You have to be very confident in scrubbing writable storage to demote hardware to a less trusted class, so you don't leak privileged information. But you have to be even more confident to go the other way, so you don't allow injection of malware as postulated in the blog post.
There was a time when the provider might be able to strip a machine to its bare bones, re-flashing firmware and replacing peripherals which couldn't be sanely verified, to reinitialize it as a new trusted machine. But, there are so many bits of writable firmware storage and different embedded controllers in modern machines, so it becomes futile to imagine scrubbing it all.
I haven't given it much thought as I've not worked with physical kit since then. I wonder if virtualization is good enough now that they could take a security stance to only deploy VMs, and deprecate the root "physical servers" product offering (i.e. you can spec out a physical server but you will always get a VM).
Short answer - yes using VMs should be good enough.
If you had direct (root) access to the hardware, you can replace firmwares/BIOS, which is what we are discussing.
However, as I'm suggesting, if that machine was only ever provisioned with a VM, the bad actor is not given access to the hardware directly (hypervisor bugs aside)
I wonder if the company I work for could use such a "smart cookie"...