[lkml]   [2002]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Problem with random.c and PPC
    Hello Oliver !!!

    What would you do in my situation. I am dealing with the Motorola MPC860T and
    my system has no disk (I use a flash), no mouse, no keyboard, no PCI bus. It
    has just a fast-ethernet, a console port and some serial ports.

    After reading the discussion on the lkml I realize that the only places I can
    get randomness in my system is in the serial.c (that controls the serial
    ports) and arch/ppc/8xx_io/fec.c (fast eth driver) interrupts.

    What do you think about this solution ???


    My fast ethernet is controlled by processor internal controler (called MII)

    On Friday 16 August 2002 07:52 pm, Oliver Xymoron wrote:
    > On Fri, Aug 16, 2002 at 11:00:00AM +0100, Jon Burgess wrote:
    > > >BTW, does anyone know where I can found the patch to get randomness from
    > > > the network cards interrupt ?
    > >
    > > Add the flag SA_SAMPLE_RANDOM into the request_irq() flags in the driver
    > > for whichever interrupt source you want to use
    > > e.g. from drivers/net/3c523.c
    > >
    > > ret = request_irq(dev->irq, &elmc_interrupt, SA_SHIRQ |
    > > SA_SAMPLE_RANDOM, dev->name, dev);
    > Don't do this. This is the Enron method of entropy accounting.
    > There is little to no reliably unpredictable data in network
    > interrupts and the current scheme does not include for the mixing of
    > untrusted sources. It's very likely that an attacker can measure,
    > model, and control such timings down to the resolution of the PCI bus
    > clock on a quiescent system. This is more than good enough to defeat
    > entropy generation on systems without a TSC and given that the bus
    > clock is a multiple of the processor clock, it's likely possible to
    > extend this to TSC-based systems as well.
    > Entropy accounting is very fickle - if you overestimate _at all_, your
    > secret state becomes theoretically predictable. I have some patches
    > that create an API for adding such hard to predict but potentially
    > observable data to the entropy pool without accounting it as actual
    > entropy, as well as cleaning up some other major accounting errors but
    > I'm not quite done testing them.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:28    [W:0.023 / U:3.496 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site