Date: Mon, 4 Apr 2016 13:50:49 +0200 From: Dirk-Willem van Gulik <dirkx@webweaving.org> To: FreeBSD Hackers <hackers@freebsd.org> Subject: reboot with reroot / 10.3 Message-ID: <B2CCFC6F-C8E9-4523-9CAB-345638D121D0@webweaving.org>
next in thread | raw e-mail | index | archive | help
Trasz, Thanks for the wonderful reroot present in 10.3 :) First tries work well = for us for a couple of scenario=E2=80=99s around pivoting early from an = ro-mounted bootup to mount the =E2=80=98real' encrypted root FS that has = its key stored on remote hardware (previously we used Adrian Steinmann / = ast his work on Pivot Root with a lot of care/order puzzles). I gather that it creates a /de/reroot tempfs; copies the, at that time, = on-disk version of init (as learned from a trusted kern.proc.pathname); = executes init with a new -r; that essentially does (just) a kill (as = only init can kill init) - and then things are mounted/cleaned up from = there after attempting to run at least something from = =E2=80=98kern.init_path=E2=80=99=20 Where would one go to understand the trust-chain/security aspects of = this ? I.e. what locks the kill(1, SIGEMT) to the copy of the real = init(8) ? Where are the places most at risk ? Thanks, Dw.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B2CCFC6F-C8E9-4523-9CAB-345638D121D0>