On Mon, Sep 23, 2019 at 11:33:21AM -0700, Andy Lutomirski wrote:
> On Fri, Sep 20, 2019 at 11:07 PM Florian Weimer wrote:
> >
> > * Linus Torvalds:
> >
> > > Violently agreed. And that's kind of what the GRND_EXPLICIT is really
> > > aiming for.
> > >
> > > However, it's worth noting that nobody
On Fri, Sep 20, 2019 at 11:07 PM Florian Weimer wrote:
>
> * Linus Torvalds:
>
> > Violently agreed. And that's kind of what the GRND_EXPLICIT is really
> > aiming for.
> >
> > However, it's worth noting that nobody should ever use GRND_EXPLICIT
> > directly. That's just the name for the bit. The
From: Linus Torvalds
> Sent: 19 September 2019 21:04
...
> Note small detail above: I changed the ^= to a +=. Addition tends to
> be better (due to carry between bits) when there might be bit
> commonalities. Particularly with something like a cycle count where
> two xors can mostly cancel out
* Linus Torvalds:
> Violently agreed. And that's kind of what the GRND_EXPLICIT is really
> aiming for.
>
> However, it's worth noting that nobody should ever use GRND_EXPLICIT
> directly. That's just the name for the bit. The actual users would use
> GRND_INSECURE or GRND_SECURE.
Should we
On Fri, Sep 20, 2019 at 04:30:20PM -0700, Andy Lutomirski wrote:
> So I think that just improving the
> getrandom()-is-blocking-on-x86-and-arm behavior, adding GRND_INSECURE
> and GRND_SECURE_BLOCKING, and adding the warning if 0 is passed is
> good enough.
I think so as well. Anyway, keep in
On Fri, Sep 20, 2019 at 3:44 PM Linus Torvalds
wrote:
>
> On Fri, Sep 20, 2019 at 1:51 PM Andy Lutomirski wrote:
> >
> > To be clear, when I say "blocking", I mean "blocks until we're ready,
> > but we make sure we're ready in a moderately timely manner".
>
> .. an I want a pony.
>
> The problem
On Fri, Sep 20, 2019 at 1:51 PM Andy Lutomirski wrote:
>
> To be clear, when I say "blocking", I mean "blocks until we're ready,
> but we make sure we're ready in a moderately timely manner".
.. an I want a pony.
The problem is that you start from an assumption that we simply can't
seem to do.
On Fri, Sep 20, 2019 at 12:51 PM Linus Torvalds
wrote:
>
> > And the only real question is how to map existing users to these
> > semantics. I see two sensible choices:
> >
> > 1. 0 means "secure, blocking". I think this is not what we'd do if we
> > could go back in time and chage the ABI from
On Fri, Sep 20, 2019 at 12:51:12PM -0700, Linus Torvalds wrote:
> So we absolutely _will_ come up with some way 0 ends the wait. Whether
> it's _just_ a timeout, or whether it's jitter-entropy or whatever, it
> will happen.
FWIW, Zircon uses the jitter entropy generator to seed the CRNG and
21.09.2019 00:51, Linus Torvalds пишет:
And we'll also have to make getrandom(0) be really _timely_. Security
people would likely rather wait for minutes before they are happy with
it. But because it's a boot constraint as things are now, it will not
just be jitter-entropy, it will be
On Fri, Sep 20, 2019 at 12:22 PM Andy Lutomirski wrote:
>
> Here are some possible approaches that come to mind:
>
> int count;
> while (crng isn't inited) {
> msleep(1);
> }
>
> and modify add_timer_randomness() to at least credit a tiny bit to
> crng_init_cnt.
I'd love that, but we don't
> On Sep 20, 2019, at 12:37 PM, Willy Tarreau wrote:
>
> On Fri, Sep 20, 2019 at 12:22:17PM -0700, Andy Lutomirski wrote:
>> Perhaps userland could register a helper that takes over and does
>> something better?
>
> If userland sees the failure it can do whatever the developer/distro
>
On Fri, Sep 20, 2019 at 12:12 PM Andy Lutomirski wrote:
>
> The problem is that new programs will have to try the new flag value
> and, if it returns -EINVAL, fall back to 0. This isn't so great.
Don't be silly.
Of course they will do that, but so what? With a new kernel, they'll
get the
On Fri, Sep 20, 2019 at 12:22:17PM -0700, Andy Lutomirski wrote:
> Perhaps userland could register a helper that takes over and does
> something better?
If userland sees the failure it can do whatever the developer/distro
packager thought suitable for the system facing this condition.
> But I
On Fri, Sep 20, 2019 at 11:12 AM Willy Tarreau wrote:
>
> Hi Andy,
>
> On Fri, Sep 20, 2019 at 10:52:30AM -0700, Andy Lutomirski wrote:
> > 2. Fix what is arguably a straight up kernel bug, not even an ABI
> > issue: when a user program is blocking in getrandom(..., 0), the
> > kernel happily
> On Sep 20, 2019, at 11:10 AM, Linus Torvalds
> wrote:
>
> On Fri, Sep 20, 2019 at 10:52 AM Andy Lutomirski wrote:
>>
>> IMO, from the beginning, we should have done this:
>>
>> GRND_INSECURE: insecure. always works.
>>
>> GRND_SECURE_BLOCKING: does exactly what it says.
>>
>> 0: -EINVAL.
>
> On Sep 20, 2019, at 11:15 AM, Alexander E. Patrakov
> wrote:
>
> 20.09.2019 22:52, Andy Lutomirski пишет:
>> I think that, given existing software, we should make two or three
>> changes to fix the basic problems here:
>> 1. Add GRND_INSECURE: at least let new applications do the right
On Fri, Sep 20, 2019 at 11:09:53AM -0700, Linus Torvalds wrote:
(...)
> So:
>
> - GRND_INSECURE is (GRND_EXPLICIT | GRND_NONBLOCK)
>
>As in "I explicitly ask you not to just not ever block": urandom
>
> - GRND_SECURE_BLOCKING is (GRND_EXPLICIT | GRND_RANDOM)
>
>As in "I explicitly
20.09.2019 22:52, Andy Lutomirski пишет:
I think that, given existing software, we should make two or three
changes to fix the basic problems here:
1. Add GRND_INSECURE: at least let new applications do the right thing
going forward.
2. Fix what is arguably a straight up kernel bug, not even
Hi Andy,
On Fri, Sep 20, 2019 at 10:52:30AM -0700, Andy Lutomirski wrote:
> 2. Fix what is arguably a straight up kernel bug, not even an ABI
> issue: when a user program is blocking in getrandom(..., 0), the
> kernel happily sits there doing absolutely nothing and deadlocks the
> system as a
On Fri, Sep 20, 2019 at 10:52 AM Andy Lutomirski wrote:
>
> IMO, from the beginning, we should have done this:
>
> GRND_INSECURE: insecure. always works.
>
> GRND_SECURE_BLOCKING: does exactly what it says.
>
> 0: -EINVAL.
Violently agreed. And that's kind of what the GRND_EXPLICIT is really
On Fri, Sep 20, 2019 at 9:30 AM Linus Torvalds
wrote:
>
> On Fri, Sep 20, 2019 at 7:34 AM Andy Lutomirski wrote:
> >
> > What is this GRND_EXPLICIT thing?
>
> Your own email gives the explanation:
>
> > Linus, I disagree that blocking while waiting for randomness is an
> > error. Sometimes you
On Fri, Sep 20, 2019 at 07:26:09PM +0200, Willy Tarreau wrote:
> Hi Ahmed,
>
> On Fri, Sep 20, 2019 at 03:46:09PM +0200, Ahmed S. Darwish wrote:
> > Problem is, glibc is still *really* slow in adopting linux syscall
> > wrappers, so I'm not optimistic about that...
> >
> > I still see the new
Hi Ahmed,
On Fri, Sep 20, 2019 at 03:46:09PM +0200, Ahmed S. Darwish wrote:
> Problem is, glibc is still *really* slow in adopting linux syscall
> wrappers, so I'm not optimistic about that...
>
> I still see the new system call as the sanest path, even provided
> the cost of a new syscall
On Fri, Sep 20, 2019 at 7:34 AM Andy Lutomirski wrote:
>
> What is this GRND_EXPLICIT thing?
Your own email gives the explanation:
> Linus, I disagree that blocking while waiting for randomness is an
> error. Sometimes you want to generate a key
That's *exactly* why GRND_EXPLICIT needs to be
On Fri, Sep 20, 2019 at 6:46 AM Ahmed S. Darwish wrote:
>
> Hi,
>
> On Wed, Sep 18, 2019 at 04:57:58PM -0700, Linus Torvalds wrote:
> > On Wed, Sep 18, 2019 at 2:17 PM Ahmed S. Darwish
> > wrote:
> > >
> > > Since Linux v3.17, getrandom(2) has been created as a new and more
> > > secure
Hi,
On Wed, Sep 18, 2019 at 04:57:58PM -0700, Linus Torvalds wrote:
> On Wed, Sep 18, 2019 at 2:17 PM Ahmed S. Darwish wrote:
> >
> > Since Linux v3.17, getrandom(2) has been created as a new and more
> > secure interface for pseudorandom data requests. It attempted to
> > solve three problems,
On Fri, Sep 20, 2019 at 03:23:58AM +0500, Alexander E. Patrakov wrote:
> OTOH, I thought that at least part of the real entropy, if it exists, comes
> from the interference of the CPU's memory accesses with the refresh cycles
> that are clocked from an independent oscillator.
That's not a valid
On Thu, Sep 19, 2019 at 08:50:15AM -0700, Linus Torvalds wrote:
> .. btw, instead of bad workarounds for a theoretical attack, here's
> something that should add actual *practical* real value: use the time
> of day (whether from an RTC device, or from ntp) to add noise to the
> random pool.
On Thu, Sep 19, 2019 at 08:20:57AM -0700, Linus Torvalds wrote:
> And unlike your theoretical state extension attack, I can point you to
> black hat presentations that literally talk about using the fact that
> we delay m,ixing in the input pull hash to know what's going on:
>
>
>
20.09.2019 03:23, Alexander E. Patrakov пишет:
20.09.2019 02:47, Linus Torvalds пишет:
On Thu, Sep 19, 2019 at 1:45 PM Alexander E. Patrakov
wrote:
This already resembles in-kernel haveged (except that it doesn't credit
entropy), and Willy Tarreau said "collect the small entropy where it is,
20.09.2019 02:47, Linus Torvalds пишет:
On Thu, Sep 19, 2019 at 1:45 PM Alexander E. Patrakov
wrote:
This already resembles in-kernel haveged (except that it doesn't credit
entropy), and Willy Tarreau said "collect the small entropy where it is,
period" today. So, too many people touched upon
On Thu, Sep 19, 2019 at 1:45 PM Alexander E. Patrakov
wrote:
>
> This already resembles in-kernel haveged (except that it doesn't credit
> entropy), and Willy Tarreau said "collect the small entropy where it is,
> period" today. So, too many people touched upon the topic in one day,
> and
20.09.2019 01:04, Linus Torvalds пишет:
instead. Yeah, it still doesn't help on machines that don't even have
a cycle counter, but it at least means that you don't have to have a
CPU rdrand (or equivalent) but you do have a cycle counter, now the
extraction of randomness from the pool doesn't
On Thu, Sep 19, 2019 at 8:20 AM Linus Torvalds
wrote:
>
> Yes, it hashes it using a good hash, but it does so in a way that
> makes it largely possible to follow the hashing and repeat it and
> analyze it.
>
> That breaks if we have hw randomness, because it does the
>
> if
On Thu, Sep 19, 2019 at 8:20 AM Linus Torvalds
wrote:
>
> The silly "reset crng_init_cnt" does absolutely nothing to help that,
> but in fact what it does is to basically give the attacker a way to
> get an infinite stream of data without any reseeding (because that
> only happens after
On Thu, Sep 19, 2019 at 7:34 AM Theodore Y. Ts'o wrote:
>
> > It's basically a "we used up entropy" thing, which is very
> > questionable to begin with as the whole discussion has shown, but
> > since it stops doing it after 10 cases, it's not even good security
> > assuming the "use up entropy"
(Adding linux-api since this patch proposes an API change; both by
changing the existing behavior, and adding new flags and possibly a
new system call.)
On Wed, Sep 18, 2019 at 04:57:58PM -0700, Linus Torvalds wrote:
> On Wed, Sep 18, 2019 at 2:17 PM Ahmed S. Darwish wrote:
> >
> > Since Linux
On Wed, Sep 18, 2019 at 2:17 PM Ahmed S. Darwish wrote:
>
> Since Linux v3.17, getrandom(2) has been created as a new and more
> secure interface for pseudorandom data requests. It attempted to
> solve three problems, as compared to /dev/urandom:
I don't think your patch is really _wrong_, but
39 matches
Mail list logo
