On Fri, Oct 23, 2015 at 12:37:06PM +0100, David Woodhouse wrote: > It's more than that — it's equivalent to the situation *with* the > IOMMU. > > Having a *separate* PASID which is the only PASID we can use for kernel > mode is *not* a security improvement. In the general case, if a user > can trick the device into setting the 'supervisor mode' bit on a given > access, it could probably just as easily trick the device into using > the separate kernel PASID for that access. In neither case is it as > simple as just asking the device to use a kernel address. > > I'm not proposing it for that reason, which is why I'm objecting to > your 'we have to...' response. Although maybe I should shut up, because > I'm pleased you aren't objecting to my plan and saying that we *do* > need to permit supervisor-mode access in normal PASIDs. At best I'd like to avoid supervisor access for devices at all, but there seems to be a need for it, so I looks like we need to provide it. Therefore I think that your idea to have a seperate PASID for kernel access, and only kernel access, is a good one. We even don't need to use a defined PASID, we can randomize the PASID used for kernel accesses and make it harder to guess this way. But having both, kernel and supervisor access, allowed for a PASID is another story, and I think we need to be careful with that (or at least avoid that the driver writers need to care that much about it to prevent userspace from getting access to kernel memory). > You mean an inline function which checks for iommu->kernel_svm ∀ iommu? > And does the equivalent for other IOMMUs? I wouldn't want IOMMU > -specific code in there; just a decision about whether to call the out > -of-line function. > > Or maybe if we are making PASID handling generic and system-wide, it > really does become a case of 'if (init_mm.pasid != -1)' ...? Yes, something like that, and of course independent of the iommu. When we have a system-wide PASID registry we can check against that, or introduce a global read_mostly flag. Using init_mm refcounting or flags also sounds like a good idea. Joerg -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>