linux-kernel - Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

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 09:19:46 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
	hpa@...or.com, mjg59@...f.ucam.org, greg@...ah.com
Subject: Re: [PATCH 0/6] kexec: A new system call to allow in kernel loading

On Fri, Nov 22, 2013 at 05:34:03AM -0800, Eric W. Biederman wrote:

[..]
> > Why ELF case is so interesting. I have not use kexec to boot ELF
> > images in years and have not seen others using it too. In fact bzImage
> > seems to be the most common kernel image format for x86, most of the distros
> > ship and use.
> 
> ELF is interesting because it is the minimal file format that does
> everything you need.   So especially for a proof of concept ELF needs to
> come first.  There is an extra virtual address field in the ELF segment
> header but otherwise ELF does not have any unnecessary fields.
> 
> ELF is interesting because it is the native kernel file format on all
> architectures linux supports including x86.
> 
> ELF is interesting because producing an ELF image in practice requires
> a trivial amount of tooling so it is a good general purpose format to
> support.

Ok. I will have a look at ELF loader too. I was hoping to keep only one
loader in initial patch. But looks like that's not acceptable.

[..]
> >> There is also a huge missing piece of this in that your purgatory is not
> >> checking a hash of the loaded image before jumping too it.  Without that
> >> this is a huge regression at least for the kexec on panic case.  We
> >> absolutely need to check that the kernel sitting around in memory has
> >> not been corrupted before we let it run very far.
> >
> > Agreed. This should not be hard. It is just a matter of calcualting
> > digest of segments. I will store it in kimge and verify digest again
> > before passing control to control page. Will fix it in next version.
> 
> Nak.  The verification needs to happen in purgatory. 
> 
> The verification needs to happen in code whose runtime environment is
> does not depend on random parts of the kernel.  Anything else is a
> regression in maintainability and reliability.
> 
> It is the wrong direction to add any code to what needs to run in the
> known broken environment of the kernel when a panic happens.
> 
> Which means that you almost certainly need to go to the trouble of
> supporting the complexity needed to support purgatory code written in C.
> 
> (For those just tuning in purgatory is our term for the code that runs
> between the kernels to do those things that can not happen a priori).

In general, I agree with not using kernel parts after crash.

But what protects against that purgatory itself has been scribbled over.
IOW, how different purgatory memory is as compared to kernel memory where
digest routines are stored. They have got equal probably of being scribbled
over and if that's the case one is not better than other?

And if they both got equal probability to getting corrupted, then there does
not seem to be an advantage in moving digest verification inside purgatory.

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/