On Wed, 2012-06-06 at 13:18 +0200, Jan Kiszka wrote: > On 2012-06-06 13:12, Avi Kivity wrote: > > On 06/05/2012 08:13 PM, Alex Williamson wrote: > >> On Tue, 2012-06-05 at 10:37 +0200, Jan Kiszka wrote: > >>> The masking was wrong (must have been 0x7f), and there is no need to > >>> re-read the value as pci_setup_device already does this for us. > >> > >> The intent was to mask off the multifunction bit from header_type, but > >> the implementation is clearly wrong. hdr_type does both. Thanks > >> > >>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43339 > >>> Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > >> > >> Acked-by: Alex Williamson <alex.williamson@xxxxxxxxxx> > > > > From your comment in the bugzilla entry I conclude that there is no need > > to get this into 3.5. is this correct? > > As I asses this (and I think Alex meant the same), this is not a > critical fix or even a security issue, just a (so far broken) safety > belt for users that are privileged anyway. Also, there were no valid > devices accidentally excluded due to the bug. Right. If a bridge does not have BARs (apparently what I tested on), it will get rejected from assignment because we assume devices without resources are special. If it does have BARs, some privileged entity needs to grant permissions to the resources, just like any other device. So while the existing code doesn't close the misconfiguration window we were trying for, it doesn't expose any kind of security issue. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
