linux-kernel - Re: [PATCH 4/6] kexec: A new system call, kexec_file

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]

Date:	Fri, 22 Nov 2013 13:57:06 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	kexec@...ts.infradead.org, ebiederm@...ssion.com, hpa@...or.com,
	Peter Jones <pjones@...hat.com>
Subject: Re: [PATCH 4/6] kexec: A new system call, kexec_file_load, for in
 kernel kexec

On Thu, Nov 21, 2013 at 07:19:07PM +0000, Matthew Garrett wrote:
> On Thu, Nov 21, 2013 at 02:13:05PM -0500, Vivek Goyal wrote:
> > On Thu, Nov 21, 2013 at 07:06:20PM +0000, Matthew Garrett wrote:
> > > That would require a certain degree of massaging from userspace if we 
> > > want to be able to use the existing Authenticode signatures. Otherwise 
> > > we need to sign kernels twice.
> > 
> > I was thinking oof signing the same kernel twice. Can I sign authenticode
> > signed kernel again (using RSA signature as we do for modules) and append
> > the signature to bzImage. 
> 
> No, you'd need to do it the other way around.

Hmm..., I am running out of ideas here. This is what I understand.

- If I sign the bzImage (using PKCS1.5 signature), and later it is signed
  with authenticode format signatures, then PKCS1.5 signatures will not be
  valid as PE/COFF signing will do some modification to PE/COFF header in
  bzImage. And another problem is that then I don't have a way to find
  PKCS1.5 signature.

- If bzImage is first signed with authenticode format signature and then
  signed using PKCS1.5 signature, then  authenticode format signature
  will become invalid as it will also hash the data appened at the end
  of file.

So looks like both signatures can't co-exist on same file. That means
one signature has to be detached.

I am beginning to think that create a kernel option which allows to choose
between attached and detached signatures. Extend kexec syscall to allow
a parameter to pass in detached signatures. If detached signatures are
not passed, then look for signatures at the end of file. That way, those
who are signing kernels using platform specific format (authenticode) in 
this case, they can generate detached signature while others can just
use attached signatures.

Any thoughts on how this should be handled?

Thanks
Vivek
--
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/