From: Dan Williams <dan.j.williams@intel.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: Re: [PATCH 2/3] libnvdimm/security: Tighten scope of nvdimm->busy vs security operations
Date: Fri, 16 Aug 2019 14:02:19 -0700 [thread overview]
Message-ID: <CAPcyv4iPBO9atdr_LdHNt=tCgjh-j_HyKXaCdUkWxb_J7OCcxg@mail.gmail.com> (raw)
In-Reply-To: <x49zhk8bzuh.fsf@segfault.boston.devel.redhat.com>
On Fri, Aug 16, 2019 at 1:49 PM Jeff Moyer <jmoyer@redhat.com> wrote:
>
> Dan Williams <dan.j.williams@intel.com> writes:
>
> > The blanket blocking of all security operations while the DIMM is in
> > active use in a region is too restrictive. The only security operations
> > that need to be aware of the ->busy state are those that mutate the
> > state of data, i.e. erase and overwrite.
> >
> > Refactor the ->busy checks to be applied at the entry common entry point
> > in __security_store() rather than each of the helper routines.
>
> I'm not sure this buys you much. Did you test this on actual hardware
> to make sure your assumptions are correct? I guess the worst case is we
> get an "invalid security state" error back from the firmware....
>
> Still, what's the motivation for this?
The motivation was when I went to test setting the frozen state and
found that it complained about the DIMM being active. There's nothing
wrong with freezing security while the DIMM is mapped. ...but then I
somehow managed to write this generalized commit message that left out
the explicit failure I was worried about. Yes, moved too fast, but the
motivation is "allow freeze while active" and centralize the ->busy
check so it's just one function to review that common constraint.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: linux-nvdimm <linux-nvdimm@lists.01.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] libnvdimm/security: Tighten scope of nvdimm->busy vs security operations
Date: Fri, 16 Aug 2019 14:02:19 -0700 [thread overview]
Message-ID: <CAPcyv4iPBO9atdr_LdHNt=tCgjh-j_HyKXaCdUkWxb_J7OCcxg@mail.gmail.com> (raw)
In-Reply-To: <x49zhk8bzuh.fsf@segfault.boston.devel.redhat.com>
On Fri, Aug 16, 2019 at 1:49 PM Jeff Moyer <jmoyer@redhat.com> wrote:
>
> Dan Williams <dan.j.williams@intel.com> writes:
>
> > The blanket blocking of all security operations while the DIMM is in
> > active use in a region is too restrictive. The only security operations
> > that need to be aware of the ->busy state are those that mutate the
> > state of data, i.e. erase and overwrite.
> >
> > Refactor the ->busy checks to be applied at the entry common entry point
> > in __security_store() rather than each of the helper routines.
>
> I'm not sure this buys you much. Did you test this on actual hardware
> to make sure your assumptions are correct? I guess the worst case is we
> get an "invalid security state" error back from the firmware....
>
> Still, what's the motivation for this?
The motivation was when I went to test setting the frozen state and
found that it complained about the DIMM being active. There's nothing
wrong with freezing security while the DIMM is mapped. ...but then I
somehow managed to write this generalized commit message that left out
the explicit failure I was worried about. Yes, moved too fast, but the
motivation is "allow freeze while active" and centralize the ->busy
check so it's just one function to review that common constraint.
next prev parent reply other threads:[~2019-08-16 21:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-15 1:20 [PATCH 0/3] libnvdimm/security: Enumerate the frozen state and other cleanups Dan Williams
2019-08-15 1:20 ` Dan Williams
2019-08-15 1:20 ` [PATCH 1/3] libnvdimm/security: Introduce a 'frozen' attribute Dan Williams
2019-08-15 1:20 ` Dan Williams
2019-08-16 20:34 ` Jeff Moyer
2019-08-16 20:34 ` Jeff Moyer
2019-08-15 1:20 ` [PATCH 2/3] libnvdimm/security: Tighten scope of nvdimm->busy vs security operations Dan Williams
2019-08-15 1:20 ` Dan Williams
2019-08-16 20:49 ` Jeff Moyer
2019-08-16 20:49 ` Jeff Moyer
2019-08-16 21:02 ` Dan Williams [this message]
2019-08-16 21:02 ` Dan Williams
2019-08-19 14:32 ` Jeff Moyer
2019-08-19 14:32 ` Jeff Moyer
2019-08-15 1:20 ` [PATCH 3/3] libnvdimm/security: Consolidate 'security' operations Dan Williams
2019-08-15 1:20 ` Dan Williams
2019-08-16 20:51 ` Jeff Moyer
2019-08-16 20:51 ` Jeff Moyer
2019-08-23 18:11 ` [PATCH 0/3] libnvdimm/security: Enumerate the frozen state and other cleanups Dave Jiang
2019-08-23 18:11 ` Dave Jiang
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='CAPcyv4iPBO9atdr_LdHNt=tCgjh-j_HyKXaCdUkWxb_J7OCcxg@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
/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.