linux-kernel - RE: [PATCH v2] nfit: add Hyper-V NVDIMM DSM command set to white list

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 2 Feb 2019 00:34:14 +0000
From:   Dexuan Cui <decui@...rosoft.com>
To:     Dan Williams <dan.j.williams@...el.com>
CC:     Ross Zwisler <zwisler@...nel.org>,
        Vishal Verma <vishal.l.verma@...el.com>,
        Dave Jiang <dave.jiang@...el.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        Josh Poulson <jopoulso@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        "driverdev-devel@...uxdriverproject.org" 
        <driverdev-devel@...uxdriverproject.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Michael Kelley <mikelley@...rosoft.com>,
        Sasha Levin <Alexander.Levin@...rosoft.com>,
        KY Srinivasan <kys@...rosoft.com>
Subject: RE: [PATCH v2] nfit: add Hyper-V NVDIMM DSM command set to white list

> From: Dan Williams <dan.j.williams@...el.com>
> Sent: Friday, February 1, 2019 3:47 PM
> To: Dexuan Cui <decui@...rosoft.com>
> 
> I believe it's the same reason. Without 11189c1089da the _LSR method
> will fail, and otherwise it works and finds the label that it doesn't
> like.
Exactly.
 
> I'm not seeing "invalid" data in your failure log. Could you double
> check that it's just not the success of _LSR that causes the issue?

acpi_label_read() never fails for me.

By "invalid", I only mean the messages in the dmesg.bad.txt I previously
attached (I'm just reading the specs to learn the details about NVDIMM
namespace's labels, so my description might be inaccurate) :

[    4.832367] nvdimm nmem1: nsindex0 labelsize 1 invalid
[    4.832369] nvdimm nmem1: nsindex1 labelsize 1 invalid
...
[    5.259017] nd_pmem namespace0.0: 0x0000000000000000, too small must be at least 0x1000

> > > The regression you are seeing is the fact that the patch enables the kernel
> to
> > > enable nvdimm-namespace-label reads.
> > Yes.
> >
> > > Those reads find a namespace index block
> > > and a label. Unfortunately the label has the LOCAL flag set and Linux
> > > explicitly ignores pmem namespace labels with that bit set. The reason
> > Can you please point out the function that ignores the flag?
> >
> > I checked where NSLABEL_FLAG_LOCAL is used, but it looks I can't find a
> > related function.
> 
> scan_labels() is where the namespace label is validated relative to
> the region type:
> 
>                 if (is_nd_blk(&nd_region->dev)
>                                 == !!(flags & NSLABEL_FLAG_LOCAL))
>                         /* pass, region matches label type */;
>                 else
>                         continue;
> 
> It also has meaning for the namespace capacity allocation
> implementation that needed that flag to distinguish aliased capacity
> between Block Aperture Mode and PMEM Mode access.
Thanks for the pointer! I'm looking at this function.

> > > for that is due to the fact that the original definition of the LOCAL
> > > bit from v1.1 of the namespace label implementation [1] explicitly
> > > limited the LOCAL flag to "block aperture" regions. If you clear that
> > > LOCAL flag I expect it will work. To my knowledge Windows pretends
> > > that the v1.1 definition never existed.
> > I'm trying to find out where the flag is used and how to clear it.
> 
> Assuming Hyper-V implements _LSW, you can recreate / reinitialize the
> label area:

I think Hyper-V only implements _LSR:
[    4.720623] nfit ACPI0012:00: device:00: has _LSR
[    4.723683] nfit ACPI0012:00: device:01: has _LSR
 
> > > The UEFI 2.7 specification for v1.2 labels states that setting the
> > > LOCAL flag is optional when "nlabel", number of labels in the set, is
> > > 1. Linux makes that mandatory as LOCAL is redundant when nlabel is 1.
> > >
> > > That said, the Robustness Principle makes a case that Linux should
> > > tolerate the bit being set. However, it's just a non-trivial amount of
> > > work to unwind the ingrained block-aperture assumptions of that bit.
> > Can you please explain this a bit more? Sorry, I'm new to this area...
> 
> The short story is that Linux enforces that LOCAL == Block Mode
> Namespaces. See section 2.2 Namespace Label Layout in the original
> spec [1]. The EFI 2.7 definition tried to allow for LOCAL to be set
> when an interleave-set was comprised of a single NVDIMM, but then also
> states its optional when Nlabel is 1. It has zero functional use for
> interleave-set based namespaces even when the interleave-set-width is
> 1. So Linux takes the option to never set it, and goes further to
> reject it if it's set and the region-type does not match, because that
> follows the v1.1 meaning of the flag.
> 
> [1]:
Thanks for the link! I'll read it.
BTW, it looks Hyper-V only supports PMEM namespace, at least so far.

Thanks,
-- Dexuan