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

On Wed, Aug 23, 2023 at 12:08:35PM +0200, Babis Chalios wrote:

On 23/8/23 12:06, Greg KH wrote:

quoted

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:

quoted

Hi Greg,

On 23/8/23 11:08, Greg KH wrote:

quoted

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:

quoted

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.

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

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.

greg k-h
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization