Re: Early boot, activation, upgrades
On Jul 10, 2007, at 5:54 PM, C. Scott Ananian wrote: Unless we're actually going to do a full cryptographic authentication of the entire FS image at every boot, the kernel checking is just security theater. I missed this message when originally following the thread. This is incorrect. Verifying the integrity of the kernel and the initramfs is necessary and sufficient for guaranteeing that the anti-theft daemon gets started in a container that cannot be killed. Making theft non- trivial is the entire point behind the crypto dance; if that is met, we don't care whether the rest of the FS is modified. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
On Jul 14, 2007, at 9:07 AM, C. Scott Ananian wrote: This seems to imply a much beefier initramfs than is currently the case, and one that is invoked on every boot. It can be done without beefing up the initramfs much, but you have a good point about it requiring one for every boot. Let me think a bit about how best to do this without one. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
More benchmarks for bios_crypto on LX: Whirlpool: 1.16 sec / MiB SHA512: 0.42 sec / MiB SHA256: 0.28 sec / MiB --- New result (SHA256 is 1.5x the speed of SHA512) RSA verification: 0.025 sec / hash ECC521 verification: 1.13 sec / hash ECC256 verification: 0.31 sec / hash --- New result (ECC256 is 3.5x the speed of ECC521) It wasn't obvious how to coerce the code to do 256-bit truncated Whirlpool, so I don't have a number for that. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
On 7/10/07, Mitch Bradley [EMAIL PROTECTED] wrote: Decompression is fast, but the signature verification is not so fast, especially since there are several different algorithms. Can't we just SHA1 the kernel+initrd bundle and sign the hash? SHA1 should be fast enough... --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
On Jul 10, 2007, at 8:46 AM, C. Scott Ananian wrote: Can't we just SHA1 the kernel+initrd bundle and sign the hash? SHA1 should be fast enough... The hashes we have available in OFW through the LTC code are Whirlpool and SHA-512. It's non-trivial to amend the list at this time. The current crypto code uses a slow(ish) and paranoid combination of the two hashes with two signature systems because it was designed to verify BIOS updates, where maximal paranoia is justified. We will want to adjust the system to drop down to a single hash algorithm and signature system for the normal boot integrity verification, which should make it quite a bit faster. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
On 7/9/07, Mitch Bradley [EMAIL PROTECTED] wrote: I looked at those git trees and didn't see the python runtime stuff in the initramfs tree. How does it get included, and how big is it? Packages in initramfs are specified by: http://dev.laptop.org/git?p=users/cscott/d-i;a=blob;f=build/pkg-lists/olpc/common;hb=HEAD python2.5-minimal is about 2MB of the 3MB compressed initramfs. The python2.5 binary is 1.4M (compressed) of that; it's likely that I could trim this down a bit more -- I notice that the python2.5 binary is unstripped, and stripping yields 470k compressed -- but I'm reluctant to minimize stuff until Ivan's written his activation code and we know roughly what packages we'll be wanting. For instance, there are a lot of different encodings represented in /usr/lib/python2.5/encodings which I've left because I don't know at this point if activation will require a localized UI. For comparison, the existing traditional 'mayflower' initrd created used for emulation is 2.3MB. So at the instant we're paying about 700k for the privilege of writing our activation code in python, but this number is pretty bogus. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
C. Scott Ananian wrote: On 7/9/07, Mitch Bradley [EMAIL PROTECTED] wrote: I looked at those git trees and didn't see the python runtime stuff in the initramfs tree. How does it get included, and how big is it? Packages in initramfs are specified by: http://dev.laptop.org/git?p=users/cscott/d-i;a=blob;f=build/pkg-lists/olpc/common;hb=HEAD python2.5-minimal is about 2MB of the 3MB compressed initramfs. The python2.5 binary is 1.4M (compressed) of that; it's likely that I could trim this down a bit more -- I notice that the python2.5 binary is unstripped, and stripping yields 470k compressed -- but I'm reluctant to minimize stuff until Ivan's written his activation code and we know roughly what packages we'll be wanting. For instance, there are a lot of different encodings represented in /usr/lib/python2.5/encodings which I've left because I don't know at this point if activation will require a localized UI. For comparison, the existing traditional 'mayflower' initrd created used for emulation is 2.3MB. So at the instant we're paying about 700k for the privilege of writing our activation code in python, but this number is pretty bogus. At that 3M size, I'm beginning to have second thoughts about the one initrd for both activation and normal booting idea. A busybox (statically linked with uclibc) with enough trimmings to do darn near anything compresses to about 0.6 MB. The fact that the kernel can currently boot with no initrd at all makes it hard for me to swallow the proposition of tripling the load image size in the usual case. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Early boot, activation, upgrades
C. Scott Ananian wrote: On 7/9/07, Mitch Bradley [EMAIL PROTECTED] wrote: At that 3M size, I'm beginning to have second thoughts about the one initrd for both activation and normal booting idea. A busybox (statically linked with uclibc) with enough trimmings to do darn near anything compresses to about 0.6 MB. The fact that the kernel can currently boot with no initrd at all makes it hard for me to swallow the proposition of tripling the load image size in the usual case. I'll look into how small I can make it tomorrow. If we've got to have the initrd for activation, we might as well do normal boot with it, since the time spent decompressing is still minimal for the sizes we're talking about. I can try to quantify that claim once I get my B4. ;-) --scott Decompression is fast, but the signature verification is not so fast, especially since there are several different algorithms. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
