Re: [PATCH v3 1/1] device-types/blk/description.tex: Allow longer device IDs to be returned

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Sep 08, 2026 at 10:12:03PM -0400, Demi Marie Obenour wrote:
> On 9/8/26 12:43, Michael S. Tsirkin wrote:
> > On Tue, Sep 08, 2026 at 04:46:40PM +0100, Richard W.M. Jones wrote:
> >> On Tue, Sep 08, 2026 at 11:14:46AM -0400, Stefan Hajnoczi wrote:
> >>> On Tue, Sep 08, 2026 at 10:40:50AM +0100, Richard W.M. Jones wrote:
> >>>> +Although 247 byte device ID strings are allowed, there may be
> >>>> +interoperability problems if strings longer than 128 bytes are used.
> >>>
> >>> Can you be more specific? Is the concern that the guest software stack
> >>> above of the driver may not be prepared for serial strings longer than
> >>> 128 bytes?
> >>
> >> I'll add more detail in the next version, but in brief the problems
> >> are twofold:
> >>
> >> (1) Windows supports up to 128 "characters" (they're not precise but
> >> they probably mean Unicode codepoints from the Basic Multilingual Plane):
> >>
> >> https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/ns-storport-stor_serial_number
> >>
> >> (2) When udev tries to encode a very long serial into a
> >> /dev/disk/by-id path you end up uncomfortably close to NAME_MAX (255).
> >>
> >>>> +It is also advisable to use only 7 bit ASCII characters.
> >>>
> >>> Versus "The device ID string is an ASCII string which can be up to 247
> >>> bytes long" earlier in this patch. Is ASCII a "SHOULD" or a "MUST"?
> >>
> >> It's "SHOULD".  I can't see any good coming from trying to use
> >> anything except letters, numbers and dashes in a serial, but both
> >> Linux and Windows (see above) could in theory handle Unicode.
> >>
> >> Rich.
> > 
> > 
> > Linux actually has code to try and handle that. unicode
> > is actually the less problematic part - ascii is
> > full of pitfalls, eith things like
> > slashes are much weirder - e.g. udev will create
> > a subdirectory with slashes. what will windows do?
> > and what will it do with backslashes? /me shrugs
> 
> What about /../../../../../../../../..?

what do you want to know, whether it's valid?

the answer is no - systemd validates paths and will not
attempt to create paths it considers invalid, such as ones with dots.

That code is in path-util.h,

https://github.com/systemd/systemd/blob/main/src/basic/path-util.h

peruse it if you want to know more.

> Honestly, the simplest way to protect against problems is to
> just use a hex-encoded or base32-encoded cryptographic hash as
> the name.

I don't know that it's simplest, but yes, some do that.
Other subsets are safe, too.  But as I said,
unicode multibyte codepoints are not really problematic at all.


-- 
MST