Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:17:20 ADT
W. J. La Cholter (tck@giage.com)
Tue, 12 May 1998 08:24:11 -0400
> From: Eric Young [SMTP:eay@cryptsoft.com]
>
> I belive this is the case for just about all operating systems that
> have a
> 'keep in memory' system call. It is nothing to do with 'password'
> security,
> rather a very strong hint that we don't want the memory swapped out.
> Real
> Time OSs may actually implement a no swap/page policy but this is very
> dangerous on a multi-user system. Just because the system call
> claims to
> implement something that looks like a 'no-swap' policy, does not mean
> it is
> true.
>
There is a place where you can be sure that the no-swap policy holds: at
the kernel level. If you implement a device driver or some other kernel
level component and use the kernel call to allocate non-paged memory (in
Windows NT it's ExAllocatePool(NonPagedPool,i_byteCount)), you can be
sure that the OS implements the call correctly. If it didn't, then
device drivers running at an IRQ level above the memory manager would
generate unrecoverable page faults.
The downside to implementing crypto in the kernel is that you must have
administrative privileges in order to install the device driver. If
you're using a crypto FS, no big deal--you already need to have admin to
install it. I'd love to see a crypto program that took advantage of the
kernel for memory locking, though SecurPC is platform specific, anyway,
so adding a little bit of code to wire the pages at the kernel level
isn't that hard.
-
W. J. La Cholter - Giage
PGP 5 Fingerprint: 79E0 EE3A 2EC1 2303 624C AE99 F31B 972B F24F 688E
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:17:20 ADT