linux-kernel - Re: [PATCH] /dev/random: Insufficient of entropy on many architectures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5400101.STbFFoov5a@tauon>
Date:	Tue, 10 Sep 2013 21:47:02 +0200
From:	Stephan Mueller <smueller@...onox.de>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Theodore Ts'o <tytso@....edu>, LKML <linux-kernel@...r.kernel.org>,
	dave.taht@...ferbloat.net
Subject: Re: [PATCH] /dev/random: Insufficient of entropy on many architectures

Am Dienstag, 10. September 2013, 12:38:56 schrieb John Stultz:

Hi John,

>On Tue, Sep 10, 2013 at 4:31 AM, Stephan Mueller <smueller@...onox.de> 
wrote:
>> Hi,
>> 
>> /dev/random uses the get_cycles() function to obtain entropy in
>> addition to jiffies and the event value of hardware events.
>> 
>> Typically the high-resolution timer of get_cycles delivers the
>> majority of entropy, because the event value is quite deterministic
>> and jiffies are very coarse.
>[snip]
>
>> The following patch uses the clocksource clock for a time value in
>> case get_cycles returns 0. As clocksource may not be available
>> during boot time, a flag is introduced which allows random.c to
>> check the availability of clocksource.
>[snip]
>
>> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
>> index 48b9fff..75b1613 100644
>> --- a/kernel/time/timekeeping.c
>> +++ b/kernel/time/timekeeping.c
>> @@ -35,6 +35,7 @@ static struct timekeeper timekeeper;
>> 
>>  static DEFINE_RAW_SPINLOCK(timekeeper_lock);
>>  static seqcount_t timekeeper_seq;
>>  static struct timekeeper shadow_timekeeper;
>> 
>> +static bool timekeeper_enabled = 0;
>> 
>>  /* flag for if timekeeping is suspended */
>>  int __read_mostly timekeeping_suspended;
>> 
>> @@ -833,8 +834,15 @@ void __init timekeeping_init(void)
>> 
>>         write_seqcount_end(&timekeeper_seq);
>>         raw_spin_unlock_irqrestore(&timekeeper_lock, flags);
>> 
>> +       timekeeper_enabled = 1;
>> 
>>  }
>
>So the end of timekeeping_init() may not be what you want here. This
>only means we've started up the timekeping core with only the default
>clocksource (with only few exceptions, this is almost always jiffies).
>Then as clocksource drivers are initialized, they are registered and
>the timekeeping core will switch over to the best available
>clocksource.  Also, to avoid the churn at boot of switching to every
>clocksource registered, we queue them up and wait until fs_init time
>to switch to whatever is the best available then.
>
>So its likely with this patch that the systems all still end up using
>jiffies for their clocksource at least until fs_init time.

Thank you for the explanation. Is there any trigger that is fired at 
fs_init time that one can read?

Thanks
>
>thanks
>-john


Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/