Re: NAA breakage

[Martin Svec <martin.svec@zoner.cz>]

Hi Nicholas,

thanks a lot for your comments. Clearly there was a misunderstanding 
of who is the vendor that defines what is "vendor-specific" in case of 
LIO. Of course, it is easy for me to fix my userspace code to generate 
serial numbers without these issues. But I suggest to enforce 
vpd_unit_serial restrictions in configfs code because rtslib/lio-utils 
is just a referential userspace implementation, not a kernel ABI.

Thanks for all your work on LIO, have a nice day.

Martin

Dne 10.9.2011 22:37, Nicholas A. Bellinger napsal(a):
> On Sat, 2011-09-10 at 17:00 +0200, Martin Svec wrote:
>> Hi Nicholas,
>>
>> thanks for your response, see my comments below.
>>
>> Dne 9.9.2011 23:38, Nicholas A. Bellinger napsal(a):
>>> On Fri, 2011-09-09 at 14:27 +0200, Martin Svec wrote:
> <SNIP>
>
>>>> (2) target_emulate_evpd_83() wrongly assumes that the unit serial
>>>> number is a hex-encoded string with at least 25 characters and
>>>> generates NAA ID using hex2bin() from its first 25 chars.
>>>>
>>> Correct, the fix that I think makes the most sense here is to ensure
>>> that the unit serial number always contains only hex digits (by
>>> stripping out the non hex charactes) when set via configfs in
>>> vpd_unit_serial.
>> Martin: But then you place additional undocumented restrictions on the
>> unit serial number format, don't you?
>>
> No, it does not.  It's vendor specific and perfectly within what's
> allowable as defined by SPC-3.
>
>>>> (3) SCSI SPC-3 (7.6.3.6.4) states that NAA IEEE Registered Extended
>>>> identifier is a 16-byte fixed-length binary sequence that is
>>>> _uniquely_ assigned by the organization associated with the IEEE
>>>> company_id (LIO uses OpenFabrics IEEE ID 00 14 05). That is, NAA ID
>>>> must be a guaranteed _stable_ worldwide-unique identifier and e.g.
>>>> VMware strongly relies on this.
>>>>
>>>>    From (1) and (2) it follows me that LIO does not guarantee the
>>>> uniqueness and in fact it very easily produces duplicate NAA IDs. For
>>>> example, unit serial numbers with a common 25-character prefix will
>>>> necessarily lead to the same NAA ID.
>>> It's the job of userspace to generate a UUID for the unit_serial number,
>>> and to ensure (as much as possible) the UUID is unique.  Taking the
>>> first 25 characters of this value has not created a problem so far.  Can
>>> you give an example of how it's 'very easily' able to produce duplicate
>>> NAA IDs..?
>> Martin: Again, SPC-3 says nothing about hex-character UUID as a unit
>> serial number. That's the key point I try to emphasize -- you assume
>> that it has a particular format but everbody who follows only the
>> SPC-3 specification and doesn't know these LIO-specific restrictions
>> risks duplicate NAA IDs.
> Not exactly.  When it doubt, people need to follow the offical userspace
> code.  I am happy to support people who insist on their own interface to
> configfs, but for something like this your code needs to follow what our
> existing userspace library does to ensure uniqueness.
>
>>   Below is an example of two unique SPC-3
>> compliant serial numbers that result in the same NAA ID (tested with
>> mainline kernel 3.1.0-rc1+):
>>
>> $ sg_inq -p 0x83 /dev/sdc
>> VPD INQUIRY: Device Identification page
>>     Designation descriptor number 1, descriptor length: 20
>>       designator_type: NAA,  code_set: Binary
>>       associated with the addressed logical unit
>>         NAA 6, IEEE Company_id: 0x140f
>>         Vendor Specific Identifier: 0xfefbfef9f
>>         Vendor Specific Identifier Extension: 0xefefcfbfefef9fef
>>         [0x600140ffefbfef9fefefcfbfefef9fef]
>>     Designation descriptor number 2, descriptor length: 78
>>       designator_type: T10 vendor identification,  code_set: ASCII
>>       associated with the addressed logical unit
>>         vendor id: LIO-ORG
>>         vendor specific:
>> IBLOCK:OurCompanyProductionSAN.StorageServer12.Customer524.Drive1
>>
>> $ sg_inq -p 0x83 /dev/sdd
>> VPD INQUIRY: Device Identification page
>>     Designation descriptor number 1, descriptor length: 20
>>       designator_type: NAA,  code_set: Binary
>>       associated with the addressed logical unit
>>         NAA 6, IEEE Company_id: 0x140f
>>         Vendor Specific Identifier: 0xfefbfef9f
>>         Vendor Specific Identifier Extension: 0xefefcfbfefef9fef
>>         [0x600140ffefbfef9fefefcfbfefef9fef]
>>     Designation descriptor number 2, descriptor length: 78
>>       designator_type: T10 vendor identification,  code_set: ASCII
>>       associated with the addressed logical unit
>>         vendor id: LIO-ORG
>>         vendor specific:
>> IBLOCK:OurCompanyProductionSAN.StorageServer12.Customer524.Drive2
>>
>>
> FYI, descriptor number 2 above this is the 0x83 T10 vendor ID, and not
> the 0x80 unit serial number.
>
>> Clearly, the serial numbers differ only in the last character (drive
>> number), far beyond the 25 characters used for NAA. For somebody that
>> starts with (i)SCSI and wants a unique and readable identification of
>> its LUNs, these serial numbers IMHO perfectly make sense, are SPC-3
>> compliant, but VMware vSphere will be totally confused of their NAAs
>> generated by LIO.
> This is broken userspace code that is using the unit serial number for
> informational purposes.  Please don't do this.
>
> All of the lio-utils and rtslib userspace generate a uuid for the unit
> serial number,  and do not have an issue with the scenario you are
> describing.  This is what your userspace should be doing as well.
>
>>>> However, I think that the solution is easy:
>>>>
>>>> (a) Provide a ConfigFS entry for NAA ID to allow userspace to maintain
>>>> the uniqueness on its own.
>>>>
>>> I am against exposing the NAA ID as a configfs attribute.  I still think
>>> basing this upon the EVPD 0x80 unit serial still makes the most sense,
>>> and to make userspace ensure (as much as possible) that the UUID ->   unit
>>> serial is unique.
>>>
>>>> (b) If no ConfigFS NAA ID is specified, target_emulate_evpd_83()
>>>> should make the best effort to generate unique NAA ID from the unit
>>>> serial number. An obvious solution is to compute a hash (e.g. SHA1)
>>>> from the unit serial number and use its 13 most significant bytes to
>>>> fill vendor-specific NAA ID bytes.
>>>>
>>> Generating a hash based upon unit serial for the vendor-specific NAA ID
>>> bytes might be useful, but I am still not convinced there is a real
>>> problem of duplicate NAA IDs using UUID based unit seriales for the
>>> vendor specific area..
>>>
>>>> Yes, the drawback is that such a change breaks NAA IDs of existing
>>>> setups. It's a question if it is better to maintain backward
>>>> compatibility, or fix it while LIO is in mainline for a short time yet.
>>>>
>>> I think the drawback is worth the extra pain here..  As mentioned, I am
>>> still leaning toward a simple fix to force hex characters for all
>>> vpd_unit_serial values set via configfs.
>>>
>> Martin: Yes, that's a possible solution -- enforce vpd_unit_serial to
>> be a hex-character string at least 25 characters long, and document
>> that the first 25 characters must be unique within a given SAN. It's
>> more restrictive than SPC-3 says but at least it doesn't allow to set
>> vpd_unit_serial to something that leads to duplicate NAA IDs.
>>
>> I still think that my proposal is better because it provides the same
>> guarantees without additional restrictions to SPC-3 standard but I can
>> live with it :-) All that I want is to save future LIO users from
>> surprises caused by the NAA ID generation based on undocumented
>> vpd_unit_serial assumptions.
>>
> No, changing kernel code to address the breakage of your own userspace
> is not an option here.
>
> Please fix your userspace code to follow what rtslib has always done to
> ensure the uniqueness of vpd_unit_serial via a well known method (eg:
> uuid).
>
> http://www.risingtidesystems.com/git/?p=rtslib.git;a=blob;f=rtslib/tcm.py;h=4da49b0f4a4aea9a1eebed23d457181085a2d03d;hb=HEAD#l307
>
> Thanks,
>
> --nab
>