linux-kernel - Re: [PATCH 8/9] PCI: Ignore BAR contents when firmware left decoding disabled

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 21 Mar 2014 16:25:16 -0400
From:	Sasha Levin <sasha.levin@...cle.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Ming Lei <tom.leiming@...il.com>
CC:	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Pekka Enberg <penberg@...nel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH 8/9] PCI: Ignore BAR contents when firmware left decoding
 disabled

On 03/21/2014 04:07 PM, Bjorn Helgaas wrote:
> I think I figured out what the problem is.  In virtio_pci__init(), we
> allocate some address space with pci_get_io_space_block(), save its
> address in vpci->mmio_addr, and hook that address space up to
> virtio_pci__io_mmio_callback with kvm__register_mmio().
>
> But when we update the BAR value in pci__config_wr(), the address
> space mapping is never updated.  I think this means that virtio-pci
> can't tolerate its devices being moved by the OS.
>
> In my opinion, this is a bug in linux-kvm.  We've managed to avoid
> triggering this bug by preventing Linux from moving the BAR (either by
> me reverting my patch, or by Sasha's linux-kvm change [1]).  But it's
> not very robust to assume that the OS will never change the BAR, so
> it's quite possible that you'll trip over this again in the future.

The purpose of KVM tool is to implement as much as possible of the KVM
interface and the virtio spec so that we'll have a good development/testing
environment with a very simple to understand codebase.

The issue you've mentioned is the "evil" side of the KVM tool. It never
tried (or claimed) to implement anything close to legacy hardware
interfaces. This means, for example, that it doesn't run any BIOS, there's
very lacking APIC support and the kernel is just injected into the virtual
RAM and gets run from there.

It also means that we went into the PCI spec deep enough to get the code
to work with the kernel. The only reason we implemented MSI interrupts
for example is because they provide improved performance with KVM, not
because we were trying to get a complete implementation of the PCI spec.

So yes, the PCI implementation in the KVM tool is lacking and what we
have there might be broken by making the kernel conform more closely
to the spec, but we are always happy to adapt and improve our code to
work with any changes in the kernel.

To sum it up, If you'll end up adding a change to the kernel that is
valid according to the spec but breaks the KVM tool we'll just go ahead
and fix the tool. You really don't need to worry about breaking it.

Thanks,
Sasha
--
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/