All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Fam Zheng <fam@euphon.net>, Laurent Vivier <lvivier@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	qemu-block@nongnu.org, Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org,
	Wainer dos Santos Moschetta <wainersm@redhat.com>,
	Max Reitz <mreitz@redhat.com>, Alexander Bulekov <alxndr@bu.edu>,
	Bandan Das <bsd@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Cleber Rosa <crosa@redhat.com>, Kevin Wolf <kwolf@redhat.com>
Subject: Re: [PATCH v2 0/2] block: Use 'read-zeroes=true' mode by default with 'null-co' driver
Date: Mon, 22 Feb 2021 18:15:13 +0000	[thread overview]
Message-ID: <YDP0sZHoT45skArd@redhat.com> (raw)
In-Reply-To: <38dd38eb-af59-8baf-b908-fb6c4e842cd1@redhat.com>

On Fri, Feb 19, 2021 at 03:09:43PM +0100, Philippe Mathieu-Daudé wrote:
> On 2/19/21 12:07 PM, Max Reitz wrote:
> > On 13.02.21 22:54, Fam Zheng wrote:
> >> On 2021-02-11 15:26, Philippe Mathieu-Daudé wrote:
> >>> The null-co driver doesn't zeroize buffer in its default config,
> >>> because it is designed for testing and tests want to run fast.
> >>> However this confuses security researchers (access to uninit
> >>> buffers).
> >>
> >> I'm a little surprised.
> >>
> >> Is changing default the only way to fix this? I'm not opposed to
> >> changing the default but I'm not convinced this is the easiest way.
> >> block/nvme.c also doesn't touch the memory, but defers to the device
> >> DMA, why doesn't that confuse the security checker?
> 
> Generally speaking, there is a balance between security and performance.
> We try to provide both, but when we can't, my understanding is security
> is more important.
> 
> Customers expect a secure product. If they prefer performance and
> at the price of security, it is also possible by enabling an option
> that is not the default.
> 
> I'm not sure why you mention block/nvme here. I have the understanding
> the null-co driver is only useful for testing. Are there production
> cases where null-co is used?

Do we have any real world figures for the performance of null-co
with & without  zero'ing ?  Before worrying about a tradeoff of
security vs performance, it'd be good to know if there is actually
a real world performance problem in the first place. Personally I'd
go for zero'ing by defualt unless the performance hit was really
bad.

> BTW block/nvme is a particular driver where performance matters more
> than security (but we have to make sure the users are aware of that).


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  parent reply	other threads:[~2021-02-22 18:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-11 14:26 [PATCH v2 0/2] block: Use 'read-zeroes=true' mode by default with 'null-co' driver Philippe Mathieu-Daudé
2021-02-11 14:26 ` [PATCH v2 1/2] block: Explicit null-co uses 'read-zeroes=false' Philippe Mathieu-Daudé
2021-02-11 16:29   ` Vladimir Sementsov-Ogievskiy
2021-02-11 19:19     ` Philippe Mathieu-Daudé
2021-02-11 22:40   ` Eric Blake
2021-02-11 23:49     ` Philippe Mathieu-Daudé
2021-02-12 11:34     ` Vladimir Sementsov-Ogievskiy
2021-02-12 19:06   ` Eric Blake
2021-02-11 14:26 ` [PATCH v2 2/2] block/null: Enable 'read-zeroes' mode by default Philippe Mathieu-Daudé
2021-02-11 16:22   ` Stefan Hajnoczi
2021-02-11 15:42 ` [PATCH v2 0/2] block: Use 'read-zeroes=true' mode by default with 'null-co' driver Alexander Bulekov
2021-02-12 14:32   ` Philippe Mathieu-Daudé
2021-02-13 21:54 ` Fam Zheng
2021-02-19 11:07   ` Max Reitz
2021-02-19 14:09     ` Philippe Mathieu-Daudé
2021-02-22 17:35       ` Fam Zheng
2021-02-22 17:55         ` Philippe Mathieu-Daudé
2021-02-23  9:21           ` Fam Zheng
2021-02-23 16:01             ` Max Reitz
2021-02-23 17:21               ` Fam Zheng
2021-02-22 18:15       ` Daniel P. Berrangé [this message]
2021-02-22 18:36         ` Philippe Mathieu-Daudé
2021-02-23  8:44         ` Max Reitz
2021-02-23  9:29           ` Daniel P. Berrangé

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=YDP0sZHoT45skArd@redhat.com \
    --to=berrange@redhat.com \
    --cc=alxndr@bu.edu \
    --cc=armbru@redhat.com \
    --cc=bsd@redhat.com \
    --cc=crosa@redhat.com \
    --cc=fam@euphon.net \
    --cc=kwolf@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    --cc=wainersm@redhat.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.