On Fri, 2018-05-18 at 19:22 -0400, Theodore Y. Ts'o wrote:
> On Fri, May 18, 2018 at 10:56:18PM +, Trent Piepho wrote:
> >
> > Let's look at what we're doing after this fix:
> > Want non-cryptographic random data for UUID, ask kernel for it.
> > Kernel has non-cryptographic random data, won't
On Fri, May 18, 2018 at 10:56:18PM +, Trent Piepho wrote:
>
> I feel like "fix" might overstate the result a bit.
>
> This ends up taking a full second to make each UUID. Having gone to
> great effort to make an iMX25 complete userspace startup in 250 ms, a
> full second, per UUID, in early
On Thu, 2018-05-17 at 22:32 -0400, Theodore Y. Ts'o wrote:
> On Fri, May 18, 2018 at 01:27:03AM +, Trent Piepho wrote:
> > I've hit this on an embedded system. mke2fs hangs trying to format a
> > persistent writable filesystem, which is where the random seed to
> > initialize the kernel entrop
On Fri, May 18, 2018 at 01:27:03AM +, Trent Piepho wrote:
>
> I've hit this on an embedded system. mke2fs hangs trying to format a
> persistent writable filesystem, which is where the random seed to
> initialize the kernel entropy pool would be stored, because it wants 16
> bytes of non-crypt
Since I wasn't on this thread from the start, I can only find a way to
reply to message in mbox format on patchwork, and this seemed the best.
On Fri, 2018-04-27 at 16:10 -0400, Theodore Tso wrote:
>
>
> This is why ultimately, we do need to attack this problem from both
> ends, which means teac
On Wed, May 2, 2018 at 5:25 PM, Theodore Y. Ts'o wrote:
> On Wed, May 02, 2018 at 10:49:34AM -0700, Laura Abbott wrote:
>>
>> It is a Fedora patch we're carrying
>> https://src.fedoraproject.org/rpms/libgcrypt/blob/master/f/libgcrypt-1.6.2-fips-ctor.patch#_23
>> so yes, it is a Fedora specific use
On Wed 2018-05-02 18:25:22, Theodore Y. Ts'o wrote:
> On Wed, May 02, 2018 at 10:49:34AM -0700, Laura Abbott wrote:
> >
> > It is a Fedora patch we're carrying
> > https://src.fedoraproject.org/rpms/libgcrypt/blob/master/f/libgcrypt-1.6.2-fips-ctor.patch#_23
> > so yes, it is a Fedora specific use
On Wed, May 02, 2018 at 10:49:34AM -0700, Laura Abbott wrote:
>
> It is a Fedora patch we're carrying
> https://src.fedoraproject.org/rpms/libgcrypt/blob/master/f/libgcrypt-1.6.2-fips-ctor.patch#_23
> so yes, it is a Fedora specific use case.
> From talking to the libgcrypt team, this is a FIPS mo
On 05/02/2018 09:26 AM, Theodore Y. Ts'o wrote:
On Wed, May 02, 2018 at 07:09:11AM -0500, Justin Forbes wrote:
Yes, Fedora libgcrypt is carrying a patch which makes it particularly
painful for us, we have reached out to the libgcrypt maintainer to
follow up on that end. But as I said before, eve
On Wed, May 02, 2018 at 07:09:11AM -0500, Justin Forbes wrote:
> Yes, Fedora libgcrypt is carrying a patch which makes it particularly
> painful for us, we have reached out to the libgcrypt maintainer to
> follow up on that end. But as I said before, even without that code
> path (no dracut-fips) w
On Tue, May 1, 2018 at 7:02 PM, Theodore Y. Ts'o wrote:
> On Tue, May 01, 2018 at 05:35:56PM -0500, Justin Forbes wrote:
>>
>> I have not reproduced in GCE myself. We did get some confirmation
>> that removing dracut-fips does make the problem less dire (but I
>> wouldn't call a 4 minute boot a w
On Tue, May 01, 2018 at 08:56:04PM -0400, Theodore Y. Ts'o wrote:
> On Tue, May 01, 2018 at 05:43:17PM -0700, Sultan Alsawaf wrote:
> >
> > I've attached what I think is a reasonable stopgap solution until this is
> > actually fixed. If you're willing to revert the CVE-2018-1108 patches
> > comple
On Tue, May 01, 2018 at 05:43:17PM -0700, Sultan Alsawaf wrote:
>
> I've attached what I think is a reasonable stopgap solution until this is
> actually fixed. If you're willing to revert the CVE-2018-1108 patches
> completely, then I don't think you'll mind using this patch in the meantime.
I wo
On Tue, May 01, 2018 at 05:35:56PM -0500, Justin Forbes wrote:
>
> I have not reproduced in GCE myself. We did get some confirmation
> that removing dracut-fips does make the problem less dire (but I
> wouldn't call a 4 minute boot a win, but booting in 4 minutes is
> better than not booting at a
On Tue, May 01, 2018 at 05:35:56PM -0500, Justin Forbes wrote:
>
> I have not reproduced in GCE myself. We did get some confirmation
> that removing dracut-fips does make the problem less dire (but I
> wouldn't call a 4 minute boot a win, but booting in 4 minutes is
> better than not booting at a
On Tue, May 1, 2018 at 7:55 AM, Theodore Y. Ts'o wrote:
> On Tue, May 01, 2018 at 06:52:47AM -0500, Justin Forbes wrote:
>>
>> We have also had reports that Fedora users are seeing this on Google
>> Compute Engine.
>
> Can you reproduce this yourself? If so, could you confirm that
> removing the
On Mon 2018-04-30 12:11:43, Theodore Y. Ts'o wrote:
> On Sun, Apr 29, 2018 at 09:34:45PM -0700, Sultan Alsawaf wrote:
> >
> > What about abusing high-resolution timers to get entropy? Since hrtimers
> > can't
> > make guarantees down to the nanosecond, there's always a skew between the
> > reques
On Tue, May 01, 2018 at 06:52:47AM -0500, Justin Forbes wrote:
>
> We have also had reports that Fedora users are seeing this on Google
> Compute Engine.
Can you reproduce this yourself? If so, could you confirm that
removing the dracut-fips package makes the problem go away for you?
Thanks,
On Mon, Apr 30, 2018 at 4:12 PM, Jeremy Cline wrote:
> On 04/29/2018 06:05 PM, Theodore Y. Ts'o wrote:
>> On Sun, Apr 29, 2018 at 01:20:33PM -0700, Sultan Alsawaf wrote:
>>> On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote:
Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE
>>>
On 04/29/2018 06:05 PM, Theodore Y. Ts'o wrote:
> On Sun, Apr 29, 2018 at 01:20:33PM -0700, Sultan Alsawaf wrote:
>> On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote:
>>> Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE
>>
>> Okay, but /dev/urandom isn't a solution to this problem b
On Sun, Apr 29, 2018 at 09:34:45PM -0700, Sultan Alsawaf wrote:
>
> What about abusing high-resolution timers to get entropy? Since hrtimers can't
> make guarantees down to the nanosecond, there's always a skew between the
> requested expiry time and the actual expiry time.
>
> Please see the att
On Sun, Apr 29, 2018 at 08:11:07PM -0400, Theodore Y. Ts'o wrote:
>
> What your patch does is assume that there is a full bit of uncertainty
> that can be obtained from the information gathered from each
> interrupt. I *might* be willing to assume that to be valid on x86
> systems that have a high
On 04/29/2018 03:05 PM, Theodore Y. Ts'o wrote:
What would be useful is if people gave reports that listed exactly
what laptop and distributions they are using. Just "a high spec x86
laptop" isn't terribly useful, because*my* brand-new Dell XPS 13
running Debian testing is working just fine. T
On Sun, Apr 29, 2018 at 07:07:29PM -0400, Dave Jones wrote:
> > Why do we continue to print this stuff out when crng_init=1 though ?
>
> answering my own question, I think.. This is a tristate, and we need it
> to be >1 to be quiet, which doesn't happen until..
>
> > [ 165.806247] random: crng
On Sun, Apr 29, 2018 at 03:49:28PM -0700, Sultan Alsawaf wrote:
> On Mon, Apr 30, 2018 at 12:43:48AM +0200, Jason A. Donenfeld wrote:
> > > - if ((fast_pool->count < 64) &&
> > > - !time_after(now, fast_pool->last + HZ))
> > > - return;
> > > -
> >
> > I suspect you s
On Sun, Apr 29, 2018 at 07:02:02PM -0400, Dave Jones wrote:
> On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote:
>
> > Can you tell me a bit about your system? What distribution, what
> > hardware is present in your sytsem (what architecture, what
> > peripherals are attach
On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote:
> Can you tell me a bit about your system? What distribution, what
> hardware is present in your sytsem (what architecture, what
> peripherals are attached, etc.)?
>
> There's a reason why we made this --- we were declaring t
On Mon, Apr 30, 2018 at 12:43:48AM +0200, Jason A. Donenfeld wrote:
> > - if ((fast_pool->count < 64) &&
> > - !time_after(now, fast_pool->last + HZ))
> > - return;
> > -
>
> I suspect you still want the rate-limiting in place. But if you _do_
> want to cheat like thi
> - if ((fast_pool->count < 64) &&
> - !time_after(now, fast_pool->last + HZ))
> - return;
> -
I suspect you still want the rate-limiting in place. But if you _do_
want to cheat like this, you could instead just modify the condition
to only relax the rate limiting whe
Hi!
> What would be useful is if people gave reports that listed exactly
> what laptop and distributions they are using. Just "a high spec x86
> laptop" isn't terribly useful, because *my* brand-new Dell XPS 13
> running Debian testing is working just fine. The year, model, make,
> and CPU type
On Sun, Apr 29, 2018 at 06:05:19PM -0400, Theodore Y. Ts'o wrote:
> It's more accurate to say that using /dev/urandom is no worse than
> before (from a few years ago). There are, alas, plenty of
> distributions and user space application programmers that basically
> got lazy using /dev/urandom, an
On Sun, Apr 29, 2018 at 01:20:33PM -0700, Sultan Alsawaf wrote:
> On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote:
> > Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE
>
> Okay, but /dev/urandom isn't a solution to this problem because it isn't
> usable
> until crng init is compl
On Sun, Apr 29, 2018 at 11:18:55PM +0200, Pavel Machek wrote:
> So -- I'm pretty sure systemd and friends should be using
> /dev/urandom. Maybe gpg wants to use /dev/random. _Maybe_.
>
> [2.948192] random: systemd: uninitialized urandom read (16 bytes
> read)
> [2.953526] systemd[1]: syste
On Sun 2018-04-29 13:20:33, Sultan Alsawaf wrote:
> On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote:
> > Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE
>
> Okay, but /dev/urandom isn't a solution to this problem because it isn't
> usable
> until crng init is complete, so it suf
On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote:
> Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE
Okay, but /dev/urandom isn't a solution to this problem because it isn't usable
until crng init is complete, so it suffers from the same init lag as
/dev/random.
Sultan
On Sun, Apr 29, 2018 at 11:30:57AM -0700, Sultan Alsawaf wrote:
>
> Mind you, this laptop has a 45W CPU, so power savings were definitely not
> considered in its design. Do you have any machines that can provide enough
> boot entropy to satisfy crng init without requiring user-provided entropy?
M
On Sun 2018-04-29 10:05:41, Sultan Alsawaf wrote:
> On Sun, Apr 29, 2018 at 04:32:05PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > This is why ultimately, we do need to attack this problem from both
> > > ends, which means teaching userspace programs to only request
> > > cryptographic-grade rand
I'd also like to add that my high-spec x86 laptop exhibits the same issue as
my Edgar Chromebook.
Here's my dmesg: https://hastebin.com/dofejolobi.go
The most interesting line:
[ 90.811633] random: crng init done
I waited 90 seconds after boot to provide entropy myself, at which point crng
ini
On Sun, Apr 29, 2018 at 04:32:05PM +0200, Pavel Machek wrote:
> Hi!
>
> > This is why ultimately, we do need to attack this problem from both
> > ends, which means teaching userspace programs to only request
> > cryptographic-grade randomness when it is really needed --- and most
> > of the time,
Hi!
> This is why ultimately, we do need to attack this problem from both
> ends, which means teaching userspace programs to only request
> cryptographic-grade randomness when it is really needed --- and most
> of the time, if the user has not logged in yet, you probably don't
> need cryptographic
Hi!
On Thu 2018-04-26 19:56:30, Theodore Y. Ts'o wrote:
> On Thu, Apr 26, 2018 at 01:22:02PM -0700, Sultan Alsawaf wrote:
> >
> > Also, regardless of what's hanging on CRNG init, CRNG should be able to
> > init on its own in a timely
> > manner without the need for user-provided entropy. Userspac
Hi!
> Am 25.04.2018 um 09:41 schrieb Theodore Y. Ts'o:
> >Does this help on your system?
>
> Thank you, after figuring out how to apply the paste, yes it helped on my
> Lenovo X60.
>
> >commit 4e00b339e264802851aff8e73cde7d24b57b18ce
> >Author: Theodore Ts'o
> >Date: Wed Apr 25 01:12:32 2018
> On Thu, Apr 26, 2018 at 10:20:44PM -0700, Sultan Alsawaf wrote:
>> I noted at least 20,000 mmc interrupts before I intervened in the boot
>> process to provide entropy
>> myself. That's just for mmc, so I'm sure there were even more interrupts
>> elsewhere. Is 20k+ interrupts
>> really not suff
On Thu, Apr 26, 2018 at 10:20:44PM -0700, Sultan Alsawaf wrote:
>
> I noted at least 20,000 mmc interrupts before I intervened in the boot
> process to provide entropy
> myself. That's just for mmc, so I'm sure there were even more interrupts
> elsewhere. Is 20k+ interrupts
> really not sufficie
On Fri, Apr 27, 2018 at 05:38:52PM +0200, Jason A. Donenfeld wrote:
>
> Please correct me if I'm wrong, but my present understanding of this
> is that crng readiness used to be broken, meaning people would have a
> seeded rng without it actually being seeded. You fixed this bug, and
> now people a
Hi Ted,
Please correct me if I'm wrong, but my present understanding of this
is that crng readiness used to be broken, meaning people would have a
seeded rng without it actually being seeded. You fixed this bug, and
now people are discovering that they don't have crng readiness during
a late stage
> The CRNG changes were needed because were erroneously saying that the
> entropy pool was securely initialized before it really was. Saying
> that CRNG should be able to init on its own is much like saying, "Ted
> should be able to fly wherever he wants in his own personal Gulfstream
> V." It wo
On Thu, Apr 26, 2018 at 10:47:49PM +0200, Christian Brauner wrote:
>
> We have observed a similiar problem with libvirt. As soon as entropy is
> provided the boot finishes otherwise it hangs for a long time.
> This is not happening with v4.17-rc1 afaict.
For libvirt there is at least an easy wor
On Thu, Apr 26, 2018 at 01:22:02PM -0700, Sultan Alsawaf wrote:
>
> Also, regardless of what's hanging on CRNG init, CRNG should be able to init
> on its own in a timely
> manner without the need for user-provided entropy. Userspace was working fine
> before the recent CRNG
> kernel changes, so
On Thu, Apr 26, 2018 at 01:22:02PM -0700, Sultan Alsawaf wrote:
> > Hmm, it looks like the multiuser startup is getting blocked on snapd:
> >
> > 29.060s snapd.service
> >
> > graphical.target @1min 32.145s
> > └─multi-user.target @1min 32.145s
> > └─hddtemp.service @6.512s +28ms
> >
> Hmm, it looks like the multiuser startup is getting blocked on snapd:
>
> 29.060s snapd.service
>
> graphical.target @1min 32.145s
> └─multi-user.target @1min 32.145s
> └─hddtemp.service @6.512s +28ms
> └─network-online.target @6.508s
> └─NetworkManager-wait-online.service @2
On Thu, Apr 26, 2018 at 08:17:34AM -0700, Sultan Alsawaf wrote:
> > Hmm, can you let the boot hang for a while? It should continue after
> > a few minutes if you wait long enough, but wait a minute or two, then
> > give it entropy so the boot can continue. Then can you use
> > "systemd-analyze bl
> Hmm, can you let the boot hang for a while? It should continue after
> a few minutes if you wait long enough, but wait a minute or two, then
> give it entropy so the boot can continue. Then can you use
> "systemd-analyze blame" or "systemd-analyize critical-chain" and we
> can see what process
On Wed, Apr 25, 2018 at 10:05:55PM -0700, Sultan Alsawaf wrote:
>
> Correct, I'm running Xubuntu 18.04 with my own kernel based off linux-stable.
>
Hmm, can you let the boot hang for a while? It should continue after
a few minutes if you wait long enough, but wait a minute or two, then
give it e
Hi!
> Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called
> from` messages. I believe, this setting should be reverted by default as
> otherwise a lot of other messages are not seen.
>
> Please find my configuration attached.
Same here, thinkpad X60:
[3.163839] systemd
> Thanks for the report!
>
> I assume since you're upgrading your own kernel, you must not be
> running Chrome OS on your Acer CB3-431 Chromebook (Edgar). Are you
> running Chromium --- or some Linux distribution on it?
>
> Thanks,
>
> - Ted
Correct, I'm runn
On Wed, Apr 25, 2018 at 09:11:08PM -0700, Sultan Alsawaf wrote:
> I noticed "systems without sufficient boot randomness" and would like to add
> to this.
>
> With the changes to /dev/random going from 4.16.3 to 4.16.4, my low-spec
> Chromebook does not reach
> the login screen upon boot (it stay
I noticed "systems without sufficient boot randomness" and would like to add to
this.
With the changes to /dev/random going from 4.16.3 to 4.16.4, my low-spec
Chromebook does not reach
the login screen upon boot (it stays stuck on a black screen) until I provide a
source of entropy to
the syste
Dear Theodore,
Am 25.04.2018 um 09:41 schrieb Theodore Y. Ts'o:
Does this help on your system?
Thank you, after figuring out how to apply the paste, yes it helped on
my Lenovo X60.
commit 4e00b339e264802851aff8e73cde7d24b57b18ce
Author: Theodore Ts'o
Date: Wed Apr 25 01:12:32 2018 -040
Does this help on your system?
- Ted
commit 4e00b339e264802851aff8e73cde7d24b57b18ce
Author: Theodore Ts'o
Date: Wed Apr 25 01:12:32 2018 -0400
random: rate limit unseeded randomness warnings
On systems without sufficient boot rando
Dear Theodore,
On 04/24/18 17:49, Theodore Y. Ts'o wrote:
On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote:
On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote:
Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called
from` messages. I believe, this
On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote:
> On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote:
> > Dear Linux folks,
> >
> >
> > Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called
> > from` messages. I believe, this setting should be reverte
On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote:
> Dear Linux folks,
>
> w
> Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called
> from` messages. I believe, this setting should be reverted by default as
> otherwise a lot of other messages are not seen.
Can you t
63 matches
Mail list logo
