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]

Message-ID: <87siu8545t.fsf@xmission.com>
Date:	Wed, 04 Dec 2013 20:10:22 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Vivek Goyal <vgoyal@...hat.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

Vivek Goyal <vgoyal@...hat.com> writes:

> Hi Eric,
>
> So you want a separate purgatory code and that purgatory should be self
> contained and should not share any code with rest of the kernel. No
> inclusion of header files, no linking against kernel libraries? That means
> even re-implementing sha256 functions separately (like user space)?

Call only trivial sharing of code with the rest of the kernel.   But only
as much as say the kernel decompressor has.  

> If code maintenance is a concern, then I think I can reimplement some
> of the functions to calculate sha256 in separate crash files and invoke
> those to reduce code sharing with rest of the kernel. And we should be
> able to link against the kernel and not have to create separate
> relocatable purgatory object and relocate it.

It is both code maintenance and the fact that we have a strong
expectation that where purgatory lives should not be corrupted.
Plus what I have seen there maintenance becomes much simpler if there is
a little bit of C code that lives between the two kernels.  At that
point people don't have to grok assembly to be able to touch anything,
and by simply living their it enforces separation of concerns
from the kernel in a way that is trivial and obvious.

Plus we already have all of the code in userspace to do all of this work
so it is not something you would need to write from scrach merely
something that you would need to adapt.

> IOW, does purgatory still have to be a relocatable object?

Fundamentally purgatory does need to be a relocatable object.

> I think
> user space had no choice but given the fact that we are implementing
> thing in kernel, I should be able to implement my own hash calculation
> and segment verification code and link it to existing kernel and invoke
> these outside purgatory. 

Doing this outside of purgatory and linking to the rest of the kernel is
almost certainly enough to get someone to perform an obvious cleanup
that will undermine the purpose of the code.  Or perhaps it will be
merely a reference to the GOT table behind our backs in the C code
generated by the compiler that will undermine this checking.

Linking to our sanity checks to the rest of the kernel leaves me
profoundly uncomfortable.

> Anyway, we call so many other functions after
> crash to stop cpus, save registers, etc.

There is no other possible place to stop cpus, and save the cpu
registers.  As much as possible that should be the only justification
for the code we run on the kexec on panic code path.

Honestly calling so many other functions on that code path is a good
reason to see about removing them.  In addition to my other reasons
adding the hash calculation on that path will likely confuse issues
more than helping them.

Eric

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