24

In the interest of data security...

when a cpu fails in a server and you remove it is there any way that removed cpu can retain any kind of data that poses a concern?

For example an Intel Xeon 1st gen scalable 8000 series processor released around 2018. Or any of the subsequent models between then and now. Or if you know any older specific model of cpu, by any manufacturer.

Improve this question
0

4 Answers 4

Reset to default
29

This is something you can actually find on the internet if you search the keywords “statements of volatility”.

The situation is nuanced, that's why security-critical users require their suppliers to define very precisely which info remains where, and how it is deleted, and what they guarantee in that respect. (I think that's basically a US invention, so either DOD or NSA. It's common that defense contractors request these from their hardware vendors.)

So, there's no general answer to your question; go and read these specifications ("statements of volatility") by Intel yourself:

https://www.intel.com/content/www/us/en/support/articles/000031551/processors/intel-xeon-processors.html

For XEONs, no data being retained might be true, but it needn't be the case for all CPUs, not even by Intel; the more a SoC targets a deeply embedded market, the more likely it is that in the CPU package there's also firmware storage.

Improve this answer
5
  • 6
    @ron that is exactly the link from my answer? Could you elaborate on why you're posting it in a comment to the same? DId you really miss the thing where the money quote from that page is: All Intel® Xeon® processors do not retain any end-user data when powered down and / or the processor is physically removed from the socket.? Please read the material pointed out to you carefully!
    – Marcus Müller
    Commented Aug 14 at 13:59
  • 1
    They may have said that, but they weren't being very imaginative and it's surely false. Just consider the ongoing scandal about failing 13th and 14th generation processors, and Intel's claims that a microcode update can avoid the damage. You've got non-volatile information (presence of permanent damage) and ability to dynamically influence it (microcode updates don't survive reboot, so if you compromise the OS so it won't load the fix on the next boot, the resulting damage serves as a side channel)
    – Ben Voigt
    Commented Aug 15 at 22:28
  • 8
    this is the most infosec castle-in-the-sky 1 bit side channel ever :D
    – Marcus Müller
    Commented Aug 15 at 22:52
  • (Of course pretty much all CPUs have voltage control through system firmware with equal potential for intentional damage... but that's less fun) 1-bit side channels are enough for some purposes. deniable warrant canary, for example
    – Ben Voigt
    Commented Aug 16 at 15:59
  • 1
    yes, but this one is just ooof
    – Marcus Müller
    Commented Aug 16 at 17:02
20

This is a good question that in the 1990s and 2000s would deserve the downvote. Technology, however, marches on. Trusted Platform Modules mean that somewhere on the chipset, usually the motherboard, permanent cryptographic keys are installed as well as the possibility of some erasable ones generated by the user that could be wiped. I think in the present day that none of the key materials are included in the CPU itself. This may not hold true in the future.

On its own this doesn't matter much, but if there is external trust of the values in the chip then it can matter. Example cases would be disk encryption managed via TPM where the drive and computer are sold together, or the TPM containing a certificate that retains some kind of authentication trust.

Improve this answer
14
  • 3
    Do CPUs exist with embedded TPM? I thought the point of a TPM is that it gives a single point of control over secrets.
    – Toby Speight
    Commented Aug 14 at 10:57
  • 7
    @TobySpeight Modern Intel and AMD CPUs provide an optional firmware TPM implementation via the integrated security processor (which often also handles things like SGX/SME and cryptographic acceleration). Depending on the exact model, the storage for that may be on the CPU itself and not on the baseboard.
    – Austin Hemmelgarn
    Commented Aug 14 at 11:13
  • 4
    @AustinHemmelgarn And then there's the management engine, basically a whole separate SoC inside of the CPU package. That one certainly does have persistent storage.
    – TooTea
    Commented Aug 14 at 13:04
  • 2
    @MarcusMüller Looks like you're right. I was assuming that the configuration of the ME is stored inside of it, but googling a bit doesn't support that. It might be that the configuration is stored in a dedicated partition of the system firmware flash, thus on the motherboard.
    – TooTea
    Commented Aug 14 at 14:01
  • 3
    @fraxinus, ...mm. I work with someone whose professional skillset includes decapping chips for analysis and/or attack. It's a subfield that very much exists.
    – Charles Duffy
    Commented Aug 16 at 15:23
3

The matter of long-term persistent state is well covered by other answers.

Additionally, CPU caches hold megabytes of data cached from main memory. These caches are nominally volatile, but if the CPU is suddenly removed from a running system and cooled to cryogenic temperatures, the cached data is likely to remain recoverable for hours to days, via a variant of the cold boot attack. Readout may require very sophisticated lab equipment.

Improve this answer
7
  • 1
    readout would also be hampered by the fact that you need to know which data to request from the cache, without the snoop unit going "nope, that's in main RAM" or "oops, I just ejected that cache page". I'm not quite sure whether there's privileged instructions on x86 that can directly address cache, but that might be the case, in which case things might become more feasible (theoretically, if you first cool and then remove, not the other way around ;) )
    – Marcus Müller
    Commented Aug 14 at 14:48
  • 1
    In the extreme case you can decap the chip and use die-level probing to access the cache directly, bypassing the MMU. L3 cache is sometimes on separate chiplets which would make this slightly easier, but it’s still a very advanced attack, basically state-level stuff.
    – pericynthion
    Commented Aug 14 at 14:54
  • 5
    I'm not aware of any decapping mechanism that wouldn't be incompatible with keeping the chip cryogenically cooled – all chemical reactions necessary to chemically delayer protective lacquer or unrelated metal layers would come to a stop effectively, and by its very principle, abrasive delayering would heat up the chip.
    – Marcus Müller
    Commented Aug 14 at 14:56
  • 4
    @MarcusMüller There seem to be instructions like CFLUSH that invalidate cache lines and write any changes to memory. So you could issue that command for all addresses and see what memory writes result. This of course requires the sensitive data to be written to the cache by the cpu and not originate from memory. But then again, if your physical access is close enough to do a cold boot attack, you could probably just grab the ram as well while you are at it.
    – mlk
    Commented Aug 15 at 11:10
  • 2
    @Vilx-, no, room-temperature retention time of SRAM is typically several milliseconds; some models can go as high as tens of seconds. Cool it down below freezing, and you can get retention times of hours. See cl.cam.ac.uk/techreports/UCAM-CL-TR-536.pdf
    – Mark
    Commented Aug 15 at 21:31
1

In some cases, a CPU, once removed, can reveal what type of system they were used in, because of certain business practices (effectively bricking CPUs so they can't be used in the competitor's server).

I know of a single real-life example currently in the market; the AMD PSB vendor-lock-in function on its Epyc (Rome and later) and Threadripper Pro (gen 3 and up) CPUs.

These are fuses that are burnt, so the change in state is one-way only.

Now suppose that the computer vendor that sold that chip is, backed by its state, a security adversary. The computer vendor could use a special pattern, unique to the motherboard, to identify it exactly.

Or, more nefariously, once the target's machines are compromised, a hacker could use this mechanism on each one of them to assign the computer's CPU fuse code to one matching an unknown private key on boot, effectively permanently turning it into a brick (as it will refuse to decrypt the firmware). That could cause significant damage and downtime, greater than a security failure where the machines would simply be flashed back to a known good state.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .