Re: [Qemu-devel] 9p mapped-* security model infos are architecture-specific

["Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>]

Michael Tokarev <mjt@tls.msk.ru> writes:

> I haven't noticed this email - which is almost a month old now - until today.
> So replying now...
>
> 30.07.2014 21:43, Aneesh Kumar K.V wrote:
>> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
>> 
>>> Michael Tokarev <mjt@tls.msk.ru> writes:
>>>
>>>> Apparently the the mapped-* security models results in a raw bytes
>>>> being dumped to host without any architecture normalization (in
>>>> host byte order).  This may even lead to security issues in guest
>>>> when the same files are served from another host for example.
>>>>
>>>> This bug has been initially submitted against debian qemu package, see
>>>> http://bugs.debian.org/755740
>>>>
>>>
>>> Thanks for reporting the bug. Yes we do have issue with
>>> mapped-xattr. But mapped-file should be ok. We record the uid/gid as
>>> string in the file.
>> 
>> What would be the best way to fix this in a backward compatible way ?
>> Considering most of the users will be little endian host, we could do "always
>> store in little endian format" which of-course will break big-endian
>> hosts. We could possibly ask them to update xattr using external tools ?
>
> If there's no way to _detect_ the used format (maybe doing some guessing, --
> if that's possible to do in a reliable way, it should be good), that's
> one of 2 possible options as I see it: that or introduce a new format
> entirely, maybe with another attribute name.
>
> It might not be even required to use an external tool for conversion.
> Again, if qemu is able to detect "wrong" endiannes, it might just
> update things itself, or print a warning and switch to an old format,
> or something like that.

I was not able to come up with a way to detect "wrong" endianness. 

>
> But the guessing idea might not be as bad really.  I haven't looked
> closely which information is stored in there, -- but it is possible
> that some fields should have zeros in some bytes for example, and
> if these aren't zero but becomes zeros after endianness conversion
> that might be a good indicator.


No, they are 32 bit numbers and we can't make any assumptions w.r.t
upper half/lower half being zero


>
> I'm not sure the runtime code should be able to work with both formats
> at the same time.  Actually, I'm not sure this is a big issue to
> start with -- indeed, you said it already, majority of users of 9pfs
> should be little endian hosts, -- are there any big endian hosts
> using this, at all? :)  How about trying to detect (preferrable at
> init time) and refusing to start if old/wrong format is detected.
>
> Maybe have a compile-time define to use native or little endian
> format is a good idea too.
>

That would confuse further. It also impact the interoperability of
export path across different build of qemus.


> Bastian, since you discovered this issue, you might be using
> a host with "uncommon" endianness, what do you think?
>

-aneesh