lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 14 Feb 2013 10:52:48 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	"Michael S. Tsirkin" <mst@...hat.com>,
	Marc Zyngier <marc.zyngier@....com>
Cc:	Pawel Moll <Pawel.Moll@....com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"virtualization\@lists.linux-foundation.org" 
	<virtualization@...ts.linux-foundation.org>
Subject: Re: [RFC PATCH] virt_mmio: fix signature checking for BE guests

"Michael S. Tsirkin" <mst@...hat.com> writes:
> On Wed, Feb 13, 2013 at 03:28:52PM +0000, Marc Zyngier wrote:
>> On 13/02/13 15:08, Pawel Moll wrote:
>> > On Wed, 2013-02-13 at 14:25 +0000, Marc Zyngier wrote:
>> >> Using readl() to read the magic value and then memcmp() to check it
>> >> fails on BE, as bytes will be the other way around (by virtue of
>> >> the registers to follow the endianess of the guest).
>> > 
>> > Hm. Interesting. I missed the fact that readl() as a "PCI operation"
>> > will always assume LE values...
>> > 
>> >> Fix it by encoding the magic as an integer instead of a string.
>> >> So I'm not completely sure this is the right fix, 
>> > 
>> > It seems right, however...
>> > 
>> >> - Using __raw_readl() instead. Is that a generic enough API?
>> >>
>> > ... this implies that either the spec is wrong (as it should say: the
>> > device registers are always LE, in the PCI spirit) or all readl()s & co.
>> > should be replaced with __raw equivalents.
>> 
>> Well, the spec clearly says that the registers reflect the endianess of
>> the guest, and it makes sense: when performing the MMIO access, KVM
>> needs to convert between host and guest endianess.
>> 
>> > Having said that, does the change make everything else work with a BE
>> > guest? (I assume we're talking about the guest being BE, right? ;-) If
>> > so it means that the host is not following the current spec and it
>> > treats all the registers as LE.
>> 
>> Yes, I only care about a BE guest. And no, not much is actually working
>> (kvmtool is not happy about the guest addresses it finds in the
>> virtio-ring). Need to dive into it and understand what needs to be fixed...
>
> Does it work for qemu? I know people were using virtio on BE there.

It's had no end of problems: the powerpc folk are quite upset with me.

If I were doing virtio again, I'd use LE everywhere: device authors
*expect* to worry about endian, and it's confusing for them when they
don't.

It's tempting to use LE for the PCI config space for the new layout, for
example.

If you want to specify virtio-mmio as LE, feel free.

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ