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)? David Lang _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel