linux-kernel - Re: [PATCH 00/23] Crypto keys and module signing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87r4u6w58c.fsf@rustcorp.com.au>
Date:	Sun, 27 May 2012 15:11:23 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	David Howells <dhowells@...hat.com>
Cc:	dhowells@...hat.com, kyle@...artin.ca,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, keyrings@...ux-nfs.org
Subject: Re: [PATCH 00/23] Crypto keys and module signing

On Thu, 24 May 2012 15:00:51 +0100, David Howells <dhowells@...hat.com> wrote:
> It doesn't really need the @ signs or the MSIZE; they can be dropped.
...
> That then adds 5 bytes to the magic string.  Is that really so bad?

Yes, because it's unnecessary.

Now you've decided to encode some data, you need to decide how.  And you
discovered that they all sucked in different ways.  Binary is a PITA for
the shell, so you chose to put ASCII (in the middle of an
otherwise-binary blob).  Then you chose a fixed length with space-based
padding as the least of all evils.

But it's still completely tasteless.

Sure, my code didn't even compile.  And yes, it takes about 70ms on an
8M file on my laptop, and yes, that drops to about 6ms if we check one
char manually.  It would drop further if we searched forwards, using
memchr then memcmp, but it's already below my care factor.

> > > Why would you want multiple signatures?  That just complicates things.
> > 
> > The code above stays pretty simple; if the signature fails, you set size
> > to i, and loop again.  As I said, if you know exactly how you're going
> > to strip the modules, you can avoid storing the stripped module and
> > simply append both signatures.
> 
> You still haven't justified it.  One of your arguments about rejecting the ELF
> parsing version was that it was too big for no useful extra value that I could
> justify.  Supporting multiple signatures adds extra size and complexity for no
> obvious value.

One loop is a lot easier to justify that the ELF-parsing mess.  And it
can be done in a backwards compatible way tomorrow: old kernels will
only check the last signature.

I had assumed you'd rather maintain a stable strip util which you can
use on kernel modules than rework your module builds.  I guess not.

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/