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:	Tue, 20 Apr 2010 10:52:02 -0700
From:	Greg KH <greg@...ah.com>
To:	Joerg Roedel <joro@...tes.org>
Cc:	Joerg Roedel <joerg.roedel@....com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: pci_get_dev_by_id() from interrupt handlers

On Tue, Apr 20, 2010 at 07:35:59PM +0200, Joerg Roedel wrote:
> On Tue, Apr 20, 2010 at 09:32:15AM -0700, Greg KH wrote:
> > On Tue, Apr 20, 2010 at 06:04:24PM +0200, Joerg Roedel wrote:
> > > Is there any other reason it should not be called in interrupt
> > > handlers?
> > 
> > klist traversal is not safe to be done in interrupt context as the
> > spinlock is not told to be interrupt safe.  Now you could go and change
> > the klist core to be interrupt safe, but you should probably rethink
> > your need here first.
> 
> The idea was to capture IO page faults in the IOMMU and propagate them
> to KVM instead of just printk into dmesg. KVM could do something better
> then like killing the guest. Currently a malicious guest could flood
> host dmesg by causing IO page faults.

That's not good.

> For the AMD IOMMU the page faults are reported in an event log and the
> cpu is informed by an interrupt about it. The event log entry contains
> the bus/dev/function of the device. To get the necessary information to
> propagate this to KVM I need to get the 'struct device' for it.

Ok, that's reasonable.

> I could certainly do this in a tasklet instead but doing that only for
> the task of converting bus/device/function into 'struct device' sounds
> a bit complicated to me.

Why not do the whole thing in an interrupt task as the whole thing
sounds like something that shouldn't be done in interrupt context,
right?  Now that we have this type of functionality, we should take
advantage of it :)

Eventually, notifying KVM isn't something that you want to do from
interrupt context anyway, right?

thanks,

greg k-h
--
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