On 27 December 2017 at 17:24, Jens Wiklander jens.wiklander@linaro.org wrote:
Currently I have the PoC for proposed approach. Right now it halfly consist of hacks, but anyways, I'm able to run xtest in two domains in parallel. And it even passes :)
Congrats! :-)
Thanks!
If someone is really interested, then you can find this PoC at [1]. But it is in very pity state. I'm reworking it shape into something that can be pushed for a review.
And so I have a question. One of my changes introduces new VA space, where I map whole secure RAM. This simplifies guests pagetables management and some other tasks. Something similar is done in the pager code, but pager creates alias mappings in runtime, only for pages that it want to access. But for me it is easier to have a static view of a whole secure RAM, than to remap needed pages in runtime. So, this is my question: is that design decision in pager was intentional? Like, from security standpoint it is better not to have whole secure RAM mapped or something like that...
The pager does that to avoid leaving aliases of pages read-write enabled while read-only-exec at the place where it's used.
Ah, I see.
There are two options before me: I can leave whole secure RAM mapped and make pager to use this mapping, or I can make my code to behave like pager (i.e. map needed pages dynamically).
I think you should map needed pages dynamically.
Yeah, I think that it is more fits into OP-TEE way.
Also I'm not that happy about tagging __kdata and __kbss directly in the code, it's easy to miss applying one. The way we're partitioning the memory for the pager and init code could be applied here too. That isn't 100% robust either, but it usually results in build error instead of some hard to find corruption. If you don't feel to comfortable with implementing that yourself I can do that once everything else is in place.
I have concerns there. In pager case, mistake in partitioning would lead to crash or to bloated pager section. But in case of virtualization this will lead to hard-to-catch problems with isolation.
Imagine that during automatic partitioning guest-related symbol (e.g. sessions list) will go into shared space. This kind of bug will be revealed only if guests will issue simultaneous calls to OP-TEE. I can imagine more subtle cases, where problem will be not so obvious, but can lead to problems with isolation.
Thus, I decided to use explicit tagging. In this case you at least see what are you doing. Also, approach "explicitly tell what belongs to OP-TEE core" will ensure that any new symbols will go into guest sections.