All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Babis Chalios <bchalios@amazon.es>
Cc: Olivia Mackall <olivia@selenic.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Theodore Ts'o <tytso@mit.edu>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, graf@amazon.de,
	xmarcalx@amazon.co.uk, aams@amazon.de, dwmw@amazon.co.uk
Subject: Re: [RFC PATCH 1/2] random: emit reseed notifications for PRNGs
Date: Wed, 23 Aug 2023 11:08:05 +0200	[thread overview]
Message-ID: <2023082322-semester-heave-e5bc@gregkh> (raw)
In-Reply-To: <20230823090107.65749-2-bchalios@amazon.es>

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?

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Babis Chalios <bchalios@amazon.es>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	graf@amazon.de, Theodore Ts'o <tytso@mit.edu>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	xmarcalx@amazon.co.uk, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	linux-crypto@vger.kernel.org, Olivia Mackall <olivia@selenic.com>,
	aams@amazon.de, dwmw@amazon.co.uk
Subject: Re: [RFC PATCH 1/2] random: emit reseed notifications for PRNGs
Date: Wed, 23 Aug 2023 11:08:05 +0200	[thread overview]
Message-ID: <2023082322-semester-heave-e5bc@gregkh> (raw)
In-Reply-To: <20230823090107.65749-2-bchalios@amazon.es>

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?

thanks,

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

  reply	other threads:[~2023-08-23  9:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-23  9:01 [RFC PATCH 0/2] Propagating reseed notifications to user space Babis Chalios
2023-08-23  9:01 ` [RFC PATCH 1/2] random: emit reseed notifications for PRNGs Babis Chalios
2023-08-23  9:08   ` Greg KH [this message]
2023-08-23  9:08     ` Greg KH
2023-08-23  9:27     ` Babis Chalios
2023-08-23 10:06       ` Greg KH
2023-08-23 10:06         ` Greg KH
     [not found]         ` <89ce1064-e4a3-461f-8a78-88e72e5b6419@amazon.es>
2023-08-23 10:20           ` Alexander Graf
2023-08-23 10:25           ` Greg KH
2023-08-23 10:25             ` Greg KH
2023-08-23 10:37             ` Alexander Graf
2023-08-23  9:01 ` [RFC PATCH 2/2] virtio-rng: implement entropy leak feature Babis Chalios
2023-09-04 13:44 ` [RFC PATCH 0/2] Propagating reseed notifications to user space Babis Chalios
2023-09-04 14:42   ` Jason A. Donenfeld
2023-09-04 14:54     ` Babis Chalios
2023-09-06 14:25     ` Alexander Graf
2023-09-17 13:34 ` Yann Droneaud
2023-09-18  8:32   ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2023082322-semester-heave-e5bc@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=Jason@zx2c4.com \
    --cc=aams@amazon.de \
    --cc=bchalios@amazon.es \
    --cc=dwmw@amazon.co.uk \
    --cc=graf@amazon.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=jasowang@redhat.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=olivia@selenic.com \
    --cc=tytso@mit.edu \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xmarcalx@amazon.co.uk \
    --cc=xuanzhuo@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.