On 05/27/2014 07:11 AM, Torsten Duwe wrote:
> [checkpatch tells me not to 0-init...]
>
> This patch introduces a derating factor to struct hwrng for
> the random bits going into the kernel input pool, and a common
> default derating for drivers which do not specify one.
>
> Signed-off-by: Torsten Duwe <[email protected]>
>
Did we lose track of this patchset?
-hpa
On Wed, Jun 11, 2014 at 06:24:53PM -0700, H. Peter Anvin wrote:
> On 05/27/2014 07:11 AM, Torsten Duwe wrote:
> > [checkpatch tells me not to 0-init...]
> >
> > This patch introduces a derating factor to struct hwrng for
> > the random bits going into the kernel input pool, and a common
> > default derating for drivers which do not specify one.
> >
> > Signed-off-by: Torsten Duwe <[email protected]>
> >
>
> Did we lose track of this patchset?
Yes. I was already considering a resend.
Torsten
On Thu, Jun 12, 2014 at 12:09:54PM +0200, Torsten Duwe wrote:
> >
> > Did we lose track of this patchset?
>
> Yes. I was already considering a resend.
I've looked it over, and I'm fairly OK with it at this point. Do
folks mind if I just run it through the random tree?
I want to add a tracepoint for better debugging, but I can take care
of that after it's in the random tree.
- Ted
Makes sense to me.
Feel free to add my
Acked-by: H. Peter Anvin <[email protected]>
On June 13, 2014 7:40:50 PM PDT, Theodore Ts'o <[email protected]> wrote:
>On Thu, Jun 12, 2014 at 12:09:54PM +0200, Torsten Duwe wrote:
>> >
>> > Did we lose track of this patchset?
>>
>> Yes. I was already considering a resend.
>
>I've looked it over, and I'm fairly OK with it at this point. Do
>folks mind if I just run it through the random tree?
>
>I want to add a tracepoint for better debugging, but I can take care
>of that after it's in the random tree.
>
> - Ted
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
OK, I've merged these changes into the random.git tree.
I had to make a few minor changes.
1) Changes so it would compile on 3.15. (random_write_wakeup_thresh
got renamed to random_write_wakeup_bits). I'm guessing the patch was
massaged so that it would apply, but it was never compile tested.
2) Fixed a bug in patch #2 so that it would work correctly if the rng
driver doesn't have an init function (which happens to be the case for
the tpm-rng driver, which I used for my testing).
There are also a few minor rough edges that I've noted, but not yet
fixed. The main one is that if you've compiled the hw_random's
rng_core into the kernel, changes to
/sys/modules/rng_core/parameters/* won't actually cause the hwrngd
kerenl thread to get started. You have to set the parameters before
you load the rng module in order for them to be activated. And if
you've compiled the rng module into the kernel, that trick won't work.
Fixing this probably means that we need to set up a formal sysfs tree
under /sys/kernel/hw_random.
- Ted
On Sun, Jun 15, 2014 at 01:11:46AM -0400, Theodore Ts'o wrote:
> OK, I've merged these changes into the random.git tree.
>
> I had to make a few minor changes.
>
> 1) Changes so it would compile on 3.15. (random_write_wakeup_thresh
> got renamed to random_write_wakeup_bits). I'm guessing the patch was
> massaged so that it would apply, but it was never compile tested.
I'm keeping and updating 2 versions, one -current (more or less)
and one for 3.12. I probably missed that when making the discussion changes
back and forth, sorry.
> 2) Fixed a bug in patch #2 so that it would work correctly if the rng
> driver doesn't have an init function (which happens to be the case for
> the tpm-rng driver, which I used for my testing).
The whole thing stems from entropy-challenged s390. 3.12 on s390 compiles
and runs fine. Yields a solid 200 kB/s
TPM RNG is a crook ;-)
> There are also a few minor rough edges that I've noted, but not yet
> fixed. The main one is that if you've compiled the hw_random's
> rng_core into the kernel, changes to
> /sys/modules/rng_core/parameters/* won't actually cause the hwrngd
> kerenl thread to get started. You have to set the parameters before
> you load the rng module in order for them to be activated. And if
> you've compiled the rng module into the kernel, that trick won't work.
With patch 03/03, it is up to the driver author to specify an entropy
quality, which can be overridden at boot time, or when loading
the module, respectively. This should be a constant hardware property.
It would be nice to change it at runtime; but frankly I hope that this
won't be neccessary.
> Fixing this probably means that we need to set up a formal sysfs tree
> under /sys/kernel/hw_random.
Maybe along with more sophisticated steering of how many bits to pick
from which source, if multiple are available.
Thanks,
Torsten
On Mon, Jun 16, 2014 at 09:31:08AM +0200, Torsten Duwe wrote:
> > 2) Fixed a bug in patch #2 so that it would work correctly if the rng
> > driver doesn't have an init function (which happens to be the case for
> > the tpm-rng driver, which I used for my testing).
>
> The whole thing stems from entropy-challenged s390. 3.12 on s390 compiles
> and runs fine. Yields a solid 200 kB/s
>
> TPM RNG is a crook ;-)
I think the word you mean is "crock" (as in "crock of sh*t"?) :-)
Were you referring to the typical hardware implementation in most
TPM's, or something else?
If you're testing on s390, I'd appreciate it if you could give the "dev"
branch on random.git a quick try. It has some improvements to help
deal with "entropy challenged" platforms by using the register values
to be mixed in with everything else. This was based on some
suggestions and work by J?rn Engel.
>From my quick testing on x86 platforms, it doubles the overhead of
add_interrupt_randomness() on platforms that don't have a cycle
counter. It still should be fairly low overhead, but it would be
great if some folks on other architectures did some testing to confirm
that the resulting overhead isn't problematic. (J?rn wanted to mix in
all of the registers, but from my calculations, even if we only did
this once a clock tick, the overhead and resulting long tail latency
in interrupt processing time was not something I was willing to
inflict on everyone.)
Also note if you are playing with the random.git tree, there is a
fairly serious bug fix on the "for_linus_stable" branch that will be
pushed to Linus once it gets a bit more testing.
> With patch 03/03, it is up to the driver author to specify an entropy
> quality, which can be overridden at boot time, or when loading
> the module, respectively. This should be a constant hardware property.
> It would be nice to change it at runtime; but frankly I hope that this
> won't be neccessary.
The question of what should be the proper derating mechanism is going
to be subject to individual administrators. I agree that we should
have good defaults, but for example, I'm sure the manufacturer of the
TPM that's in my Thinkpad would try to claim that it's the Bug
Free(tm), and try to assign it derating factor accordingly. If the
manufacturer is supplying the device driver, it may not be a value
that other people will agree with. Which is why I think making it
runtime configurable is a good thing.
As another example, I assume Peter or someone else from Intel will be
shortly submitting a hw_random driver for RDRAND on x86. What should
the derating factor be for that? I suspect David Johnson's answer
would be quite different from other people's. And that's to be
expected, since he has much better information that most of us have
access to about the RDRAND implementation, and the
likelihood/possibiliy it could have been subverted.
> > Fixing this probably means that we need to set up a formal sysfs tree
> > under /sys/kernel/hw_random.
>
> Maybe along with more sophisticated steering of how many bits to pick
> from which source, if multiple are available.
Yeah, the question about what to do we have multiple hw random sources
is something that I thought about. Do we want to poll from more than
one?
Also, suppose some hw random sources require more resources ---
battery life in particular, for mobile/laptop devices? How do we deal
with policy questions such as these? Should we deal with it all, or
just assume that userspace will dynamically enable or disable pulling
from certain devices based on policy questions such as power
utilization issues?
Cheers,
- Ted
On Mon, Jun 16, 2014 at 07:22:07AM -0400, Theodore Ts'o wrote:
> On Mon, Jun 16, 2014 at 09:31:08AM +0200, Torsten Duwe wrote:
> > > 2) Fixed a bug in patch #2 so that it would work correctly if the rng
> > > driver doesn't have an init function (which happens to be the case for
> > > the tpm-rng driver, which I used for my testing).
> >
> > The whole thing stems from entropy-challenged s390. 3.12 on s390 compiles
> > and runs fine. Yields a solid 200 kB/s
> >
> > TPM RNG is a crook ;-)
>
> I think the word you mean is "crock" (as in "crock of sh*t"?) :-)
Actually, I was thinking of a crutch. Makes you walk slowly, but better
than nothing. Seems I've bent the wrong tube.
> Were you referring to the typical hardware implementation in most
> TPM's, or something else?
Those are designed for the TPM's own, internal use IIRC. Their exposure
to the main computer is only a side effect.
> > With patch 03/03, it is up to the driver author to specify an entropy
> > quality, which can be overridden at boot time, or when loading
> > the module, respectively. This should be a constant hardware property.
> > It would be nice to change it at runtime; but frankly I hope that this
> > won't be neccessary.
>
> The question of what should be the proper derating mechanism is going
> to be subject to individual administrators. I agree that we should
> have good defaults, but for example, I'm sure the manufacturer of the
> TPM that's in my Thinkpad would try to claim that it's the Bug
> Free(tm), and try to assign it derating factor accordingly. If the
Then the next question would be about the underlying specification.
A bug free implementation of dual-EC DRBG?
> manufacturer is supplying the device driver, it may not be a value
> that other people will agree with. Which is why I think making it
> runtime configurable is a good thing.
Boot time configurable, I'd say. Again: this is a hardware property,
multiplied by the admin's level of confidence in the absence of backdoors.
It's easy with s390: from z/VM you can read all the guest's memory anyway.
If you use this machine, you already trust IBM.
> As another example, I assume Peter or someone else from Intel will be
> shortly submitting a hw_random driver for RDRAND on x86. What should
> the derating factor be for that? I suspect David Johnson's answer
> would be quite different from other people's. And that's to be
> expected, since he has much better information that most of us have
> access to about the RDRAND implementation, and the
> likelihood/possibiliy it could have been subverted.
So let's keep it close to 0, and allow those to raise it who have confidence.
> > Maybe along with more sophisticated steering of how many bits to pick
> > from which source, if multiple are available.
>
> Yeah, the question about what to do we have multiple hw random sources
> is something that I thought about. Do we want to poll from more than
> one?
Of course! Choose your mix!
> Also, suppose some hw random sources require more resources ---
> battery life in particular, for mobile/laptop devices? How do we deal
> with policy questions such as these? Should we deal with it all, or
> just assume that userspace will dynamically enable or disable pulling
> from certain devices based on policy questions such as power
> utilization issues?
One thing after the other. What are the consumers of kernel entropy?
Mostly ASLR, I guess, and the web server / sshd accepting connections.
Those proceses starting probably eats more power than a HWRNG needs for
the appropriate random bits. We can address exceptions once they arise.
Torsten
On Mon, Jun 16, 2014 at 04:07:19PM +0200, Torsten Duwe wrote:
> > > TPM RNG is a crook ;-)
> >
> > I think the word you mean is "crock" (as in "crock of sh*t"?) :-)
>
> Actually, I was thinking of a crutch. Makes you walk slowly, but better
> than nothing. Seems I've bent the wrong tube.
Heh. One of the things that I have considered, especially for TPM, is
that in addition to having a very small quality rating, we should also
have some kind of delay so that we sleep some small amount time before
we pull from the TPM again.
Otherwise the result of using a very small quality rating is that we
end up pounding on the TPM a huge amount until the entropy pool is
above the write_wakeup threshold. If there's some "real" use of the
TPM, such as authenticating to a wireless network, or some such, I'd
rather not be constantly pounding on the TPM if so happens that there
is a heavy drain on /dev/random at the same time that Network Manager
needs to reauthenticate to the 802.1x network.
> > manufacturer is supplying the device driver, it may not be a value
> > that other people will agree with. Which is why I think making it
> > runtime configurable is a good thing.
>
> Boot time configurable, I'd say. Again: this is a hardware property,
> multiplied by the admin's level of confidence in the absence of backdoors.
> It's easy with s390: from z/VM you can read all the guest's memory anyway.
> If you use this machine, you already trust IBM.
Sure, but I guess I'm a bit allergic to gazillions of boot
command-line parameters. I guess if you are building a modular
kernel, this matters a lot less, since you can put the configs in
/etc/modprobe.d.
- Ted