protection against hardware attacks (RAM removal)

[Jerome Baum]

>> 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.

-- 
Jerome Baum

Hessenweg 222
48432 Rheine
GERMANY

tel +49-1578-8434336
email jerome at jeromebaum.com
web www.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
--
http://five.sentenc.es