David,
On Tue, 1 Oct 2019, David Laight wrote:
> From: Linus Torvalds
> > Sent: 30 September 2019 17:16
> >
> > On Mon, Sep 30, 2019 at 6:16 AM Theodore Y. Ts'o wrote:
> > >
> > > Which is to say, I'm still worried that people with deep access to the
> > > implementation details of a CPU might b
From: Pavel Machek
> Sent: 09 October 2019 09:03
> > NAND flash requires ECC so is likely to be async.
> > But I2C is clocked from the cpu end - so is fixed.
>
> RTC i2c may be clocked from the CPU end, but the time source needs to
> work when machine is off, so that has a separate crystal for
> ti
Hi!
> > I have many systems including SoC here, but technology needed for NAND
> > flash is different from technology for CPU, so these parts do _not_
> > share a silicon die. They do not even share same package. (Also RTC
> > tends to be on separate chip, connected using i2c).
>
> NAND flash req
From: Pavel Machek
> Sent: 07 October 2019 23:18
..
> I have many systems including SoC here, but technology needed for NAND
> flash is different from technology for CPU, so these parts do _not_
> share a silicon die. They do not even share same package. (Also RTC
> tends to be on separate chip, co
On Mon 2019-10-07 07:47:34, Theodore Y. Ts'o wrote:
> On Sun, Oct 06, 2019 at 08:21:03PM +0200, Pavel Machek wrote:
> > Even without cycle counter... if we _know_ we are trying to generate
> > entropy and have MMC available, we don't care about power and
> > performance.
> >
> > So we can just...
On Sun, Oct 06, 2019 at 08:21:03PM +0200, Pavel Machek wrote:
> Even without cycle counter... if we _know_ we are trying to generate
> entropy and have MMC available, we don't care about power and
> performance.
>
> So we can just...
>
>issue read request on MMC
>while (!interrupt_done)
>
On Sun, Oct 6, 2019 at 11:21 AM Pavel Machek wrote:
>
>
> Even without cycle counter... if we _know_ we are trying to generate
> entropy and have MMC available, we don't care about power and
> performance.
>
> So we can just...
>
>issue read request on MMC
>while (!interrupt_done)
>
On Sun 2019-10-06 11:06:38, Linus Torvalds wrote:
> On Sun, Oct 6, 2019 at 10:35 AM Pavel Machek wrote:
> >
> > It will not: boot is now halted because systemd wants some
> > entropy. Everything is idle and very little interrupts are
> > happening. We have spinning rust, but it is idle, and thus n
On Sun, Oct 6, 2019 at 10:35 AM Pavel Machek wrote:
>
> It will not: boot is now halted because systemd wants some
> entropy. Everything is idle and very little interrupts are
> happening. We have spinning rust, but it is idle, and thus not
> generating any interrupts.
Yes, but we have that probl
On Sun, Oct 6, 2019 at 4:41 AM Pavel Machek wrote:
>
> Should we have some kind of notifier chain, so that we could utilize
> better random sources (spinning rust) if we had them?
The spinning rust will get entropy on its own just thanks to the
regular interrupt stuff. And the kernel tryin gto do
On Sun 2019-10-06 10:26:18, Linus Torvalds wrote:
> On Sun, Oct 6, 2019 at 4:41 AM Pavel Machek wrote:
> >
> > Should we have some kind of notifier chain, so that we could utilize
> > better random sources (spinning rust) if we had them?
>
> The spinning rust will get entropy on its own just than
Hi!
> Entropy really is hard. It's hard to generate, and it's hard to measure.
It is not hard to generate... not on PC, not on most machines. "find
/" can generate plenty of entropy... certainly on any PC.
But it does not work everywhere, and we may need other methods of
generating entropy on so
Hi!
On Sat 2019-09-28 16:53:52, Linus Torvalds wrote:
> On Sat, Sep 28, 2019 at 3:24 PM Thomas Gleixner wrote:
> >
> > Nicholas presented the idea to (ab)use speculative execution for random
> > number generation years ago at the Real-Time Linux Workshop:
>
> What you describe is just a particul
On Tue, Oct 01, 2019 at 06:15:02PM +0200, Ahmed S. Darwish wrote:
>
> Using the "ent" tool, [2] also used to test randomness in the Stephen
> Müller LRNG paper, on a 50-byte file, produced the following
> results:
The "ent" tool is really, really useless. If you take any CRNG, even
intialize
On Tue, Oct 1, 2019 at 9:15 AM Ahmed S. Darwish wrote:
>
> To test the quality of the new jitter code, I added a small patch on
> top to disable all other sources of randomness except the new jitter
> entropy code, [1] and made quick tests on the quality of getrandom(0).
You also need to make sur
On Tue, Oct 01, 2019 at 09:37:39AM -0700, Kees Cook wrote:
> On Tue, Oct 01, 2019 at 06:15:02PM +0200, Ahmed S. Darwish wrote:
> > On Sat, Sep 28, 2019 at 04:53:52PM -0700, Linus Torvalds wrote:
> > > Ahmed - would you be willing to test this on your problem case (with
> > > the ext4 optimization r
On Tue, Oct 1, 2019 at 6:51 AM Borislav Petkov wrote:
>
> So when I add this by hand and do git diff, it adds a second hunk:
You and me both.
We both have editors that always add line-endings, and right now that
file doesn't have a newline at the end of the file thanks to commit
428826f5358c ("f
On Tue, Oct 01, 2019 at 06:15:02PM +0200, Ahmed S. Darwish wrote:
> On Sat, Sep 28, 2019 at 04:53:52PM -0700, Linus Torvalds wrote:
> > Ahmed - would you be willing to test this on your problem case (with
> > the ext4 optimization re-enabled, of course)?
> >
>
> So I pulled the patch and the rever
Hi,
Sorry for the late reply as I'm also on vacation this week :-)
On Sat, Sep 28, 2019 at 04:53:52PM -0700, Linus Torvalds wrote:
> On Sat, Sep 28, 2019 at 3:24 PM Thomas Gleixner wrote:
> >
> > Nicholas presented the idea to (ab)use speculative execution for random
> > number generation years
On Mon, Sep 30, 2019 at 09:06:36AM -0700, Linus Torvalds wrote:
> Obviously, that can be a problem if you then need sshd in order to get
> into a headless box, so my patch fixes things for you too, but at
> least your box doesn't show the problem that Ahmed had, and the boot
> completing presumably
From: Linus Torvalds
> Sent: 30 September 2019 17:16
>
> On Mon, Sep 30, 2019 at 6:16 AM Theodore Y. Ts'o wrote:
> >
> > Which is to say, I'm still worried that people with deep access to the
> > implementation details of a CPU might be able to reverse engineer what
> > a jitter entropy scheme pr
Why not get entropy from the white noise that can be obtained from any
attached ADC? Audio cards, some SBCs, and microcontrollers all have
ADCs.
Not that I'm familiar with when the kernel first needs entropy or an
expert in the field.
Thanks
--
On Mon, Sep 30, 2019 at 08:10:15AM +0200, Borislav Petkov wrote:
> On Sun, Sep 29, 2019 at 07:59:19PM -0700, Linus Torvalds wrote:
> > All my smoke testing looked fine - I disabled trusting the CPU, I
> > increased the required entropy a lot, and to actually trigger the
> > lockup issue without the
On Mon, Sep 30, 2019 at 9:32 AM Peter Zijlstra wrote:
>
> In my experience LFSRs are good at defeating branch predictors, which
> would make even in-order cores suffer lots of branch misses. And that
> might be enough, maybe.
Agreed, branch mis-prediction is likely fairly hard to take into
accoun
On Mon, Sep 30, 2019 at 09:15:55AM -0700, Linus Torvalds wrote:
> On Mon, Sep 30, 2019 at 6:16 AM Theodore Y. Ts'o wrote:
> But it _also_ means that if you have a small and excessively stupid
> in-order CPU, I can almost guarantee that you will at least have cache
> misses likely all the way out
On Mon, Sep 30, 2019 at 6:16 AM Theodore Y. Ts'o wrote:
>
> Which is to say, I'm still worried that people with deep access to the
> implementation details of a CPU might be able to reverse engineer what
> a jitter entropy scheme produces. This is why I'd be curious to see
> the results when some
On Sun, Sep 29, 2019 at 11:10 PM Borislav Petkov wrote:
>
> so sshd does getrandom(2) while those other userspace things don't. Oh
> well.
Well, that's actually what systems _should_ do. Presumably sshd
actually wants secure randomness, and nothing else waits for it.
Obviously, that can be a pro
On Sun, Sep 29, 2019 at 11:37:06PM -0400, Theodore Y. Ts'o wrote:
> I'm OK with this as a starting point. If a jitter entropy system
> allow us to get pass this logjam, let's do it. At least for the x86
> architecture, it will be security through obscurity. And if the
> alternative is potentiall
On Sun, Sep 29, 2019 at 07:59:19PM -0700, Linus Torvalds wrote:
> All my smoke testing looked fine - I disabled trusting the CPU, I
> increased the required entropy a lot, and to actually trigger the
> lockup issue without the broken user space, I made /dev/urandom do
> that "wait for entropy" thin
On Sun, Sep 29, 2019 at 06:16:33PM -0700, Linus Torvalds wrote:
>
> - or just say "hey, a lot of people find jitter entropy reasonable,
> so let's just try this".
>
I'm OK with this as a starting point. If a jitter entropy system
allow us to get pass this logjam, let's do it. At least for the
On Sun, Sep 29, 2019 at 6:16 PM Linus Torvalds
wrote:
>
> But I've committed that patch and the revert of the ext4 revert to a
> local branch, I'll do some basic testing of it (which honestly on my
> machines are kind of pointless, since all of them support rdrand), but
> assuming it passes the ba
On Sat, Sep 28, 2019 at 4:53 PM Linus Torvalds
wrote:
>
> But hey, here's a made-up patch. It basically does jitter entropy, but
> it uses a more complex load than the fibonacci LFSR folding: it calls
> "schedule()" in a loop, and it sets up a timer to fire.
Ok, I'm sure a lot of people will end
29.09.2019 04:53, Linus Torvalds пишет:
On Sat, Sep 28, 2019 at 3:24 PM Thomas Gleixner wrote:
Nicholas presented the idea to (ab)use speculative execution for random
number generation years ago at the Real-Time Linux Workshop:
What you describe is just a particularly simple version of the j
On Sat, 28 Sep 2019, Linus Torvalds wrote:
> On Sat, Sep 28, 2019 at 3:24 PM Thomas Gleixner wrote:
> >
> > Nicholas presented the idea to (ab)use speculative execution for random
> > number generation years ago at the Real-Time Linux Workshop:
>
> What you describe is just a particularly simple
On Sat, Sep 28, 2019 at 3:24 PM Thomas Gleixner wrote:
>
> Nicholas presented the idea to (ab)use speculative execution for random
> number generation years ago at the Real-Time Linux Workshop:
What you describe is just a particularly simple version of the jitter
entropy. Not very reliable.
But
Nicholas presented the idea to (ab)use speculative execution for random
number generation years ago at the Real-Time Linux Workshop:
https://static.lwn.net/images/conf/rtlws11/random-hardware.pdf
The idea is to use the non-constant execution time of loops on speculative
CPUs. The trick is to "
36 matches
Mail list logo
