[RFC] Add "GELI Passphrase:" prompt to boot loader
Devin Teske
dteske at FreeBSD.org
Mon Apr 6 18:09:44 UTC 2015
> On Apr 6, 2015, at 10:52 AM, Eric van Gyzen <vangyzen at FreeBSD.org> wrote:
>
> On 04/06/2015 13:39, Devin Teske wrote:
>>
>>> On Apr 6, 2015, at 10:24 AM, Eric van Gyzen <eric at 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.
>
Kk. In the meantime, I’ve updated the patch in D2105 to reflect the new potential
outcome. Worth noting, that I left the kern_unsetenv() call in sys/geom/eli/geom_eli.c
in-tact (didn’t see any harm in calling kern_unsetenv() on the same variable twice; no
real conerns of removing it, just didn’t see any harm in leaving it).
Would like feedback on phabricator.
https://reviews.freebsd.org/D2105 <https://reviews.freebsd.org/D2105>
—
Cheers,
Devin
More information about the freebsd-current
mailing list