lkml.org 
[lkml]   [2017]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: early x86 unseeded randomness
    On Tue, Aug 15, 2017 at 03:48:18PM +0200, Thomas Gleixner wrote:
    > > > +u64 __init tsc_early_random(void)
    > > > +{
    > > > + u64 uninitialized_var(res);
    > > > + int i;
    > > > +
    > > > + if (!boot_cpu_has(X86_FEATURE_TSC))
    > > > + return res;
    > > > +
    > > > + res ^= rdtsc();
    > > > + for (i = 0; i < BITS_PER_LONG; i++) {
    > > > + res ^= ((rdtsc() & 0x04) >> 2) << i;
    > > > + udelay(2);
    > > > + }
    > > > + return res;
    > > > +}

    Reasons why this is probably not the best idea:

    1) Exactly how udelay is implemented varies from architecture to
    architecture and in some cases is different on a subarchitectural
    level. Some of them rely on reading the TSC; others rely on
    operations that will have a constant number of CPU cycles (e.g., they
    aren't doing much if any operations that might even have a tiny
    glimmer of hope of adding unpredictability).

    2) Given a dozen numbers and saying, "hmm, my human brain doesn't see
    a problem, it *must* be good" is hardly the basis on which to make
    this kind of security design. If you don't understand why this is a
    bad idea, and can't come up with a counter example in under 5 seconds,
    you probably aren't qualified to be designing a RNG which is supposed
    to be cryptographically secure.

    3) Depending on when you use this function in early boot, udelay()
    might not even have been calibrated yet.

    4) As as standalone function, it doesn't take advantage of whatever
    randomness might have been available; and if it turns out that the
    tsc_early_random() is trivially predictable by someone spends more
    time analyizing it for particular target architectures, it could be
    disastrous

    5) If you use this in addition to the existing get_random_u32(), it
    won't hurt from a cryptographic perspective, but it will end up
    burning 64-128 microseconds (or potentially more, depending on how
    udelay is implemented on the architecture/subarch and whether udelay
    has been calibrated yet). And it's not clear it's really better(tm).

    6) It would be the ultimate in irony if Jason, who tried so hard to
    get this warning in because he hoped it would make Linux more secure,
    actually ends up making Linux *less* secure because something like
    this starts getting used....

    - Ted

    \
     
     \ /
      Last update: 2017-08-15 16:27    [W:2.094 / U:0.628 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site