All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Babis Chalios <bchalios@amazon.es>
Cc: virtio-comment@lists.oasis-open.org,
	virtio-dev@lists.oasis-open.org, "Cali,
	Marco" <xmarcalx@amazon.co.uk>, "Graf (AWS),
	Alexander" <graf@amazon.de>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	aams@amazon.de
Subject: Re: [virtio-dev] [PATCH RFC 3/3] rng: leak detection support
Date: Wed, 13 Sep 2023 05:37:27 -0400	[thread overview]
Message-ID: <20230913053707-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <e738e7f0-dd13-44db-806c-543746aa6967@amazon.es>

On Wed, Sep 13, 2023 at 11:32:57AM +0200, Babis Chalios wrote:
> > I do not understand why this matters though. we know there was a leak,
> > why does it matter whether there was one or two leaks?
> >
> > > In the last RFC implementing this in Linux we sent to LKML [1] we avoid
> the
> > > issue by pre-populating both
> > > queues, but that does not solve the problem if a third entropy leak
> event
> > > arrives. The probability of this
> > > happening is indeed small, but we thought of a potential solution to
> this.
> > >
> > > What if we modify the spec here to instruct the VMM to deny taking a
> > > snapshot if there are not any buffers
> > > in the active leak queue? If we did this, we could even simplify the
> spec to
> > > just introduce a single entropy
> > > leak queue, so we could avoid the complexity of switching between active
> > > leak queues in the driver and
> > > the device. WDYT?
> >
> > here's the problem:
> >
> > - driver adds batch 1 of buffers
> > - leak
> > - device starts using buffers from batch 1
> > - driver sees some buffers and starts adding batch 2
> 
> If understand this clause:
> 
> > > +\item Upon detecting that buffers have been used, driver
> > > +      switches to another leak queue making it active
> > > +      (e.g. from \field{leakq1} to \field{leakq2} or vice versa).
> > > +      It then starts adding buffers to the new leak queue.
> 
> correctly:
> 
> At this point, the driver will first switch active leak queue and
> then add batch 2 to the new leak queue.
> 
> and due to this:
> 
> > > +\item Device will keep using buffers in the active leak queue
> > > +      until it detects that both the current leak queue is empty and
> another
> > > +      leak queue has buffers. At that point device switches to
> > > +      another leak queue, making it active.
> > > +\item After the switch, buffers from the new leak queue are not
> > > +      used until an information leak is detected.
> > > +\end{enumerate}
> 
> the following won't happen:
> 
> > - device sees batch 2 and thinks this is part of batch 1
> >    consumes them all
> 
> Does it make sense?
> 
> Cheers,
> Babis

yes, the queue switch is used as a barrier to detect a new leak event.

-- 
MST


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Babis Chalios <bchalios@amazon.es>
Cc: virtio-comment@lists.oasis-open.org,
	virtio-dev@lists.oasis-open.org, "Cali,
	Marco" <xmarcalx@amazon.co.uk>, "Graf (AWS),
	Alexander" <graf@amazon.de>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	aams@amazon.de
Subject: [virtio-comment] Re: [virtio-dev] [PATCH RFC 3/3] rng: leak detection support
Date: Wed, 13 Sep 2023 05:37:27 -0400	[thread overview]
Message-ID: <20230913053707-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <e738e7f0-dd13-44db-806c-543746aa6967@amazon.es>

On Wed, Sep 13, 2023 at 11:32:57AM +0200, Babis Chalios wrote:
> > I do not understand why this matters though. we know there was a leak,
> > why does it matter whether there was one or two leaks?
> >
> > > In the last RFC implementing this in Linux we sent to LKML [1] we avoid
> the
> > > issue by pre-populating both
> > > queues, but that does not solve the problem if a third entropy leak
> event
> > > arrives. The probability of this
> > > happening is indeed small, but we thought of a potential solution to
> this.
> > >
> > > What if we modify the spec here to instruct the VMM to deny taking a
> > > snapshot if there are not any buffers
> > > in the active leak queue? If we did this, we could even simplify the
> spec to
> > > just introduce a single entropy
> > > leak queue, so we could avoid the complexity of switching between active
> > > leak queues in the driver and
> > > the device. WDYT?
> >
> > here's the problem:
> >
> > - driver adds batch 1 of buffers
> > - leak
> > - device starts using buffers from batch 1
> > - driver sees some buffers and starts adding batch 2
> 
> If understand this clause:
> 
> > > +\item Upon detecting that buffers have been used, driver
> > > +      switches to another leak queue making it active
> > > +      (e.g. from \field{leakq1} to \field{leakq2} or vice versa).
> > > +      It then starts adding buffers to the new leak queue.
> 
> correctly:
> 
> At this point, the driver will first switch active leak queue and
> then add batch 2 to the new leak queue.
> 
> and due to this:
> 
> > > +\item Device will keep using buffers in the active leak queue
> > > +      until it detects that both the current leak queue is empty and
> another
> > > +      leak queue has buffers. At that point device switches to
> > > +      another leak queue, making it active.
> > > +\item After the switch, buffers from the new leak queue are not
> > > +      used until an information leak is detected.
> > > +\end{enumerate}
> 
> the following won't happen:
> 
> > - device sees batch 2 and thinks this is part of batch 1
> >    consumes them all
> 
> Does it make sense?
> 
> Cheers,
> Babis

yes, the queue switch is used as a barrier to detect a new leak event.

-- 
MST


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


  reply	other threads:[~2023-09-13  9:37 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21 16:30 [virtio-comment] [PATCH RFC 0/3] virtio-rng based entropy leak reporting Michael S. Tsirkin
2022-11-21 16:30 ` [virtio-comment] [PATCH RFC 1/3] rng: move to a file of its own Michael S. Tsirkin
2022-11-21 16:30 ` [virtio-comment] [PATCH RFC 2/3] rng: be specific about the virtqueue Michael S. Tsirkin
2022-11-21 16:30 ` [virtio-dev] [PATCH RFC 3/3] rng: leak detection support Michael S. Tsirkin
2022-11-25 12:41   ` [virtio-dev] " Babis Chalios
2022-12-12 10:10     ` Babis Chalios
2023-01-11 13:57   ` Babis Chalios
2023-08-31 10:16   ` [virtio-dev] " Babis Chalios
2023-09-12 21:05     ` Michael S. Tsirkin
2023-09-12 21:05       ` [virtio-comment] " Michael S. Tsirkin
2023-09-13  9:32       ` Babis Chalios
2023-09-13  9:37         ` Michael S. Tsirkin [this message]
2023-09-13  9:37           ` [virtio-comment] " Michael S. Tsirkin
2023-09-13 11:19           ` Babis Chalios
2023-09-18 11:14             ` Babis Chalios
2023-09-18 12:41             ` Michael S. Tsirkin
2023-09-18 12:41               ` [virtio-comment] " Michael S. Tsirkin
2023-09-18 13:00               ` Babis Chalios
2023-09-18 13:58                 ` Michael S. Tsirkin
2023-09-18 13:58                   ` [virtio-comment] " Michael S. Tsirkin
2023-09-18 14:02                   ` Babis Chalios
2023-09-18 14:05                     ` Michael S. Tsirkin
2023-09-18 14:05                       ` [virtio-comment] " Michael S. Tsirkin
2023-09-18 16:30                       ` Babis Chalios
2023-09-19  7:32                         ` Babis Chalios
2023-09-19 10:01                           ` Michael S. Tsirkin
2023-09-19 10:01                             ` [virtio-comment] " Michael S. Tsirkin
2023-09-19 10:11                             ` Babis Chalios
2023-09-22 12:30                               ` Babis Chalios
2023-09-22 15:06                               ` Michael S. Tsirkin
2023-09-22 15:06                                 ` [virtio-comment] " Michael S. Tsirkin
2023-09-22 15:40                                 ` Babis Chalios
2023-09-22 16:01                                   ` Michael S. Tsirkin
2023-09-22 16:01                                     ` [virtio-comment] " Michael S. Tsirkin
2023-09-27 10:43                                     ` Babis Chalios
2023-09-27 21:47                                       ` Michael S. Tsirkin
2023-09-27 21:47                                         ` [virtio-comment] " Michael S. Tsirkin
2023-09-28 18:16                                         ` Babis Chalios
2023-10-13  7:49                                           ` Babis Chalios
2023-10-13 13:38                                             ` Michael S. Tsirkin
2023-10-13 13:38                                               ` [virtio-comment] " Michael S. Tsirkin
2023-11-02 11:20                                           ` Michael S. Tsirkin
2023-11-02 11:20                                             ` [virtio-comment] " Michael S. Tsirkin
2023-11-02 11:38                                             ` Babis Chalios
2023-11-02 11:51                                               ` Michael S. Tsirkin
2023-11-02 11:51                                                 ` [virtio-comment] " Michael S. Tsirkin
2023-11-02 13:42                                                 ` Babis Chalios
2023-11-02 11:25                                   ` Michael S. Tsirkin
2023-11-02 11:25                                     ` [virtio-comment] " Michael S. Tsirkin
2023-11-02 11:51                                     ` Babis Chalios
2023-01-12  7:02 ` [virtio-dev] Re: [PATCH RFC 0/3] virtio-rng based entropy leak reporting Michael S. Tsirkin
2023-01-16 11:39   ` Babis Chalios
     [not found]     ` <CAHmME9ry2fss2gsbPs2zVJkY=8Cdeae0XFD9FzCVnW67Xy3thA@mail.gmail.com>
2023-01-16 18:11       ` [virtio-comment] " Michael S. Tsirkin

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=20230913053707-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=Jason@zx2c4.com \
    --cc=aams@amazon.de \
    --cc=bchalios@amazon.es \
    --cc=graf@amazon.de \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=xmarcalx@amazon.co.uk \
    /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.