debxo 0.3 release
david at lang.hm
david at lang.hm
Sun Nov 2 23:51:20 EST 2008
On Sun, 2 Nov 2008, John Gilmore wrote:
>> things that I can see as possibly needed:
>> hardware encryption engine (does this show up to the kernel as an
>> available encryption device? (it would be handy if at least the
>> development builds of the kernel enabled /proc/config.gz for all xo
>> distros (including the OLPC builds) it costs about 10k
>> compressed, 40k raw)
> The Geode hardware encryption engine is useless for Unix user
> programs. It was apparently designed for/by hardware engineers who
> had no idea how an operating system or a crypto library works. It can
> only be accessed via DMA using physical addresses, which means a user
> program that wanted to do AES would have to do a kernel call and the
> kernel would have to copy the data to reside in contiguous physical
> memory, then copy the results back and return to user space. It's
> much faster to simply do AES in software for virtually every
> application (and that software's already coded and tested). If the
> Geode designers had only made the engine accessible via unprivileged
> instructions that took operands from registers or virtual memory, we'd
> have seen a very different result.
what about the kernel encryption modules? those aren't suitable for a lot
of userspace code, but for other things (like network encryption where
they kernel is already processing the data) can the CPU support
replace/supplement the software versions?
>> is there anything else that may need special handling?
> Suspend/resume, e.g. when you close the lid.
the lid buttons handle detection of closing the lid
for suspend/resume what special cases are needed? or are you just saying
that we need to check the suspend/resume support for all the hardware and
make sure it's in the upstream kernel (and test it regularly so that they
don't make a change that breaks it)?
More information about the Devel