linux-kernel - Re: [RFC PATCH 1/2] random: emit reseed notifications for PRNGs

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] [day] [month] [year] [list]

Message-ID: <b8744eea-c9bb-4d46-9b1a-1437cf1f098c@amazon.de>
Date:   Wed, 23 Aug 2023 12:37:18 +0200
From:   Alexander Graf <graf@...zon.de>
To:     Greg KH <gregkh@...uxfoundation.org>,
        Babis Chalios <bchalios@...zon.es>
CC:     Olivia Mackall <olivia@...enic.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Theodore Ts'o <tytso@....edu>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        "Jason Wang" <jasowang@...hat.com>,
        Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
        <linux-crypto@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <virtualization@...ts.linux-foundation.org>,
        <xmarcalx@...zon.co.uk>, <aams@...zon.de>, <dwmw@...zon.co.uk>
Subject: Re: [RFC PATCH 1/2] random: emit reseed notifications for PRNGs


On 23.08.23 12:25, Greg KH wrote:
> On Wed, Aug 23, 2023 at 12:08:35PM +0200, Babis Chalios wrote:
>>
>> On 23/8/23 12:06, Greg KH wrote:
>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>>
>>>
>>>
>>> On Wed, Aug 23, 2023 at 11:27:11AM +0200, Babis Chalios wrote:
>>>> Hi Greg,
>>>>
>>>> On 23/8/23 11:08, Greg KH wrote:
>>>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 23, 2023 at 11:01:05AM +0200, Babis Chalios wrote:
>>>>>> Sometimes, PRNGs need to reseed. For example, on a regular timer
>>>>>> interval, to ensure nothing consumes a random value for longer than e.g.
>>>>>> 5 minutes, or when VMs get cloned, to ensure seeds don't leak in to
>>>>>> clones.
>>>>>>
>>>>>> The notification happens through a 32bit epoch value that changes every
>>>>>> time cached entropy is no longer valid, hence PRNGs need to reseed. User
>>>>>> space applications can get hold of a pointer to this value through
>>>>>> /dev/(u)random. We introduce a new ioctl() that returns an anonymous
>>>>>> file descriptor. From this file descriptor we can mmap() a single page
>>>>>> which includes the epoch at offset 0.
>>>>>>
>>>>>> random.c maintains the epoch value in a global shared page. It exposes
>>>>>> a registration API for kernel subsystems that are able to notify when
>>>>>> reseeding is needed. Notifiers register with random.c and receive a
>>>>>> unique 8bit ID and a pointer to the epoch. When they need to report a
>>>>>> reseeding event they write a new epoch value which includes the
>>>>>> notifier ID in the first 8 bits and an increasing counter value in the
>>>>>> remaining 24 bits:
>>>>>>
>>>>>>                  RNG epoch
>>>>>> *-------------*---------------------*
>>>>>> | notifier id | epoch counter value |
>>>>>> *-------------*---------------------*
>>>>>>         8 bits           24 bits
>>>>> Why not just use 32/32 for a full 64bit value, or better yet, 2
>>>>> different variables?  Why is 32bits and packing things together here
>>>>> somehow simpler?
>>>> We made it 32 bits so that we can read/write it atomically in all 32bit
>>>> architectures.
>>>> Do you think that's not a problem?
>>> What 32bit platforms care about this type of interface at all?
>> I think, any 32bit platform that gets random bytes from the kernel.
> You are making a new api, for some new functionality, for what I thought
> was virtual machines (hence the virtio driver), none of which work in a
> 32bit system.


There should be 2 use cases of this that I'm aware of:

   * Virtual machine clones. Most 64bit VMs can execute 32bit user space.
   * Bare metal rng time-to-live. An easy mechanism to tell every PRNG 
in the system to reseed every 5 minutes. This applies to all 
architectures Linux supports.


> I thought this was an ioctl for userspace, which can handle 64bits at
> once (or 2 32bit numbers).


The ioctl is only to create a file descriptor that you can use to mmap() 
a shared page between kernel and user space which you can then 
atomically access to understand if you're in the old epoch (keep using 
previous RNG values) or in the new epoch (discard any old cached RNG 
values).


> For internal kernel stuff, a lock should be fine, or better yet, a 64bit
> atomic value read (horrible on 32bit platforms, I know...)
>
> Just asking, it feels odd to pack bits in these days for when 90% of the
> cpus really don't need it.


I agree, but we're really not really bit constrained for this value and 
by making it 32bit always, we can guarantee that there will never be 
muckery for 32-on-64 compatibility.


Alex





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879