Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1423196 > unrolled thread

Re: [PATCH v4 0/5] /dev/random - a new approach

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 0/5] /dev/random - a new approach David Jaša <djasa@redhat.com> - 2016-06-15 18:20 +0200
    Re: [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-06-15 19:00 +0200
      Re: [PATCH v4 0/5] /dev/random - a new approach David Jaša <djasa@redhat.com> - 2016-06-17 16:00 +0200
        Re: [PATCH v4 0/5] /dev/random - a new approach Sandy Harris <sandyinchina@gmail.com> - 2016-06-17 17:30 +0200
          Re: [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-06-18 10:30 +0200
        Re: [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-06-18 10:30 +0200
        Re: [PATCH v4 0/5] /dev/random - a new approach Theodore Ts'o <tytso@mit.edu> - 2016-06-18 16:50 +0200
          Re: [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-06-18 18:40 +0200
            Re: [PATCH v4 0/5] /dev/random - a new approach "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-06-20 19:40 +0200
              Re: [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-06-20 20:40 +0200
                Re: [PATCH v4 0/5] /dev/random - a new approach "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-06-21 15:10 +0200
                  Re: [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-06-21 15:30 +0200
                    Re: [PATCH v4 0/5] /dev/random - a new approach "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-06-21 20:00 +0200
                      Re: [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-06-21 20:10 +0200
                        Re: [PATCH v4 0/5] /dev/random - a new approach "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-06-21 21:40 +0200
                          Re: [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-06-22 07:20 +0200
                            Re: [PATCH v4 0/5] /dev/random - a new approach "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-06-22 15:00 +0200
                              Re: [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-06-22 15:30 +0200
                  Re: [PATCH v4 0/5] /dev/random - a new approach Tomas Mraz <tmraz@redhat.com> - 2016-06-21 15:30 +0200
                    Re: [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-06-21 19:30 +0200
                      Re: [PATCH v4 0/5] /dev/random - a new approach "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-06-21 20:00 +0200
                        Re: [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-06-21 20:10 +0200
                    Re: [PATCH v4 0/5] /dev/random - a new approach "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-06-21 20:30 +0200
                  Re: [PATCH v4 0/5] /dev/random - a new approach Pavel Machek <pavel@ucw.cz> - 2016-06-21 15:50 +0200
                    Re: [PATCH v4 0/5] /dev/random - a new approach "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-06-21 19:20 +0200
          Re: [PATCH v4 0/5] /dev/random - a new approach David Jaša <djasa@redhat.com> - 2016-06-21 14:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1428021

On 2016-06-21 13:23, Stephan Mueller wrote:
> Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn:
>
> Hi Austin,
>
>>> You have to trust the host for anything, not just for the entropy in
>>> timings. This is completely invalid argument unless you can present a
>>> method that one guest can manipulate timings in other guest in such a
>>> way that _removes_ the inherent entropy from the host.
>>
>> When dealing with almost any type 2 hypervisor, it is fully possible for
>> a user other than the one running the hypervisor to manipulate
>> scheduling such that entropy is reduced.  This does not imply that the
>
> Please re-read the document: Jitter RNG does not rest on scheduling.
If you are running inside a VM, your interrupt timings depend on the 
hpyervisor's scheduling, period.  You may not directly rely on 
scheduling from the OS you are running on, but if you are doing anything 
timing related in a VM, you are at the mercy of the scheduling used by 
the hypervisor and whatever host OS that may be running on.

In the attack I"m describing, the malicious user is not manipulating the 
guest OS's scheduling, they are manipulating the host system's scheduling.

[toc] | [prev] | [next] | [standalone]

#1428035

Am Dienstag, 21. Juni 2016, 13:54:13 schrieb Austin S. Hemmelgarn:

Hi Austin,

> On 2016-06-21 13:23, Stephan Mueller wrote:
> > Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn:
> > 
> > Hi Austin,
> > 
> >>> You have to trust the host for anything, not just for the entropy in
> >>> timings. This is completely invalid argument unless you can present a
> >>> method that one guest can manipulate timings in other guest in such a
> >>> way that _removes_ the inherent entropy from the host.
> >> 
> >> When dealing with almost any type 2 hypervisor, it is fully possible for
> >> a user other than the one running the hypervisor to manipulate
> >> scheduling such that entropy is reduced.  This does not imply that the
> > 
> > Please re-read the document: Jitter RNG does not rest on scheduling.
> 
> If you are running inside a VM, your interrupt timings depend on the

The RNG does not rest on interrupts either.

> hpyervisor's scheduling, period.  You may not directly rely on
> scheduling from the OS you are running on, but if you are doing anything
> timing related in a VM, you are at the mercy of the scheduling used by
> the hypervisor and whatever host OS that may be running on.
> 
> In the attack I"m describing, the malicious user is not manipulating the
> guest OS's scheduling, they are manipulating the host system's scheduling.


Ciao
Stephan

[toc] | [prev] | [next] | [standalone]

#1428047

On 2016-06-21 09:19, Tomas Mraz wrote:
> On Út, 2016-06-21 at 09:05 -0400, Austin S. Hemmelgarn wrote:
>> On 2016-06-20 14:32, Stephan Mueller wrote:
>>>
>>> [1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf
>> Specific things I notice about this:
>> 1. QEMU systems are reporting higher values than almost anything
>> else
>> with the same ISA.  This makes sense, but you don't appear to have
>> accounted for the fact that you can't trust almost any of the entropy
>> in
>> a VM unless you have absolute trust in the host system, because the
>> host
>> system can do whatever the hell it wants to you, including
>> manipulating
>> timings directly (with a little patience and some time spent working
>> on
>> it, you could probably get those number to show whatever you want
>> just
>> by manipulating scheduling parameters on the host OS for the VM
>> software).
>
> You have to trust the host for anything, not just for the entropy in
> timings. This is completely invalid argument unless you can present a
> method that one guest can manipulate timings in other guest in such a
> way that _removes_ the inherent entropy from the host.
When dealing with almost any type 2 hypervisor, it is fully possible for 
a user other than the one running the hypervisor to manipulate 
scheduling such that entropy is reduced.  This does not imply that the 
user who is doing this has any other control over the target VM, and 
importantly, often does not require administrative access on the host, 
only regular user access.  Such an attack is very difficult to effect 
outside of a clean-room environment, but is still possible.  You can't 
use this to force generation of arbitrary data, but you can definitely 
starve a VM for entropy.  By nature, something that relies on interrupt 
timings will be more impacted by such an attack than something that does 
not.

In most cases, such an attack will be a DoS attack on the host as well 
(as that's the simplest way to do this).  This is less of an issue with 
proper practices on a type 1 hypervisor, but is still possible there too 
(although pulling this off on at least Xen when you have proper VCPU 
isolation is functionally impossible without administrative access to 
the control domain).

[toc] | [prev] | [next] | [standalone]

#1427771

Hi!

> 6. You have a significant lack of data regarding embedded systems, which is
> one of the two biggest segments of Linux's market share.  You list no
> results for any pre-ARMv6 systems (Linux still runs on and is regularly used
> on ARMv4 CPU's, and it's worth also pointing out that the values on
> the

Feel free to contribute more test results.

I mean... you can't expect every person who wants to improve something
in linux to test on everything in the world... can you?

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1427982

On 2016-06-21 09:42, Pavel Machek wrote:
> Hi!
>
>> 6. You have a significant lack of data regarding embedded systems, which is
>> one of the two biggest segments of Linux's market share.  You list no
>> results for any pre-ARMv6 systems (Linux still runs on and is regularly used
>> on ARMv4 CPU's, and it's worth also pointing out that the values on
>> the
>
> Feel free to contribute more test results.
>
> I mean... you can't expect every person who wants to improve something
> in linux to test on everything in the world... can you?
>
I was commenting less on the lack of results for such systems than on 
attempts to make statements about such systems based on a data-set that 
lacks information about such systems.

[toc] | [prev] | [next] | [standalone]

#1427698

Hi,

On So, 2016-06-18 at 10:44 -0400, Theodore Ts'o wrote:
> On Fri, Jun 17, 2016 at 03:56:13PM +0200, David Jaša wrote:
> > I was thinking along the lines that "almost every important package
> > supports FreeBSD as well where they have to handle the condition so
> > option to switch to Rather Break Than Generate Weak Keys would be nice"
> > - but I didn't expect that systemd could be a roadblock here. :-/
> 
> It wasn't just systemd; it also broke OpenWRT and Ubuntu Quantal
> systems from booting.
> 
> > I was also thinking of little devices where OpenWRT or proprietary
> > Linux-based systems run that ended up with predictable keys way too
> > ofter (or as in OpenWRT's case, with cumbersome tutorials how to
> > generate keys elsewhere).
> 
> OpenWRT and other embedded devices (a) generally use a single master
> oscillator to drive everything, and (b) often use RISC architectures
> such as MIPS.
> 
> Which means that arguments of the form ``the Intel L1 / L2 cache
> architecture is ****soooo**** complicated that no human could possibly
> figure out how they would affect timing calculations, and besides, my
> generator passes FIPS 140-2 tests (never mind AES(NSA_KEY, CNTR++)

this

> also passes the FIPS 140-2 statistical tests)'' --- which I normally
> have trouble believing --- are even harder for me to believe.
> 
> At the end of the day, with these devices you really badly need a
> hardware RNG.  

and this.

It seems much easier to me to embed AES(NSA_KEY, CNTR++) logic directly
to HW RNG compared to tweaking of every microarchitecture to make
jitter/maxwell/havege return known numbers that are going to be mixed
with other entropy anyway (won't they?). So if I put the bits together
correctly, HW RNG helps getting more random numbers but itself is
insufficient to ensure that random numbers are truly random...

Cheers,

David Jaša

> We can't generate randomness out of thin air.  The only
> thing you really can do requires user space help, which is to generate
> keys lazily, or as late as possible, so you can gather as much entropy
> as you can --- and to feed in measurements from the WiFi (RSSI
> measurements, MAC addresses seen, etc.)  This won't help much if you
> have an FBI van parked outside your house trying to carry out a
> TEMPEST attack, but hopefully it provides some protection against a
> remote attacker who isn't try to carry out an on-premises attack.
> 
> Cheers,
> 
> 						- Ted

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web