From: Joerg Roedel <joro@8bytes.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
iommu@lists.linux-foundation.org,
Sudeep Dutt <sudeep.dutt@intel.com>
Subject: Re: [RFC PATCH] iommu/vt-d: Add IOTLB flush support for kernel addresses
Date: Fri, 23 Oct 2015 14:42:58 +0200 [thread overview]
Message-ID: <20151023124257.GB27420@8bytes.org> (raw)
In-Reply-To: <1445600226.4113.196.camel@infradead.org>
On Fri, Oct 23, 2015 at 12:37:06PM +0100, David Woodhouse wrote:
> It's more than that a?? 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 a?? 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@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2015-10-23 12:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-20 15:52 [RFC PATCH] iommu/vt-d: Add IOTLB flush support for kernel addresses David Woodhouse
2015-10-20 16:03 ` Joerg Roedel
2015-10-20 16:17 ` David Woodhouse
2015-10-23 10:20 ` Joerg Roedel
2015-10-23 10:33 ` David Woodhouse
2015-10-23 11:03 ` Joerg Roedel
2015-10-23 11:37 ` David Woodhouse
2015-10-23 12:42 ` Joerg Roedel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151023124257.GB27420@8bytes.org \
--to=joro@8bytes.org \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=sudeep.dutt@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).