Re: [PATCH] * grub-core/fs/udf.c: Add support for UUID

[Pali Rohár]

On Monday 08 May 2017 15:13:28 Vladimir 'phcoder' Serbinenko wrote:
> On Mon, Apr 10, 2017, 23:17 Pali Rohár <address@hidden> wrote:
> > char *outbuf, int normalize_utf8)
> 
> Normalize isn't the right word. And it's not utf-8 but latin1 (called
> compressed utf-16 by udf docs).

Without this patch part read_string() expects that input string is 
either utf-8 or utf-16 in that compressed osta form. If input string is 
marked with leading 0x8 but contains invalid UTF-8 sequence (like chars 
80-FF) then it is treated as Latin1 and converted to UTF-8 in output. So 
input "\x80" is returned as "\xC2\x80".

What I need is to do not do this Latin1 --> UTF-8 conversion if input is 
marked with leading 0x8 and stay it in binary/raw/octets form. This is 
due to older versions of mkudffs which put into volset string not 
conforming to osta spec. libblkid do not do that "\x80" --> "\xC2\x80" 
conversion too so it is better to have same algorithm for providing UUID 
on running system (blkid on Linux) and in bootloader (Grub2).

> Are you sure you handle utf-16 case correctly? What is the expected
> behavior in those cases? Ideally you may want to just parse raw
> string in caller

If volsetid is stored according to osta spec, then it is handed 
correctly (both UTF-8 and UTF-16).

> > +  binpos = 16;
> > +  for (i = 0; i < len; ++i)
> > +    {
> > +      if (!grub_isalnum (buf[i]))
> 
> That looks real weird. What if first byte of UUID is 'a'? What if
> alnum part contains non-English chars.
> I have to admit I don't get what expected behaviour is. Can you
> elaborate on this and enable UUID test in udf_test to check that
> UUID matches blkid?

According to osta spec, first 16 characters of volsetid are unique and 
remaining anything. First 8 characters are hexadecimal representation of 
32bit timestamp and remaining 8 implementation free (but still are 
unique). Therefore those first 16 characters we use for generating UUID.
Again some generators of UDF disks do not put there hexadecimal number, 
but some garbage (sometimes not valid UTF-8...) so this code generates 
alphanumeric UUID from input with fact that in most cases is input 
hexadecimal (so used as is).

If you have other idea how to deal with this, let me know...

-- 
Pali Rohár
address@hidden

signature.asc
Description: This is a digitally signed message part.