Publishing what started as an review request - Forwarded conversation Subject: New branch on bios-crypto: delegation ------------------------
From: *Martin Langhoff* <[email protected]> Date: Thu, May 7, 2009 at 6:43 PM To: "Reuben K. Caron" <[email protected]>, Daniel Drake <[email protected]>, "C. Scott Ananian" <[email protected]> Hi guys, Early heads up -- I am working on the tools included in bios-crypto to prepare them to produce 'sig02' delegated signatures and specially delegated leases. The work I am doing is following the spec on the wiki and the examples in the bitfrost code. You might want to give brief review at http://dev.laptop.org/git/bios-crypto/commit/?h=delegation - Scott, Daniel - I've patched sig01.c lightly so that it changes its format slightly for sig02. C is not my native language; I don't think I did anything particularly stupid, but a review would be welcome. - Scott: if you look at make-delegation.sh and the patches to sig01.c -- does it make sense? - Reuben: have a look at the README The remaining bit is to rework make-lease.sh to accept and use delegation signature, like --chained works on make delegation. And testing this end-to-end. cheers, m -- [email protected] [email protected] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ---------- From: *Daniel Drake* <[email protected]> Date: Thu, May 7, 2009 at 6:55 PM To: Martin Langhoff <[email protected]> Cc: "Reuben K. Caron" <[email protected]>, "C. Scott Ananian" < [email protected]> 2009/5/7 Martin Langhoff <[email protected]>: Don't forget that OFW needs to be taught about the new format, and needs to be extended to correctly verify sig02 leases. Or is that already being taken care of? ---------- From: *Martin Langhoff* <[email protected]> Date: Thu, May 7, 2009 at 7:03 PM To: Daniel Drake <[email protected]> Cc: "Reuben K. Caron" <[email protected]>, "C. Scott Ananian" < [email protected]> It's not so important in the short term. OFW checks the leases, and then it executes runos or actos depending on the outcome... but both are the same thing ATM. Once Mitch gets out of his 1.5 work, he'll have a chance to test his patches for delegation support. As long as runos and actos remain the same for that period... :-) ---------- From: *Daniel Drake* <[email protected]> Date: Thu, May 7, 2009 at 8:50 PM To: Martin Langhoff <[email protected]> Cc: "Reuben K. Caron" <[email protected]>, "C. Scott Ananian" < [email protected]> No, it is important. If OFW doesnt trust the lease, it will boot with the "activate" parameter passed to the kernel, which the OLPC initramfs will unconditionally interpret as the machine being unactivated. The consequence being that no systems with act02 leases will boot. Daniel ---------- From: *Martin Langhoff* <[email protected]> Date: Thu, May 7, 2009 at 9:36 PM To: Daniel Drake <[email protected]> Cc: "Reuben K. Caron" <[email protected]>, "C. Scott Ananian" < [email protected]> Good pointer. As things stand, I have to hack inside of the initrd anyway -- I can make sure that the initrd behaves properly in that case. It sounds like an easy enough fix -- do you think that there are more reasons to worry? ---------- From: *Daniel Drake* <[email protected]> Date: Thu, May 7, 2009 at 9:37 PM To: Martin Langhoff <[email protected]> Cc: "Reuben K. Caron" <[email protected]>, "C. Scott Ananian" < [email protected]> Changing the behaviour in this area sounds scary. For testing and development, maybe OK, but I don't feel that this plan becomes realistic without firmware support. Daniel ---------- From: *Reuben K. Caron* <[email protected]> Date: Thu, May 7, 2009 at 10:01 PM To: Daniel Drake <[email protected]> Cc: Martin Langhoff <[email protected]>, "C. Scott Ananian" < [email protected]> From my understanding from http://wiki.laptop.org/go/Firmware_Security#Process 1. OFW check for valid lease.sig 2. No valid lease.sig run actos.zip 3. actos.zip copies lease.sig to /security 4. Continue boot. Since OFW will not see a valid lease.sig, will actos have to be run on every boot? (Increasing boot time?) While not having OFW support is not ideal, I'm not sure how much room there is in OFW for support. Since actos.zip and runos.zip are signed by a different key how much does this actually effect security (making changes to actos and runos) ? Apologies if my understanding is grossly in error. Reuben ---------- From: *Daniel Drake* <[email protected]> Date: Thu, May 7, 2009 at 10:09 PM To: [email protected] Cc: Martin Langhoff <[email protected]>, "C. Scott Ananian" < [email protected]> 2009/5/7 Reuben K. Caron <[email protected]>: Firstly, note that when booting actos, OFW *additionally* passes an "activate" parameter to the kernel. actos and runos are actually the same file. They could theoretically be different, and even if so they would be signed with the same key, but they currently are not. So, there's always one initramfs that boots. The initramfs looks for the presence of the "activate" parameter when deciding what to do: 1. If the activate parameter is *not* present, it boots the system as normal. Note that the initramfs does not check the lease even in this case; it trusts the judgement that OFW made by not passing the "activate" parameter. 2. If the activate parameter is present, the initramfs assumes that there is no lease available on the system (it doesn't bother checking) and starts hunting on SD, USB and wifi. In the discussions here, there may well be an act02 lease present on the system which other parts of the system will trust, but again, lease checking is currently *not* part of this codepath; the initramfs only listens to what OFW had to say about the situation. IMO changing the semantics here is risky, there is probably a reason that things are as they are (i.e. firmware-based security), and any changes would require a careful discussion between all parties... Daniel ---------- From: *Martin Langhoff* <[email protected]> Date: Fri, May 8, 2009 at 9:49 AM To: Daniel Drake <[email protected]> Cc: [email protected], "C. Scott Ananian" <[email protected]> I went to sleep last night wondering about that, so re-read init and antitheft.py first thing this morning. Your description is correct, the init process trusts the boot parameter and doesn't recheck things. It could very well switch to making the checks itself, and I'll argue that it is actually a reasonable thing to do, as we're still within the trusted codebase. I agree that more discussion will be good. However, I suspect that the actual reason is performance. What Mitch has mentioned serveral times is that as OFW is making the checks, a smaller, slimmer and faster(!) initrd could be used for the common case (hence runos.zip being separate). -- [email protected] [email protected] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff
_______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
