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: <CAKi4VA+ntfH=ezAU77T3WFr6kqgXMb9npJ_msSQyCwps75yuEA@mail.gmail.com>
Date:	Fri, 22 Jun 2012 00:29:46 -0300
From:	Lucas De Marchi <lucas.de.marchi@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	David Howells <dhowells@...hat.com>, kyle@...artin.ca,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, keyrings@...ux-nfs.org,
	linux-modules <linux-modules@...r.kernel.org>
Subject: Re: [PATCH 00/23] Crypto keys and module signing

Hi,

Sorry to jump into this discussion only now, but
linux-modules@...r.kernel.org was not CC'ed and I was not following
LKML last month.

On Thu, Jun 21, 2012 at 10:53 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Sun, May 27, 2012 at 03:11:23PM +0930, Rusty Russell wrote:
>> > > > 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.
>
> To dig an old thread up, but what really is wrong with the original ELF
> section stuff?  Why encode "magic" values on the end of the kernel
> module that then require all userspace tools to be modified in order to
> properly handle this?
>
> When I first did this so many many years ago an elf section made it so
> easy to handle.  Userspace didn't need to be modified, and everyone
> knows how to handle elf sections, even the kernel does :)

Indeed. What's wrong with creating an ELF section for this and let
kernel deal with it? I fail to see the need for init_module2()

I need to catch up with this discussion though since I was not aware of that.


Lucas De Marchi

>
> And I think we really want the ability to have multiple signatures, the
> whole "chain of trust" thing that is needed will work out much better if
> multiple signatures are allowed.  Putting it in an elf section allows
> this to work out easier, right?
>
> confused,

me too.


Lucas De Marchi
--
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/