Hello folks,
I'd like to reopen this discussion because there was no conclusion in
last three weeks and I still believe that the present implementation
of NAA IDs is wrong, regardless of the Andy's Shevchenko patch. Let me
explain why:
(1) According to SCSI SPC-3 (7.6.10), 0x80 VPD unit serial number is a
vendor-assigned variable-length string of ASCII data with characters
20h through 7Eh.
(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.
(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. With Andy's Shevchenko patch, the
same also holds for serial numbers that contain only non-hex
characters in first 25 bytes, resulting in NAA IDs full of 0xff. And
there are other cases where hex2bin() conversion applied to serial
numbers leads to duplicates.
So the way NAA ID is generated from the serial number seems to be
broken and does not guarantee NAA ID uniqueness even if the serial
numbers are unique and SPC-3 compliant.
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.
(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.
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.
(Sorry that I don't include a patch but I'm not a kernel developer and
I have no knowledge of configfs and crypto APIs.)
Have a nice day.
Martin
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
