On 01/16/14 at 09:31am, Vivek Goyal wrote:
On Thu, Jan 16, 2014 at 11:35:57AM +0800, WANG Chao wrote:
> On 01/15/14 at 12:52pm, Vivek Goyal wrote:
> > On Wed, Jan 15, 2014 at 03:39:14PM +0800, WANG Chao wrote:
> >
> > [..]
> > > > I am not sure if random seed is optional. I think things will still
work
> > > > but enough randomness might not be there and it might make for
weaker
> > > > crypto and might make it little less secure in kdump environemnt.
> > >
> > > Yes, it's right. Without sufficient entropy, the random could be
> > > theoretically vulnerable. That makes kdump environment less secure like
> > > you said.
> > >
> > > But kdump can't force user to maintain such random seed file
> > > /var/lib/systemd/random-seed or /var/lib/random-seed. For whatever
> > > reason, this seed file could be deleted or relocated some other place.
> > >
> > > Given the fact that entropy may be not sufficient and we must feed
> > > /dev/urandom in 2nd kernel. What makes sense to me is that we generate
> > > our own seed when creating kdump initramfs and feed this one to
> > > /dev/urandom in 2nd kernel.
> > >
> > > It's rather simple to implement it.
> > > [inspired from man:random(4)]
> > >
> > > In module-setup.sh, save random seed:
> > >
> > > dd if=/dev/urandom of=${initdir}/$RANDOM_SEED \
> > > bs=`cat /proc/sys/kernel/random/poolsize` count=1
> > >
> > > In kdump.sh, feed /dev/urandom with our preserved randome seed:
> > >
> > > cat $RANDOM_SEED > /dev/urandom
> > >
> > > So neither we have to fail when kdump can't find the system-wide
random
> > > seed file nor we have worry about where the seed is located.
> >
> > In general I like the idea that we use /dev/urandom to save the seed if
> > it is not available at standard places. So how about following.
> >
> > if [ -f /var/lib/random-seed ]
> > dracut_install /var/lib/random-seed
> > elif [ -f /var/lib/systemd/random-seed ]
> > dracut_install /var/lib/systemd/random-seed
> > else
> > /* Use /dev/urandom as random seed */
> > fi
>
> It's too complicated code block and if the seed file changes again, we
> have to address it for another time. The code block will grow larger and
> larger.
>
> A seed file doesn't have to be the standard one. As far as I know,
> /var/lib/systemd/random-seed works in a quite simple way:
>
> 1. When system is booting, systemd-random-seed.service starts and do the
> following job:
>
> a) Restore the entropy pool from the last boot by:
>
> cat /var/lib/systemd/random-seed > /dev/urandom
>
> b) Save the entropy pool for the next boot by (in case a sudden
> shutdwon):
>
> dd if=/dev/urandom of=${initdir}/$RANDOM_SEED \
> bs=`cat /proc/sys/kernel/random/poolsize` count=1
>
> 2. When system is shutting down, s-r-s.service stops and do the
> following job:
>
> a) Save the entropy pool for the next boot:
>
> dd if=/dev/urandom of=${initdir}/$RANDOM_SEED \
> bs=`cat /proc/sys/kernel/random/poolsize` count=1
>
> So based on how /var/lib/systemd/random-seed works, I think it's nothing
> wrong if we use a random seed created by ourselves. It could be less
> vulnerable (more secure) using a different random seed rather than
> presevering /var/lib/systemd/random-seed for 2nd kernel.
>
> That's why I'd like to stick to the idea to create our own seed and not
> use the systemd's one.
There is a problem with kdump saving the seed. And that is kdump is
started at the beginning of boot and you are assuming that by then
systemd has restored the entropy pool from previously saved random seed.
I looked into the systemd services dependencies[1], I found that kdump
would always run after systemd-random-seed. That said, when kdump is
starting, /dev/urandom is already feed. And actually systemd-random-seed
service is started very early, same level with systemd-udevd,
systemd-journald etc. and systemd-random-seed is only depending on the /
mount.
[1]: I got this data by running `systemctl list-dependencies kdump`
That's the reason I wanted to use last stored random seed instead of
relying on the fact that /dev/urandom has been initialized with right
random seed.
Except it is a fact...
Thanks
WANG Chao