lkml.org 
[lkml]   [2006]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 34/35] Add the Xen virtual network device driver.
    On Thu, 11 May 2006 11:47:52 +0200
    Andi Kleen <ak@suse.de> wrote:

    > On Thursday 11 May 2006 09:49, Keir Fraser wrote:
    > > On 11 May 2006, at 01:33, Herbert Xu wrote:
    > > >> But if sampling virtual events for randomness is really unsafe (is it
    > > >> really?) then native guests in Xen would also get bad random numbers
    > > >> and this would need to be somehow addressed.
    > > >
    > > > Good point. I wonder what VMWare does in this situation.
    > >
    > > Well, there's not much they can do except maybe jitter interrupt
    > > delivery. I doubt they do that though.
    > >
    > > The original complaint in our case was that we take entropy from
    > > interrupts caused by other local VMs, as well as external sources.
    > > There was a feeling that the former was more predictable and could form
    > > the basis of an attack. I have to say I'm unconvinced: I don't really
    > > see that it's significantly easier to inject precisely-timed interrupts
    > > into a local VM. Certainly not to better than +/- a few microseconds.
    > > As long as you add cycle-counter info to the entropy pool, the least
    > > significant bits of that will always be noise.
    >
    > I think I agree - e.g. i would expect the virtual interrupts to have
    > enough jitter too. Maybe it would be good if someone could
    > run a few statistics on the resulting numbers?
    >
    > Ok the randomness added doesn't consist only of the least significant
    > bits. Currently it adds jiffies+full 32bit cycle count. I guess if it was
    > a real problem the code could be changed to leave out the jiffies and
    > only add maybe a 8 bit word from the low bits. But that would only
    > help for the para case because the algorithm for native guests
    > cannot be changed.
    >
    > > 2. An entropy front/back is tricky -- how do we decide how much
    > > entropy to pull from domain0? How much should domain0 be prepared to
    > > give other domains? How easy is it to DoS domain0 by draining its
    > > entropy pool? Yuk.
    >
    > I claim (without having read any code) that in theory you need to have solved
    > that problem already in the vTPM @)
    >

    The base question under all this is "how good does an entropy source have
    to be?" and then "what guarantees do we make about the entropy inputs used
    by /dev/random?". If we can resolve those, then the virtual environment
    answer should fall out.

    This is a area where the security tin-foil hat types take over, and it
    gets real hard to make "good enough" argument. People have built an expectation
    that /dev/random has really strong entropy, good enough to generate long term
    keys etc.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-05-11 18:24    [W:4.281 / U:0.260 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site