Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 06 Apr 2015 13:52:37 -0400
From:      Eric van Gyzen <vangyzen@FreeBSD.org>
To:        Devin Teske <dteske@FreeBSD.org>
Cc:        freebsd-current@freebsd.org, cperciva@freebsd.org
Subject:   Re: [RFC] Add "GELI Passphrase:" prompt to boot loader
Message-ID:  <5522C7E5.4090609@FreeBSD.org>
In-Reply-To: <72AB2A13-8DA5-4320-8302-598B6672DA25@FreeBSD.org>
References:  <0D7CA1BF-3052-41FD-A3E7-5BBAA51B214A@FreeBSD.org> <5522C167.6090408@vangyzen.net> <72AB2A13-8DA5-4320-8302-598B6672DA25@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 04/06/2015 13:39, Devin Teske wrote:
> 
>> On Apr 6, 2015, at 10:24 AM, Eric van Gyzen <eric@vangyzen.net> wrote:
>>
>> On 04/06/2015 12:58, Devin Teske wrote:
>>> Hi -current,
>>>
>>> I have a pending enhancement to the boot loader that Colin P. and I
>>> have been working on together.
>>>
>>> URL: https://reviews.freebsd.org/D2105 <https://reviews.freebsd.org/D2105>;
>>>
>>> The nature of the patch is to cause the boot loader to prompt for the
>>> GELI passphrase and then pass that on (through a kenv(1) variable)
>>> to Colin’s code in geom_eli.ko where it will be:
>>>
>>> (a) picked up for-use as the initial passphrase attempt(s)
>>> (b) zeroed after being picked-up so “kenv kern.geom.eli.passphrase”
>>> returns nothing
>>>
>>> NB: Actually, “kenv kern.geom.eli.passphrase” generates the error
>>> “kenv: unable to get kern.geom.eli.passphrase”
>>>
>>> The problem that I (we) need help in solving is:
>>>
>>> If the geom_eli.ko module doesn’t get loaded, then the variable
>>> (kern.geom.eli.passphrase) is not zeroed.
>>>
>>> While I do think that this is of minimal concern (not loading the GELI
>>> module means you won’t be able to get past the mountroot prompt in
>>> the case where GELI is required to boot), I discussed with Colin and
>>> I think we are in consensus that the resetting of the variable should
>>> perhaps be moved to another section of the kernel to prevent leakage
>>> of this sensitive information being passed through kenv(1) variable(s).
>>>
>>> Issue for me is, I’m not sure where the best place to move this to.
>>> Here’s the code that needs to be moved (Lines 108-109 of g_eli.c):
>>>
>>> https://svnweb.freebsd.org/base?view=revision&revision=273489 <https://svnweb.freebsd.org/base?view=revision&revision=273489>;
>>>
>>>
>>> 108 <https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?annotate=273489&pathrev=273489#l108>;	 	                 /* Wipe the passphrase from the environment. */
>>> 109 <https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?annotate=273489&pathrev=273489#l109>;	 	                 kern_unsetenv("kern.geom.eli.passphrase");
>>>
>>> Need to move that preferably to some place in the kernel that is NOT
>>> optional in the compilation process. Suggestions?
>>
>> How about putting it right after a successful mount of the root file system? 
>> (I've never used GELI, so this could be as "right out" as five.)
>>
> 
> I think that’s an excellent idea.
> 
> /me rummages through source
> 
> I’m thinking that the best place might be where we deal with the registered
> event handler for mountroot.
> 
> 
> One place that I crawled upon that looks particularly sexy is in start_init()
> of sys/kern/init_main.c:
> 
> ### BEGIN SNIPPET ###
> /*
>  * Start the initial user process; try exec’ing each pathname in init_path.
>  * The program is invoked with one argument containing the boot flags.
>  */
> static void
> start_init(void *dummy)
> {
> 	vm_offset_t addr;
> 	struct execve_args args;
> 	int options, error;
> 	char *var, *path, *next, *s;
> 	char *ucp, **uap, *arg0, *arg1;
> 	struct thread *td;
> 	struct proc *p;
> 
> 	mtx_lock(&Giant);
> 
> 	GIANT_REQUIRED;
> 
> 	td = furthered;
> 	p = td->td_proc;
> 
> 	vfs_mountroot();
> 
> 	### RFC for code placement ###
> 	/* XXX Put reset of kern.geom.eli.passphrase here XXX */
> 	##########################
> 
> 	/*
> 	 * Need just enough stack to hold the faked-up “execve()” arguments.
> 	 */
> 	// snip rest //
> ### END SNIPPET ###
> 
> Or can you think of a better place?

That looks good to me, although I'm no expert in this area, so you might wait
for more opinions.

Eric



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5522C7E5.4090609>