On 02.07.19 13:59, Jan Hoogerbrugge wrote:
Hi,
For kernel protection purposes I want to make kernel read-only memory
pages also read-only in stage 2 so that if malicious code in the kernel tries
to modify read-only memory by first making it writable in stage 1 that then
a read-only stage 2 page table entry will catch this.
I want to do this for arm64.
How to do this? Where is the 2nd stage table constructed? What kind of exception
can I expect when the kernel writes to data via a stage 1 access where writes
are allowed followed by a stage 2 where writes are not allowed?
Jailhouse is statically configured. Therefore, you define the 2nd-stage table
via the .cell configuration, and this is applied during cell creation (or, for
the root cell, when enabling jailhouse). Translating 1st-stage permissions to
the second stage sound like you will need a lot of dynamics.
In addition, the Jailhouse paging subsystem is not prepared for runtime page
table changes, except for those affecting only the per-cpu part of the table.
That simplifies the code and even allows for static validation of the majority
of page table entries.
Regarding exception trapping: We do not intercept regular guest exceptions
because there is no need to (and it would be extremely slow). It is
architecturally doable, though (like in old shadow MMU times).
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/d0fa5684-2c3a-9b6d-0629-dd919716bec1%40siemens.com.
For more options, visit https://groups.google.com/d/optout.
