On Mon, 12 Dec 2011 16:11:27 +0000, David Howells <dhowells@xxxxxxxxxx> wrote: > Rusty Russell <rusty@xxxxxxxxxx> wrote: > > > OK, then you need to generate stripped modules as part of the build, > > too. It's a bit of a pain, sure, but hardly a showstopper. > > They'd have to be maximally stripped so that mkinitrd doesn't do anything to > them, but you'd then get the debuginfo from them into the packaging if you're > on some distribution or other. And you also provide an option to not strip > them if whoever wants them unstripped. I was thinking we generate multiple modules; people will definitely want unstripped versions as well. > > A signature contains a magic marker > > I don't like this particularly - you can't guarantee that this won't be > generated by the assembler quite by accident. We don't care, in practice. It can't generate a valid key by accident. The only difference is that you might get "bad key" instead of "no key" if no sigature matches. But a validly parsable signature won't happen in practice. > You should find the end of the > ELF and work from there. It should be a simple matter of parsing the header > and the section table only, right? Then you can look at the file offset + > length of the last section in the file. Tried that first. It's more lines (which need to be carefully scrutinized)... > At that point, assuming this isn't > coincident with the actual end of the file, you can try parsing what's > thereafter as a signature. If it is actual PGP, then an RFC4880 parser should > recognise it as valid, and a signature packet should be seen. ...and you can still have padding. At which point, I realised that we might as well just scan the whole thing and be done. It's a bit cheeky, but I *know* it works, and can be verified by any reader without knowing anything about ELF or trusting the format at all. > > A signature contains a magic marker: it signs everything up to the > > magic marker (ie. just append them): > > SUM=`md5sum drivers/block/loop.ko | cut -d\ -f1`; echo "@Module signature:$SUM" >> drivers/block/loop.ko > > That's not a useful signature, but I suspect you're just showing this as an > example. Yeah, it was supposed to be a dumb example... > > We can have false positives, but at worst that make us report EINVAL > > (bad signature) instead of ENOENT (no signature). > > EKEYREJECTED please; that way it's the same as RHEL does now. OK, sure (who knew that was there?). > > Took me longer to figure out the damn crypto API > > You don't actually need to use that. The crypto API for the moment doesn't do > crytographic signature verification. Sure, I was working on mainline, which is why I chose md5 (plus using md5sum is easy). > returns -EBADMSG if none of its parsers recognise the signature, -ENOPKG if > the signature is recognised, but we can't handle it (for instance if it's an > unsupported hash algorithm), -ENOKEY if we recognise it, but there's no key > available or -EKEYREJECTED if we recognised it, found the matching key, but > the key couldn't be used to verify the signature for some reason. > > /* Call repeatedly to shovel data into the crypto hash */ > verify_sig_add_data(mod_sig, dataptr, datasize); > > /* Call to finalise and actually perform the verification */ > ret = verify_sig_end(mod_sig, sig, sig_size); > > or: > > /* Call to cancel the verification */ > verify_sig_cancel(mod_sig); > > This does all the work for you. That looks really nice, actually! Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
