On Wed, Jan 08, 2020 at 02:48:13PM -0500, Noah Meyerhans wrote:
> The buster arm64 images on Amazon EC2 appear to have insufficient
> entropy at boot, and thus take several minutes to complete the boot
> process.
>
> There are a couple of potential fixes (or at least workarounds) for this
>
On Wed, Jan 08, 2020 at 11:25:34PM -0500, Theodore Y. Ts'o wrote:
> On Thu, Jan 09, 2020 at 01:11:41AM +, Luca Filipozzi wrote:
> >
> > (It's not like RNG quaility is a new problem... why didn't
> > virtualization approaches include host-to-guest RNG passthrough from the
> > beginning?)
>
>
On Wed, Jan 08, 2020 at 07:18:33PM -0500, Theodore Y. Ts'o wrote:
> I was under the impression that Amazon provided virtio-rng support for
> its VM's? Or does that not apply for their arm64 Vm's? If they do
> support virtio-rng, it might just be an issue of building the cloud
> kernel with that
On Wed, Jan 08, 2020 at 04:29:35PM -0500, Noah Meyerhans wrote:
> If the kernel team is supportive of the
> EFI_RNG+CONFIG_RANDOM_TRUST_BOOTLOADER approach, would folks be in
> favor of enabling haveged temporarily, until kernel support is
> available, or is it better to avoid it completely?
I
On Thu, Jan 09, 2020 at 12:41:28AM +, Luca Filipozzi wrote:
> On Wed, Jan 08, 2020 at 04:29:35PM -0500, Noah Meyerhans wrote:
> > If the kernel team is supportive of the
> > EFI_RNG+CONFIG_RANDOM_TRUST_BOOTLOADER approach, would folks be in
> > favor of enabling haveged temporarily, until
On Thu, Jan 09, 2020 at 01:11:41AM +, Luca Filipozzi wrote:
>
> (It's not like RNG quaility is a new problem... why didn't
> virtualization approaches include host-to-guest RNG passthrough from the
> beginning?)
Virtio-rng has been around since 2008 (over a decade), and it provides
On Wed, Jan 08, 2020 at 07:18:33PM -0500, Theodore Y. Ts'o wrote:
> Another approach would be to cherry pick 50ee7529ec45 ("random: try to
> actively add entropy rather than passively wait for it"). I'm pretty
> confident that it's probably fine ("it's fine. it's fine. Really,
> it's fine") for
The buster arm64 images on Amazon EC2 appear to have insufficient
entropy at boot, and thus take several minutes to complete the boot
process.
There are a couple of potential fixes (or at least workarounds) for this
problem, but none is entirely perfect.
Option 1:
We add haveged to the arm64
On Wed, Jan 08, 2020 at 02:48:13PM -0500, Noah Meyerhans wrote:
> We add haveged to the arm64 EC2 AMI. This appears to work, and is
> something we can do today. The debian-installer has previously used
> haveged to ensure reasonable entropy during installation, so there is
> some precident for
On Wed, Jan 08, 2020 at 02:48:13PM -0500, Noah Meyerhans wrote:
> Option 1:
>
> We add haveged to the arm64 EC2 AMI. This appears to work, and is
> something we can do today. The debian-installer has previously used
> haveged to ensure reasonable entropy during installation, so there is
> some
On 2020-01-08 13:04:42 -0800 (-0800), Ross Vandegrift wrote:
> On Wed, Jan 08, 2020 at 08:17:13PM +, Luca Filipozzi wrote:
> > On Wed, Jan 08, 2020 at 02:48:13PM -0500, Noah Meyerhans wrote:
> > > We add haveged to the arm64 EC2 AMI. This appears to work, and is
> > > something we can do
On Wed, Jan 08, 2020 at 12:50:04PM -0800, Ross Vandegrift wrote:
> I know of two other options:
> - pollinate
> - jitterentropy-rngd
>
> pollinate downloads seeds remotely, which feels wrong - and itself may
> require random numbers. I've never tried jitterentropy.
IMO these are roughly
> On Wed, 8 Jan 2020 16:40:33 -0500, Noah Meyerhans said:
> To be clear, the problem isn't a failure to boot, but rather a several
> minute pause during boot.
For me such a delay is kind of failure. And as Daniel wrote in his
blog "unverified entropy is better than no entropy."
--
On Wed, Jan 08, 2020 at 08:17:13PM +, Luca Filipozzi wrote:
> On Wed, Jan 08, 2020 at 02:48:13PM -0500, Noah Meyerhans wrote:
> > We add haveged to the arm64 EC2 AMI. This appears to work, and is
> > something we can do today. The debian-installer has previously used
> > haveged to ensure
On Wed, Jan 08, 2020 at 08:17:13PM +, Luca Filipozzi wrote:
> Every time I propose the use of haveged to resolve entropy starvation, I
> get reactions from crypto folks saying that it's not a valid solution.
> They invariably suggest that passing hardware RNG through to the VM is
> the
On Wed, Jan 08, 2020 at 09:24:25PM +, Jeremy Stanley wrote:
> > I've seen reactions like this, but never an explanation. Has anyone
> > written up the issues? Given that "fail to boot" isn't a workable
> > outcome, it'd be useful to know exactly what risks one accepts when
> > using haveged.
JFTR
https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html
--
regards Thomas
17 matches
Mail list logo
