On 10/07/2015 12:58 AM, Stephen Hemminger wrote:
Go ahead and submit a seperate taint bit for UIO as a patch.
Taint should only be applied if bus mastering is enabled (to avoid annoying the users of the original uio use case)
On Tue, Oct 6, 2015 at 10:41 PM, Alex Williamson <alex.williamson@xxxxxxxxxx <mailto:alex.williamson@xxxxxxxxxx>> wrote:
On Tue, 2015-10-06 at 22:32 +0100, Stephen Hemminger wrote:
> On Tue, 06 Oct 2015 12:51:20 -0600
> Alex Williamson <alex.williamson@xxxxxxxxxx
<mailto:alex.williamson@xxxxxxxxxx>> wrote:
>
> > Of course this is entirely unsafe and this no-iommu driver
should taint
> > the kernel, but it at least standardizes on one userspace API
and you're
> > already doing completely unsafe things with uio. vfio should be
> > enlightened at least to the point that it allows only
privileged users
> > access to devices under such a (lack of) iommu
>
> I agree with the design, but not with the taint argument.
> (Unless you want to taint any and all use of UIO drivers which can
> already do this).
Yes, actually, if the bus master bit gets enabled all bets are
off. I
don't see how that leaves a supportable kernel, so we might as well
taint it. Isn't this exactly why we taint for proprietary
drivers, we
have no idea what it has mucked with in kernel space. This just moves
the proprietary driver out to userspace without an iommu to
protect the
host. Thanks,
Alex