Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1945923Ab2JSWEZ (ORCPT ); Fri, 19 Oct 2012 18:04:25 -0400 Received: from mail-ob0-f174.google.com ([209.85.214.174]:36262 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932400Ab2JSWEY (ORCPT ); Fri, 19 Oct 2012 18:04:24 -0400 MIME-Version: 1.0 In-Reply-To: References: <87txtso9xw.fsf@rustcorp.com.au> <871ugwny1n.fsf@rustcorp.com.au> <87fw5bp858.fsf@rustcorp.com.au> From: Linus Torvalds Date: Fri, 19 Oct 2012 15:04:03 -0700 X-Google-Sender-Auth: JKjWzxEdsAjcXrSye2aMiKKZsk4 Message-ID: Subject: Re: RFC: sign the modules at install time To: Rusty Russell Cc: David Miller , David Howells , Linux Kernel Mailing List Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2378 Lines: 64 On Fri, Oct 19, 2012 at 12:58 PM, Linus Torvalds wrote: > > Tssk. I fixed it up, and now it works-for-me(tm), but some perl person > probably really should try to make that sign-file and x509keyid merge. > My fix made the thing even slower, doing two extra "wc -c" invocations > since it can't do "${#..}" expansion due to the locale problem. Hmm. I haven't seen this breakage personally yet, but looking more at Rusty's last changes I'm pretty sure my fixes are potentially not sufficient. In particular, this line from Rusty's sign-file script simplification makes me worry: KEYID="`perl $keyid_script $x509 keyid`" and the problem is that the 'keyid' is a binary blob. And I'm pretty damn sure that assigning random binary data to shell variables is going to break eventually. In particular, I tested NUL characters, and bash is not happy about doing things like a="`echo -en '\000'`" and 'a' ends up empty, not containing a one-byte string containing a NUL character. Not to mention that even if the shell were to handle this correctly, if you do echo -n "$a" then even *if* the shell remembered that 'a' contains one NUL character, when it then executes the 'echo' binary, that will certainly not be able to handle it. With a built-in 'echo' it _could_ work, with an external one it fundamentally could not. NUL is special, and terminates strings at execve(). You cannot have NUL bytes in arguments. Of course, I don't know the rules for x509 key id blobs. Maybe they aren't allowed to contain NUL anyway? Possible solutions: - Linus is a worry-wart, and key id's never contain NUL. - somebody with the appropriate perl-fu does the perl conversion, and keeps it all in perl. - somebody with (slightly less) perl-fu makes the x509 keyid_script return a quoted string, so that we can save that *quoted* version for the shell interatction (perhaps in a similar format that we now use for the "prologue" variable, ie just a list of hex bytes) otherwise we need to go back to putting the binary blob in a file (which shell won't corrupt). Rusty, David? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/