From: Bart Van Assche <bvanassche@acm.org>
To: Damien Le Moal <Damien.LeMoal@wdc.com>,
Alexander Potapenko <glider@google.com>
Cc: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>,
Jens Axboe <axboe@kernel.dk>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
Willem de Bruijn <willemb@google.com>,
Dmitriy Vyukov <dvyukov@google.com>
Subject: Re: null_handle_cmd() doesn't initialize data when reading
Date: Mon, 11 May 2020 19:43:50 -0700 [thread overview]
Message-ID: <b90e0030-c0fa-7e7e-ea17-137d49293f54@acm.org> (raw)
In-Reply-To: <BY5PR04MB690045ED7665BF98A2EA7ED3E7BE0@BY5PR04MB6900.namprd04.prod.outlook.com>
On 2020-05-11 18:42, Damien Le Moal wrote:
> The patch looks good to me. However, I have one concern regarding the
> performance impact of this. When nullblk is used to benchmark the block IO stack
> overhead, doing this zeroing unconditionally will likely significantly impact
> measured performance. So may be this zeroing feature should be driven by a
> modprobe/configfs option ? Doing so, we can keep it off by default, preserving
> performance, and turn it on when needed as in Alexander use case.
>
> Thoughts ?
Hi Damien,
Does the current implementation of null_blk allow one process to access
data that was generated by another process? If so, does that behavior
count as a security bug?
I am aware of the performance impact of the patch attached to my
previous email. I have not made the zeroing behavior optional because
I'm concerned about the security implications of doing that.
Bart.
next prev parent reply other threads:[~2020-05-12 2:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-15 10:16 null_handle_cmd() doesn't initialize data when reading Alexander Potapenko
2019-11-20 23:12 ` Jens Axboe
2019-11-22 11:58 ` Alexander Potapenko
2019-11-25 4:01 ` Chaitanya Kulkarni
2020-05-10 10:03 ` Alexander Potapenko
2020-05-10 16:20 ` Bart Van Assche
2020-05-11 12:58 ` Alexander Potapenko
2020-05-11 13:01 ` Damien Le Moal
2020-05-11 13:09 ` Alexander Potapenko
2020-05-11 23:18 ` Bart Van Assche
2020-05-12 1:25 ` Bart Van Assche
2020-05-12 1:42 ` Damien Le Moal
2020-05-12 2:43 ` Bart Van Assche [this message]
2020-05-12 3:23 ` Damien Le Moal
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=b90e0030-c0fa-7e7e-ea17-137d49293f54@acm.org \
--to=bvanassche@acm.org \
--cc=Chaitanya.Kulkarni@wdc.com \
--cc=Damien.LeMoal@wdc.com \
--cc=axboe@kernel.dk \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=linux-block@vger.kernel.org \
--cc=willemb@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).