* Richard Zidlicky <rz@xxxxxxxxxxxxxx> wrote: > > As a reaction to this "attack" I wonder if it might be possible > > to use level 2 cache of the processor to store keys in highly > > volatile memory space. 2 or more megabytes on the CPU die might > > be a last resort. As gpg prevents leaking keys from kernel ram to > > swap partitions, newer disk encryption might prevent keys to be > > stored in DRAM cells. Of course, elderly processors might not do > > this stunt due to lack of level 1/2/3 cache but newer > > architectures offer ever increasing megabytes. Is that a > > worthwhile option? > > there is aonether option that is well doable with todays > technology. On a multi-CPU machine run a dedicated > noninterruptible kernel thread on one of the cores which keeps > essential parts of the key in CPU registers at all times. How do you prevent the OS from using this CPU? If it's a dualcore system, ok, but what about quadcore+ systems? I agree it's possible (and takes the idea of using "cache" for key storage to an extreme level). Has it been achieved to access CPU#1 regs from a thread running on CPU#2, f.e., a) without significant speed penalties and b) at all? My quite limited knowledge of current thread handling says that such access is not meant to happen at all. So far, theoretically it would be the best thing to do without having to change any hardware architecture, IMHO. > Using some of the coprocessors would be another interesting idea > but much less portable. > > I am curious what kind of attacks people find against this:) Apart from all the speculation I'd like to see some code snippets ... I fear it's all talk and all agreed upon and then nothing happens. Given the number of people actually caring about the issue it's a start to have even pseudo-code published. -- left blank, right bald
Attachment:
pgpyoamqlwu3c.pgp
Description: PGP signature
