protection against hardware attacks (RAM removal)
jerome at jeromebaum.com
Thu Sep 1 17:39:13 CEST 2011
>> Though you need to carefully balance the size -- too small and it's
>> not a significant help (i.e. data loss isn't fast enough), too big and
>> it doesn't fit into the cache.
> There is no need for the expanded data to fit into the cache. Would not even
> make sense to cache it on normal systems as you hardly ever have crypto
> operations so quickly one after another that the cache data has NOT been
> trashed in the meantime.
I was thinking along these lines:
>>> Does Linux allow locking of pages in a L1 cache (in order to prevent
the data from being written to RAM)?
>> About the context switches, won't going into system mode be enough?
> I have to admit that I don't know what "system mode" is. It would be nice to
> be able to implement something like that without the need for OS support.
I only roughly recall this stuff but basically your average CPU can
distinguish "system" vs. "user" mode. System mode is where your OS
works, user mode is where the user works. :)
The point being that system mode gives you a lot more privileges and I
think that while in system mode, you don't get interrupted (in fact,
system mode is where e.g. the scheduler would be running). I don't
think there is any way to prevent a context-switch w/out OS support
(read: root-level access). It's a security feature of the underlying
OS that you can't "steal" the CPU.
email jerome at jeromebaum.com
Einigkeit und Recht und Modeerscheinung
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
More information about the Gnupg-devel