linux-kernel - Re: [PATCH 1/2] libnvdimm/security: 'security' attr never show 'overwrite' state

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] [day] [month] [year] [list]

Message-ID: <69576669-632e-1821-2076-7bc47c0bbd85@intel.com>
Date:   Mon, 3 Aug 2020 14:26:18 -0700
From:   Dave Jiang <dave.jiang@...el.com>
To:     Jane Chu <jane.chu@...cle.com>, dan.j.williams@...el.com,
        vishal.l.verma@...el.com, ira.weiny@...el.com, jmoyer@...hat.com,
        linux-nvdimm@...ts.01.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] libnvdimm/security: 'security' attr never show
 'overwrite' state



On 8/3/2020 2:10 PM, Jane Chu wrote:
> Hi, Dave,
> 
> On 8/3/2020 1:41 PM, Dave Jiang wrote:
>> On 7/24/2020 9:09 AM, Jane Chu wrote:
>>> Since
>>> commit d78c620a2e82 ("libnvdimm/security: Introduce a 'frozen' attribute"),
>>> when issue
>>>   # ndctl sanitize-dimm nmem0 --overwrite
>>> then immediately check the 'security' attribute,
>>>   # cat /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/nmem0/security
>>>   unlocked
>>> Actually the attribute stays 'unlocked' through out the entire overwrite
>>> operation, never changed.  That's because 'nvdimm->sec.flags' is a bitmap
>>> that has both bits set indicating 'overwrite' and 'unlocked'.
>>> But security_show() checks the mutually exclusive bits before it checks
>>> the 'overwrite' bit at last. The order should be reversed.
>>>
>>> The commit also has a typo: in one occasion, 'nvdimm->sec.ext_state'
>>> assignment is replaced with 'nvdimm->sec.flags' assignment for
>>> the NVDIMM_MASTER type.
>>
>> May be best to split this fix to a different patch? Just thinking git bisect 
>> later on to track issues. Otherwise Reviewed-by: Dave Jiang 
>> <dave.jiang@...el.com>
> 
> Sure. I take it you meant to separate the typo fix from the change that tests 
> the OVERWRITE bit first?

Yep!

> 
> Regards,
> -jane