[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1358793893.2406.143.camel@falcor1.watson.ibm.com>
Date: Mon, 21 Jan 2013 13:44:53 -0500
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: linux-kernel@...r.kernel.org, ebiederm@...ssion.com,
pjones@...hat.com, hpa@...or.com, dhowells@...hat.com,
jwboyer@...hat.com
Subject: Re: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary
On Mon, 2013-01-21 at 10:45 -0500, Vivek Goyal wrote:
> On Sun, Jan 20, 2013 at 12:20:00PM -0500, Mimi Zohar wrote:
> > On Thu, 2013-01-17 at 12:36 -0500, Vivek Goyal wrote:
> > > On Thu, Jan 17, 2013 at 11:32:45AM -0500, Mimi Zohar wrote:
> > >
> > > [..]
> > > > > > At this point, why would you want yet another method for signing files?
> > > > >
> > > > > Are you saying that append signature instead of putting them in a section
> > > > > or are you saying that just use IMA.
> > > > >
> > > > > - For the first, I am fine with appending too if that works better. So
> > > > > what's wrong with current implementation. Just because we append the
> > > > > signatures in case of modules, we should follow the same thing for
> > > > > executables too?
> > > >
> > > > No, I was saying that if this patch set were to be upstreamed, then the
> > > > signature verification, at least for ELF modules and ELF executables,
> > > > should be the same. The patch would then be a lot smaller.
> > >
> > > I don't think that patch is lot smaller. Initially I had written code
> > > where signatures were appended. Parsing the signature is little different
> > > from module. In case of modules, whole file is already in memory and
> > > in case of executables, we are reading selected portions of file in
> > > buffer.
> >
> > Have you looked at the original kernel module signature verification
> > code as posted by David? It did something similar, but was not
> > upstreamed.
>
> I have. I think keeping code in a section makes stripping of section
> easy. Anyway, these sections are not loaded in memory at file exec
> time so it should be fine.
>
> So appending signature is easy and I can change the implementation to
> do it like modules.
>
> But please give a more stronger reason that why it should be appened
> to executable then put in a section.
There are two existing upstreamed methods for verifying the integrity of
files. One uses a file descriptor, the other is memory based, for the
specific use case, where a file descriptor is not available. The real
question is what benefit there is to adding another method? That
question needs to be addressed in the patch description.
thanks,
Mimi
--
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/
Powered by blists - more mailing lists