As I recall, the limit was going to be 1 page per process.
In any case, if I want to block DMA buffers, I'll just fork(2) and
mlock(2) until I can't do it any more. Not having virt->phys
translations isn't going to stop me.
All virt->phys translations do is allow me to stop the attack early
when I have achieved some narrow, specific goal. Kind of like a nice
for a DOS programme :-)
> In general, it is bad to leak information.
There is information leaking going on all over the place. There's
little we can do about that. Furthermore, we need to distinguish
between levels of sensitivity of information. I think there's very
little you can do with virt->phys translations.
Also, IMHO the correct way to deal with information leakage is to make
it irrelevant, not to try to plug all the leaks (a losing game). Take
for example the Pentium cycle counter, which can be used to time how
long someone else's PGP encryption is taking. You can't just block
access to timing information (are you going to block gettimeofday(2)
as well?). The correct way to deal with this kind of attack is to make
knowledge of the time spent during encryption valueless. For example,
ensure the algorithm takes the same amount of time irrespective of key
length/contents. Alternatively, add some random delay time after
encrypting. A secure cryptosystem depends on more than having strong
ciphers and massive keys: you have to think about the protocols
involved. The way these things are implemented on a shared system is
in effect part of that protocol. It is *not* the OS that is leaking
information, it is the encryption programme. It may be entirely valid
for one programme to time another.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html