On 9/10/19 12:21 AM, Ahmed S. Darwish wrote:
> Can this even be considered a user-space breakage? I'm honestly not
> sure. On my modern RDRAND-capable x86, just running rng-tools rngd(8)
> early-on fixes the problem. I'm not sure about the status of older
> CPUs though.
Tangent: I asked aloud on
On 9/10/19 12:21 AM, Ahmed S. Darwish wrote:
> Can this even be considered a user-space breakage? I'm honestly not
> sure. On my modern RDRAND-capable x86, just running rng-tools rngd(8)
> early-on fixes the problem. I'm not sure about the status of older
> CPUs though.
Tangent: I asked aloud on
On Fr, 27.09.19 08:58, Linus Torvalds (torva...@linux-foundation.org) wrote:
> On Fri, Sep 27, 2019 at 6:57 AM Lennart Poettering
> wrote:
> >
> > Doing the random seed in the boot loader is nice for two reasons:
> >
> > 1. It runs very very early, so that the OS can come up with fully
> >
On Fri, Sep 27, 2019 at 6:57 AM Lennart Poettering wrote:
>
> Doing the random seed in the boot loader is nice for two reasons:
>
> 1. It runs very very early, so that the OS can come up with fully
>initialized entropy right from the beginning.
Oh, that part I love.
But I don't believe in
On Mi, 18.09.19 13:26, Linus Torvalds (torva...@linux-foundation.org) wrote:
> On Wed, Sep 18, 2019 at 1:15 PM Alexander E. Patrakov
> wrote:
> >
> > No, this is not the solution, if we take seriously not only getrandom
> > hangs, but also urandom warnings. In some setups (root on LUKS is one of
Hi!
> > => src/random-seed/random-seed.c:
> > /*
> > * Let's make this whole job asynchronous, i.e. let's make
> > * ourselves a barrier for proper initialization of the
> > * random pool.
> > */
...
> > k = getrandom(buf, buf_size, GRND_NONBLOCK);
> > if (k
Dear Lennart.
Lennart Poettering - 18.09.19, 15:53:25 CEST:
> On Mi, 18.09.19 00:10, Martin Steigerwald (mar...@lichtvoll.de) wrote:
> > > getrandom() will never "consume entropy" in a way that will block
> > > any
> > > users of getrandom(). If you don't have enough collected entropy
> > > to
>
On Wed, Sep 18, 2019 at 01:26:39PM -0700, Linus Torvalds wrote:
> Of course, even then people will say "I don't trust the platform". But
> at some point you just say "you have trust issues" and move on.
It's where our extreme configurability can hurt. Sometimes we'd rather
avoid providing some of
On Wed, Sep 18, 2019 at 1:15 PM Alexander E. Patrakov
wrote:
>
> No, this is not the solution, if we take seriously not only getrandom
> hangs, but also urandom warnings. In some setups (root on LUKS is one of
> them) they happen early in the initramfs. Therefore "restoring" entropy
> from the
19.09.2019 00:56, Eric W. Biederman пишет:
The cheap solution appears to be copying a random seed from a previous
boot, and I think that will take care of many many cases, and has
already been implemented. Which reduces this to a system first
boot issue.
No, this is not the solution, if we
On Wed, Sep 18, 2019 at 12:56 PM Eric W. Biederman
wrote:
>
> The cheap solution appears to be copying a random seed from a previous
> boot, and I think that will take care of many many cases, and has
> already been implemented. Which reduces this to a system first
> boot issue.
Not really.
Lennart Poettering writes:
> On Di, 17.09.19 09:23, Linus Torvalds (torva...@linux-foundation.org) wrote:
>
>> On Tue, Sep 17, 2019 at 9:08 AM Lennart Poettering
>> wrote:
>> >
>> > Here's what I'd propose:
>>
>> So I think this is ok, but I have another proposal. Before I post that
>> one,
On Wed, Sep 18, 2019 at 2:33 AM Rasmus Villemoes
wrote:
>
> And unrelated to the non-use of the RTC (which I agree seems weird), but
> because there's no better place in this thread: How "random" is the
> contents of RAM after boot?
It varies all over the place.
Some machines will most
18.09.2019 18:59, Alexander E. Patrakov пишет:
18.09.2019 18:38, Lennart Poettering пишет:
On Di, 17.09.19 19:29, Willy Tarreau (w...@1wt.eu) wrote:
What do you expect these systems to do though?
I mean, think about general purpose distros: they put together live
images that are supposed to
18.09.2019 18:38, Lennart Poettering пишет:
On Di, 17.09.19 19:29, Willy Tarreau (w...@1wt.eu) wrote:
What do you expect these systems to do though?
I mean, think about general purpose distros: they put together live
images that are supposed to work on a myriad of similar (as in: same
arch)
On Mi, 18.09.19 00:10, Martin Steigerwald (mar...@lichtvoll.de) wrote:
> > getrandom() will never "consume entropy" in a way that will block any
> > users of getrandom(). If you don't have enough collected entropy to
> > seed the rng, getrandom() will block. If you do, getrandom() will
> >
On Di, 17.09.19 23:38, Martin Steigerwald (mar...@lichtvoll.de) wrote:
> (I know that it still with /dev/urandom, so if it is using RDRAND now,
> this may indeed be different, but would it then deplete entropy the CPU
> has available and that by default is fed into the Linux crng as well
> (even
On Di, 17.09.19 19:29, Willy Tarreau (w...@1wt.eu) wrote:
> > What do you expect these systems to do though?
> >
> > I mean, think about general purpose distros: they put together live
> > images that are supposed to work on a myriad of similar (as in: same
> > arch) but otherwise very different
On Wed, Sep 18, 2019 at 03:25:51PM +0500, Alexander E. Patrakov wrote:
> The results so far are:
>
> 1. Desktop with MSI Z87I board: works.
> 2. Lenovo Yoga 2 Pro laptop: works.
> 3. Server based on the Intel Corporation S1200SPL board (available from OVH
> as EG-32): does not work, memory is
18.09.2019 15:16, Willy Tarreau пишет:
We've already discussed that point a few times. The issue is that
bootloaders and/or BIOSes tend to wipe everything. Ideally we should
let the boot loader collect entropy from the DDR training phase since
it's a period where noise is observed. It's also the
On Wed, Sep 18, 2019 at 11:33:39AM +0200, Rasmus Villemoes wrote:
> On 17/09/2019 22.58, Linus Torvalds wrote:
> > Side note, and entirely unrelated to this particular problem, but
> > _because_ I was looking at the entropy init and sources of randomness
> > we have, I notice that we still don't
On 17/09/2019 22.58, Linus Torvalds wrote:
> Side note, and entirely unrelated to this particular problem, but
> _because_ I was looking at the entropy init and sources of randomness
> we have, I notice that we still don't use the ToD clock as a source.
And unrelated to the non-use of the RTC
On Tue, Sep 17, 2019 at 2:52 PM Matthew Garrett wrote:
>
> getrandom() will never "consume entropy" in a way that will block any
> users of getrandom().
Yes, this is true for any common and sane use.
And by that I just mean that we do have GRND_RANDOM, which currently
does exactly that entropy
Matthew Garrett - 17.09.19, 23:52:00 CEST:
> On Tue, Sep 17, 2019 at 11:38:33PM +0200, Martin Steigerwald wrote:
> > My understanding of entropy always has been that only a certain
> > amount of it can be produced in a certain amount of time. If that
> > is wrong… please by all means, please teach
On Tue, Sep 17, 2019 at 11:38:33PM +0200, Martin Steigerwald wrote:
> My understanding of entropy always has been that only a certain amount
> of it can be produced in a certain amount of time. If that is wrong…
> please by all means, please teach me, how it would be.
getrandom() will never
Ahmed S. Darwish - 17.09.19, 22:52:34 CEST:
> On Tue, Sep 17, 2019 at 10:28:47PM +0200, Martin Steigerwald wrote:
> [...]
>
> > I don't have any kernel logs old enough to see whether whether crng
> > init times have been different with Systemd due to asking for
> > randomness for UUID/hashmaps.
>
Side note, and entirely unrelated to this particular problem, but
_because_ I was looking at the entropy init and sources of randomness
we have, I notice that we still don't use the ToD clock as a source.
There's not a whole lot of bits there, but at least one of the attacks
against entirely
On Tue, Sep 17, 2019 at 10:28:47PM +0200, Martin Steigerwald wrote:
[...]
>
> I don't have any kernel logs old enough to see whether whether crng init
> times have been different with Systemd due to asking for randomness for
> UUID/hashmaps.
>
Please stop claiming this. It has been pointed out
Willy Tarreau - 17.09.19, 19:29:29 CEST:
> On Tue, Sep 17, 2019 at 07:13:28PM +0200, Lennart Poettering wrote:
> > On Di, 17.09.19 18:21, Willy Tarreau (w...@1wt.eu) wrote:
> > > On Tue, Sep 17, 2019 at 05:57:43PM +0200, Lennart Poettering
> > > wrote:
> > > > Note that calling getrandom(0) "too
Willy Tarreau - 17.09.19, 18:21:37 CEST:
> On Tue, Sep 17, 2019 at 05:57:43PM +0200, Lennart Poettering wrote:
> > Note that calling getrandom(0) "too early" is not something people
> > do
> > on purpose. It happens by accident, i.e. because we live in a world
> > where SSH or HTTPS or so is run
Linus Torvalds - 17.09.19, 20:01:23 CEST:
> > We can make boot hang in "sane", discoverable way.
>
> That is certainly a huge advantage, yes. Right now I suspect that what
> has happened is that this has probably been going on as some
> low-level background noise for a while, and people either
On Tue, Sep 17, 2019 at 10:42 AM Lennart Poettering
wrote:
>
> So I think people nowadays prefer getrandom() over /dev/urandom
> primarily because of the noisy logging the kernel does when you use
> the latter on a non-initialized pool. If that'd be dropped then I am
> pretty sure that the
On Tue, Sep 17, 2019 at 06:20:02PM +0100, Matthew Garrett wrote:
> AES keys are used for a variety of long-lived purposes (eg, disk
> encryption).
True, good point.
Willy
On Di, 17.09.19 09:23, Linus Torvalds (torva...@linux-foundation.org) wrote:
> On Tue, Sep 17, 2019 at 9:08 AM Lennart Poettering
> wrote:
> >
> > Here's what I'd propose:
>
> So I think this is ok, but I have another proposal. Before I post that
> one, though, I just wanted to point out:
>
> >
17.09.2019 22:32, Willy Tarreau пишет:
On Tue, Sep 17, 2019 at 07:30:36PM +0200, Lennart Poettering wrote:
On Di, 17.09.19 21:58, Alexander E. Patrakov (patra...@gmail.com) wrote:
I am worried that the getrandom delays will be serialized, because processes
sometimes run one after another. If
On Tue, Sep 17, 2019 at 07:30:36PM +0200, Lennart Poettering wrote:
> On Di, 17.09.19 21:58, Alexander E. Patrakov (patra...@gmail.com) wrote:
>
> > I am worried that the getrandom delays will be serialized, because processes
> > sometimes run one after another. If there are enough
On Di, 17.09.19 21:58, Alexander E. Patrakov (patra...@gmail.com) wrote:
> I am worried that the getrandom delays will be serialized, because processes
> sometimes run one after another. If there are enough chained/dependent
> processes that ask for randomness before it is ready, the end result
On Tue, Sep 17, 2019 at 07:13:28PM +0200, Lennart Poettering wrote:
> On Di, 17.09.19 18:21, Willy Tarreau (w...@1wt.eu) wrote:
>
> > On Tue, Sep 17, 2019 at 05:57:43PM +0200, Lennart Poettering wrote:
> > > Note that calling getrandom(0) "too early" is not something people do
> > > on purpose.
On Di, 17.09.19 09:27, Linus Torvalds (torva...@linux-foundation.org) wrote:
> But look at what gnome-shell and gnome-session-b does:
>
> https://lore.kernel.org/linux-ext4/20190912034421.GA2085@darwi-home-pc/
>
> and most of them already set GRND_NONBLOCK, but look at the
> problematic one
On Tue, Sep 17, 2019 at 06:20:02PM +0100, Matthew Garrett wrote:
> AES keys are used for a variety of long-lived purposes (eg, disk
> encryption).
And as an example of when we'd want to do that during early boot - swap
is frequently encrypted with a random key generated on each boot, but
it's
On Tue, Sep 17, 2019 at 07:16:41PM +0200, Willy Tarreau wrote:
> On Tue, Sep 17, 2019 at 05:34:56PM +0100, Matthew Garrett wrote:
> > On Tue, Sep 17, 2019 at 09:27:44AM -0700, Linus Torvalds wrote:
> >
> > > Does anybody believe that 128 bits of randomness is a good basis for a
> > > long-term
On Tue, Sep 17, 2019 at 05:34:56PM +0100, Matthew Garrett wrote:
> On Tue, Sep 17, 2019 at 09:27:44AM -0700, Linus Torvalds wrote:
>
> > Does anybody believe that 128 bits of randomness is a good basis for a
> > long-term secure key?
>
> Yes, it's exactly what you'd expect for an AES 128 key,
On Di, 17.09.19 18:21, Willy Tarreau (w...@1wt.eu) wrote:
> On Tue, Sep 17, 2019 at 05:57:43PM +0200, Lennart Poettering wrote:
> > Note that calling getrandom(0) "too early" is not something people do
> > on purpose. It happens by accident, i.e. because we live in a world
> > where SSH or HTTPS
On Tue, Sep 17, 2019 at 09:27:44AM -0700, Linus Torvalds wrote:
> Does anybody believe that 128 bits of randomness is a good basis for a
> long-term secure key?
Yes, it's exactly what you'd expect for an AES 128 key, which is still
considered to be secure.
--
Matthew Garrett |
17.09.2019 21:27, Linus Torvalds пишет:
On Tue, Sep 17, 2019 at 12:33 AM Martin Steigerwald wrote:
So yes, that would it make it harder to abuse the API, but not
impossible. Which may still be good, I don't know.
So the real problem is not people abusing the ABI per se. Yes, I was a
bit
Am 17.09.19 um 18:23 schrieb Linus Torvalds:
> I do agree that a message is a good idea regardless, but I don't think
> it necessarily solves the problems except for developers
sadly in our current world dvelopers and maintainers don't read any logs
and as long it compiles and boots it works
On Tue, Sep 17, 2019 at 12:33 AM Martin Steigerwald wrote:
>
> So yes, that would it make it harder to abuse the API, but not
> impossible. Which may still be good, I don't know.
So the real problem is not people abusing the ABI per se. Yes, I was a
bit worried about that too, but it's not the
On Tue, Sep 17, 2019 at 9:08 AM Lennart Poettering wrote:
>
> Here's what I'd propose:
So I think this is ok, but I have another proposal. Before I post that
one, though, I just wanted to point out:
> 1) Add GRND_INSECURE to get those users of getrandom() who do not need
>high quality
On Tue, Sep 17, 2019 at 05:57:43PM +0200, Lennart Poettering wrote:
> Note that calling getrandom(0) "too early" is not something people do
> on purpose. It happens by accident, i.e. because we live in a world
> where SSH or HTTPS or so is run in the initrd already, and in a world
> where booting
On Di, 17.09.19 12:30, Ahmed S. Darwish (darwish...@gmail.com) wrote:
> Ideally, systems would be configured with hardware random
> number generators, and/or configured to trust the CPU-provided
> RNG's (CONFIG_RANDOM_TRUST_CPU) or boot-loader provided ones
>
On Di, 17.09.19 08:11, Theodore Y. Ts'o (ty...@mit.edu) wrote:
> On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote:
> > Willy Tarreau - 17.09.19, 07:24:38 CEST:
> > > On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote:
> > > > >Well, the patch actually made
On Mo, 16.09.19 13:21, Theodore Y. Ts'o (ty...@mit.edu) wrote:
> We could create a new flag, GRND_INSECURE, which never blocks. And
> that that allows us to solve the problem for silly applications that
> are using getrandom(2) for non-cryptographic use cases. Use cases
> might include Python
17.09.2019 18:11, Alexander E. Patrakov пишет:
17.09.2019 17:11, Theodore Y. Ts'o пишет:
There are only two ways out of this mess. The first option is we take
functionality away from a userspace author who Really Wants A Secure
Random Number Generator. And there are an awful lot of programs
17.09.2019 17:11, Theodore Y. Ts'o пишет:
There are only two ways out of this mess. The first option is we take
functionality away from a userspace author who Really Wants A Secure
Random Number Generator. And there are an awful lot of programs who
really want secure crypto, becuase this is
On Tue, Sep 17, 2019 at 12:30:15PM +, Ahmed S. Darwish wrote:
> Sounds good?
Sounds good to me except that I'd like to have the option to get
poor randoms. getrandom() is used when /dev/urandom is not accessible
or painful to use. Until we provide applications with a solution to
this fairly
17.09.2019 17:30, Ahmed S. Darwish пишет:
On Tue, Sep 17, 2019 at 08:11:56AM -0400, Theodore Y. Ts'o wrote:
On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote:
Willy Tarreau - 17.09.19, 07:24:38 CEST:
On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote:
Well, the
On Tue, Sep 17, 2019 at 08:11:56AM -0400, Theodore Y. Ts'o wrote:
> On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote:
> > Willy Tarreau - 17.09.19, 07:24:38 CEST:
> > > On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote:
> > > > >Well, the patch actually made
On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote:
> Willy Tarreau - 17.09.19, 07:24:38 CEST:
> > On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote:
> > > >Well, the patch actually made getrandom() return en error too, but
> > > >you seem more interested in the
Willy Tarreau - 17.09.19, 10:35:16 CEST:
> On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote:
> > However this again would be burdening users with an issue they
> > should
> > not have to care about. Unless userspace developers care enough and
> > manage to take time to fix the
On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote:
> However this again would be burdening users with an issue they should
> not have to care about. Unless userspace developers care enough and
> manage to take time to fix the issue before updated kernels come to their
>
Willy Tarreau - 17.09.19, 07:24:38 CEST:
> On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote:
> > >Well, the patch actually made getrandom() return en error too, but
> > >you seem more interested in the hypotheticals than in arguing
> > >actualities.>
> > If you want to be safe,
As this is not about Linux 5.3-rc8 anymore I took the liberty to change
the subject.
Linus Torvalds - 17.09.19, 01:05:47 CEST:
> On Mon, Sep 16, 2019 at 4:02 PM Matthew Garrett
> wrote:
> > The semantics many people want for secure key generation is urandom,
> > but with a g
On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote:
> >Well, the patch actually made getrandom() return en error too, but you
> >seem more interested in the hypotheticals than in arguing actualities.
>
> If you want to be safe, terminate the process.
This is an interesting approach.
On 16 September 2019 18:41:36 GMT-07:00, Linus Torvalds
wrote:
>On Mon, Sep 16, 2019 at 6:24 PM Matthew Garrett
>wrote:
>>
>> Exactly the scenario where you want getrandom() to block, yes.
>
>It *would* block. Just not forever.
It's already not forever - there's enough running in the
On Mon, Sep 16, 2019 at 6:24 PM Matthew Garrett wrote:
>
> Exactly the scenario where you want getrandom() to block, yes.
It *would* block. Just not forever.
And btw, the whole "generate key at boot when nothing else is going
on" is already broken, so presumably nobody actually does it.
See
On 16 September 2019 18:05:57 GMT-07:00, Linus Torvalds
wrote:
>On Mon, Sep 16, 2019 at 4:29 PM Ahmed S. Darwish
>wrote:
>>
>> Linus, in all honesty, the other case is _not_ a hypothetical .
>
>Oh yes it is.
>
>You're confusing "use" with "breakage".
>
>The _use_ of getrandom(0) for key
On Mon, Sep 16, 2019 at 4:29 PM Ahmed S. Darwish wrote:
>
> Linus, in all honesty, the other case is _not_ a hypothetical .
Oh yes it is.
You're confusing "use" with "breakage".
The _use_ of getrandom(0) for key generation isn't hypothetical.
But the _breakage_ from the suggested patch that
On 16 September 2019 16:18:00 GMT-07:00, Linus Torvalds
wrote:
>On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett
>wrote:
>>
>> In one case we have "Systems don't boot, but you can downgrade your
>> kernel" and in the other case we have "Your cryptographic keys are
>weak
>> and you have no way of
On 16 September 2019 16:18:00 GMT-07:00, Linus Torvalds
wrote:
>On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett
>wrote:
>>
>> In one case we have "Systems don't boot, but you can downgrade your
>> kernel" and in the other case we have "Your cryptographic keys are
>weak
>> and you have no way of
On Mon, Sep 16, 2019 at 10:44:31AM -0700, Linus Torvalds wrote:
> - admit that the current situation actually causes problems, and has
> _existing_ bugs.
>
> - throw it out the window, with the timeout and big BIG warning when
> the problem cases trigger
The semantics many people want for
On Mon, Sep 16, 2019 at 04:18:00PM -0700, Linus Torvalds wrote:
> On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett wrote:
> >
> > In one case we have "Systems don't boot, but you can downgrade your
> > kernel" and in the other case we have "Your cryptographic keys are weak
> > and you have no way
On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett wrote:
>
> In one case we have "Systems don't boot, but you can downgrade your
> kernel" and in the other case we have "Your cryptographic keys are weak
> and you have no way of knowing unless you read dmesg", and I think
> causing boot problems is
On Tue, Sep 17, 2019 at 04:13:36AM +0500, Alexander E. Patrakov wrote:
> 17.09.2019 04:11, Matthew Garrett пишет:
> > In one case we have "Systems don't boot, but you can downgrade your
> > kernel"
>
> You can't. There are way too many dedicated server providers where there is
> no IPMI or any
17.09.2019 04:11, Matthew Garrett пишет:
In one case we have "Systems don't boot, but you can downgrade your
kernel"
You can't. There are way too many dedicated server providers where there
is no IPMI or any equivalent, and the only help that the staff can do is
to reinstall, wiping your
On Mon, Sep 16, 2019 at 04:05:47PM -0700, Linus Torvalds wrote:
> On Mon, Sep 16, 2019 at 4:02 PM Matthew Garrett wrote:
> > Changing the default (even with kernel warnings) seems like
> > it risks people generating keys from an unseeded prng, and that seems
> > like a bad thing?
>
> I agree
On Mon, Sep 16, 2019 at 4:02 PM Matthew Garrett wrote:
>
> The semantics many people want for secure key generation is urandom, but
> with a guarantee that it's seeded.
And that is exactly what I'd suggest GRND_SECURE should do.
The problem with:
> getrandom()'s default behaviour at present
On Mon, Sep 16, 2019 at 01:21:17PM -0400, Theodore Y. Ts'o wrote:
> On Mon, Sep 16, 2019 at 09:17:10AM -0700, Linus Torvalds wrote:
> > So the semantics that getrandom() should have had are:
> >
> > getrandom(0) - just give me reasonable random numbers for any of a
> > million
On Mon, Sep 16, 2019 at 10:44:31AM -0700, Linus Torvalds wrote:
> - add new GRND_SECURE and GRND_INSECURE flags that have the actual
> useful behaviors that we currently pretty much lack
>
> - consider the old 0-3 flag values legacy, deprecated, and unsafe
> because they _will_ time out to fix
16.09.2019 22:21, Theodore Y. Ts'o пишет:
On Mon, Sep 16, 2019 at 09:17:10AM -0700, Linus Torvalds wrote:
So the semantics that getrandom() should have had are:
getrandom(0) - just give me reasonable random numbers for any of a
million non-strict-long-term-security use (ie the old urandom)
> - add new GRND_SECURE and GRND_INSECURE flags that have the actual
> useful behaviors that we currently pretty much lack
>
> - consider the old 0-3 flag values legacy, deprecated, and unsafe
> because they _will_ time out to fix the existing problem we have right
> now because of their bad
On Mon, Sep 16, 2019 at 10:21 AM Theodore Y. Ts'o wrote:
>
> We could create a new flag, GRND_INSECURE, which never blocks. And
> that that allows us to solve the problem for silly applications that
> are using getrandom(2) for non-cryptographic use cases.
Note that getting "reasonably good
On Mon, Sep 16, 2019 at 09:17:10AM -0700, Linus Torvalds wrote:
> So the semantics that getrandom() should have had are:
>
> getrandom(0) - just give me reasonable random numbers for any of a
> million non-strict-long-term-security use (ie the old urandom)
>
> - the nonblocking flag makes
On Mon, Sep 16, 2019 at 10:00 AM Theodore Y. Ts'o wrote:
>
> How /dev/random blocks is very different from how getrandom(2) blocks.
> Getrandom(2) blocks until the CRNG, and then it never blocks again.
Yes and no.
getrandom() very much blocks exactly like /dev/random, when you give
it the
On Sun, Sep 15, 2019 at 08:40:30PM -0700, Linus Torvalds wrote:
> On Sun, Sep 15, 2019 at 8:23 PM Theodore Y. Ts'o wrote:
> >
> > But not blocking is *precisely* what lead us to weak keys in network
> > devices that were sold by the millions to users in their printers,
> > wifi routers, etc.
>
>
On Sun, Sep 15, 2019 at 11:13 PM Willy Tarreau wrote:
>
> >
> > So three out of four flag combinations end up being mostly "don't
> > use", and the fourth one isn't what you'd normally want (which is just
> > plain /dev/urandom semantics).
>
> I'm seeing it from a different angle. I now
On Tue, Sep 10, 2019 at 07:56:35AM -0400, Theodore Y. Ts'o wrote:
> Hmm, I'm not seeing this on a Dell XPS 13 (model 9380) using a Debian
> Bullseye (Testing) running a rc4+ kernel.
>
> This could be because Debian is simply doing more I/O; or it could be
> because I don't have some package
On Sun, Sep 15, 2019 at 10:02:02PM -0700, Linus Torvalds wrote:
> On Sun, Sep 15, 2019 at 9:30 PM Willy Tarreau wrote:
> >
> > I'd be in favor of adding in the man page something like "this
> > random source is only suitable for applications which will not be
> > harmed by getting a predictable
On Sun, Sep 15, 2019 at 9:30 PM Willy Tarreau wrote:
>
> I'd be in favor of adding in the man page something like "this
> random source is only suitable for applications which will not be
> harmed by getting a predictable value on output, and as such it is
> not suitable for generation of system
On Sun, Sep 15, 2019 at 09:21:06PM -0700, Linus Torvalds wrote:
> The timer interrupt could be somewhat interesting if you are also
> CPU-bound on a non-trivial load, because then "what program counter
> got interrupted" ends up being possibly unpredictable - even with a
> very stable timer
Hi Ted,
On Sun, Sep 15, 2019 at 10:49:04PM -0400, Theodore Y. Ts'o wrote:
> No matter *what* we do, it's going to either (a) make some
> systems insecure, or (b) make some systems more likely hang while
> booting.
I continue to strongly disagree with opposing these two. (b) is
caused precisely
On Sun, Sep 15, 2019 at 8:52 PM Herbert Xu wrote:
>
> Can we perhaps artifically increase the interrupt rate while the
> CRNG is not initialised?
Long term (or even medium term in some areas), the problem really is
that device interrupts during boot really are going away, rather than
becoming
On Sun, Sep 15, 2019 at 8:40 PM Linus Torvalds
wrote:
>
> If you want secure keys, you can't rely on a blocking model, because
> it ends up not working. Blocking leads to problems.
Side note: I'd argue that (despite my earlier mis-understanding) the
only really valid use of "block until there is
Theodore Y. Ts'o wrote:
>
> Ultimately, though, we need to find *some* way to fix userspace's
> assumptions that they can always get high quality entropy in early
> boot, or we need to get over people's distrust of Intel and RDRAND.
> Otherwise, future performance improvements in any part of the
On Sun, Sep 15, 2019 at 8:23 PM Theodore Y. Ts'o wrote:
>
> But not blocking is *precisely* what lead us to weak keys in network
> devices that were sold by the millions to users in their printers,
> wifi routers, etc.
Ted, just admit that you are wrong on this, instead of writing the
above kind
On Sun, Sep 15, 2019 at 6:41 PM Ahmed S. Darwish wrote:
>
> Yes, the systemd-random-seed(8) process blocks, but this is an
> isolated process, and it's only there as a synchronization point and
> to load/restore random seeds from disk across reboots.
>
> What blocked the system boot was
On Sun, Sep 15, 2019 at 10:02:18AM -0700, Linus Torvalds wrote:
> But on a PC, we can _almost_ guarantee entropy. Even with a golden
> image, we do mix in:
>
> - timestamp counter on every device interrupt (but "device interrupt"
> doesn't include things like the local CPU timer, so it really
On Sun, Sep 15, 2019 at 06:48:34PM -0700, Vito Caputo wrote:
> > A small note here, especially after I've just read the commit log of
> > 72dbcf721566 ('Revert ext4: "make __ext4_get_inode_loc plug"'), which
> > unfairly blames systemd there.
...
> > What blocked the system boot was
On Mon, Sep 16, 2019 at 03:40:50AM +0200, Ahmed S. Darwish wrote:
> On Sun, Sep 15, 2019 at 09:29:55AM -0700, Linus Torvalds wrote:
> > On Sat, Sep 14, 2019 at 11:51 PM Lennart Poettering
> > wrote:
> > >
> > > Oh man. Just spend 5min to understand the situation, before claiming
> > > this was
On Sun, Sep 15, 2019 at 09:29:55AM -0700, Linus Torvalds wrote:
> On Sat, Sep 14, 2019 at 11:51 PM Lennart Poettering
> wrote:
> >
> > Oh man. Just spend 5min to understand the situation, before claiming
> > this was garbage or that was garbage. The code above does not block
> > boot.
>
> Yes it
On Sat, Sep 14, 2019 at 11:56 PM Lennart Poettering
wrote:
>
> I am not expecting the kernel to guarantee entropy. I just expecting
> the kernel to not give me garbage knowingly. It's OK if it gives me
> garbage unknowingly, but I have a problem if it gives me trash all the
> time.
So
1 - 100 of 145 matches
Mail list logo
