On Fri, Jan 17, 2020 at 02:32:22PM -0500, Noah Meyerhans wrote:
> On Thu, Jan 09, 2020 at 05:22:17PM -0500, Noah Meyerhans wrote:
> > I've confirmed that 4.19.87 with changes cherry-picked from 50ee7529ec45
> > claims to have entropy at boot:
> >
> > admin@ip-172-31-49-239:~$ cloud-init analyze
On Thu, Jan 09, 2020 at 05:22:17PM -0500, Noah Meyerhans wrote:
> I've confirmed that 4.19.87 with changes cherry-picked from 50ee7529ec45
> claims to have entropy at boot:
>
> admin@ip-172-31-49-239:~$ cloud-init analyze blame
> -- Boot Record 01 --
> 02.88900s (init-network/config-ssh)
>
On Tue, Jan 14, 2020 at 03:01:23PM +, Luca Filipozzi wrote:
> > If we want to extend the cloud kernel to support other services, we need
> > to do more than just enable virtio-rng. Somebody need to come up with a
> > complete list of devices that are needed for the service in question,
> >
On Fri, Jan 10, 2020 at 01:33:12PM -0500, Noah Meyerhans wrote:
> On Fri, Jan 10, 2020 at 03:52:53AM +, Luca Filipozzi wrote:
> > Two questions (pretend i'm 6yo):
> >
> > (1) why can't AWS offer virtio-rng support (other than "we already offer
> > a RDRAND on amd64") and should Debian
On Fri, Jan 10, 2020 at 03:52:53AM +, Luca Filipozzi wrote:
> Two questions (pretend i'm 6yo):
>
> (1) why can't AWS offer virtio-rng support (other than "we already offer
> a RDRAND on amd64") and should Debian actively encourage their adding
> this support?
We can certainly ask. However,
On Thu, Jan 09, 2020 at 04:56:58PM -0500, Theodore Y. Ts'o wrote:
> On Thu, Jan 09, 2020 at 07:15:20PM +, Jeremy Stanley wrote:
> > On 2020-01-09 13:18:24 +0100 (+0100), Adam Dobrawy wrote:
> > [...]
> > > I wonder if the correct criterion for the cloud image is
> > > compatibility with AWS
On Thu, Jan 09, 2020 at 01:22:30PM -0500, Noah Meyerhans wrote:
> Our 5.4 kernel in sid does not suffer from a lack of entropy at boot on
> arm64 EC2 instances. I guess it could be due to the "random: try to
> actively add entropy rather than passively wait for it" that tytso
> mentioned earlier.
On Thu, Jan 09, 2020 at 07:15:20PM +, Jeremy Stanley wrote:
> On 2020-01-09 13:18:24 +0100 (+0100), Adam Dobrawy wrote:
> [...]
> > I wonder if the correct criterion for the cloud image is
> > compatibility with AWS and GCP only. I suppose a large number of
> > deployment are based on private
On 2020-01-09 13:18:24 +0100 (+0100), Adam Dobrawy wrote:
[...]
> I wonder if the correct criterion for the cloud image is
> compatibility with AWS and GCP only. I suppose a large number of
> deployment are based on private cloud environments (OpenStack
> etc.).
[...]
Setting aside for the moment
On Thu, Jan 09, 2020 at 04:57:24PM +, Luca Filipozzi wrote:
> > > >> I'd encourage those of you who are in position to make Amazon listen
> > > >> to get with the program and support virtio-rng. :-)
> > > > Noah: chances of AWS supporting virtio-rng?
> > > I wonder if the correct criterion
On Thu, Jan 09, 2020 at 07:54:14AM -0500, Noah Meyerhans wrote:
> On Thu, Jan 09, 2020 at 01:18:24PM +0100, Adam Dobrawy wrote:
> > >> I'd encourage those of you who are in position to make Amazon listen
> > >> to get with the program and support virtio-rng. :-)
> > > Noah: chances of AWS
On Thu, Jan 09, 2020 at 01:18:24PM +0100, Adam Dobrawy wrote:
> >> I'd encourage those of you who are in position to make Amazon listen
> >> to get with the program and support virtio-rng. :-)
> > Noah: chances of AWS supporting virtio-rng?
> I wonder if the correct criterion for the cloud image
W dniu 09.01.2020 o 06:47, Luca Filipozzi pisze:
>> I'd encourage those of you who are in position to make Amazon listen
>> to get with the program and support virtio-rng. :-)
> Noah: chances of AWS supporting virtio-rng?
I wonder if the correct criterion for the cloud image is compatibility
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 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
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 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 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 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
>
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
> 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 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.
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, 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 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 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 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 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
29 matches
Mail list logo
