On 7/12/19 9:48 PM, Thomas Gleixner wrote:
On Fri, 12 Jul 2019, Alexandre Chartre wrote:
On 7/12/19 5:16 PM, Thomas Gleixner wrote:
On Fri, 12 Jul 2019, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
And then we've fully replaced PTI.
So no, they're not orthogonal.
Right. If we decide to expose more parts of the kernel mappings then that's
just adding more stuff to the existing user (PTI) map mechanics.
If we expose more parts of the kernel mapping by adding them to the existing
user (PTI) map, then we only control the mapping of kernel sensitive data but
we don't control user mapping (with ASI, we exclude all user mappings).
What prevents you from adding functionality to do so to the PTI
implementation? Nothing.
Again, the underlying concept is exactly the same:
1) Create a restricted mapping from an existing mapping
2) Switch to the restricted mapping when entering a particular execution
context
3) Switch to the unrestricted mapping when leaving that execution context
4) Keep track of the state
The restriction scope is different, but that's conceptually completely
irrelevant. It's a detail which needs to be handled at the implementation
level.
What matters here is the concept and because the concept is the same, this
needs to share the infrastructure for #1 - #4.
You are totally right, that's the same concept (page-table creation and switching),
it is just used in different contexts. Sorry it took me that long to realize it,
I was too focus on the use case.
It's obvious that this requires changes to the way PTI works today, but
anything which creates a parallel implementation of any part of the above
#1 - #4 is not going anywhere.
This stuff is way too sensitive and has pretty well understood limitations
and corner cases. So it needs to be designed from ground up to handle these
proper. Which also means, that the possible use cases are going to be
limited.
As I said before, come up with a list of possible usage scenarios and
protection scopes first and please take all the ideas other people have
with this into account. This includes PTI of course.
Once we have that we need to figure out whether these things can actually
coexist and do not contradict each other at the semantical level and
whether the outcome justifies the resulting complexity.
After that we can talk about implementation details.
Right, that makes perfect sense. I think so far we have the following scenarios:
- PTI
- KVM (i.e. VMExit handler isolation)
- maybe some syscall isolation?
I will look at them in more details, in particular what particular mappings they
need and when they need to switch mappings.
And thanks for putting me back on the right track.
alex.
This problem is not going to be solved with handwaving and an ad hoc
implementation which creates more problems than it solves.
Thanks,
tglx
