On 15.08.20 03:31, Ralf Ramsauer wrote:
On 8/14/20 8:13 PM, Jan Kiszka wrote:
If we have a universal binary, there will be a jailhouse disable will be
present in the beginning. Once we decide freeze the configuration, drop
it. If we make those things compile-time configurable, then it has
potential to become a variant hell.
Dropping significant code chunks from a root-less jailhouse.bin would be
a valuable reason for such a config variant. You do not have to argue
over things that are provably not there.
With my approach, things are (provably) not there in the operative
phase. It depends when you want to attest your system. In the same way,
you could also argue that Linux, U-boot, the firmware, whatever has been
there before you made your attest.
What are the parts you could drop during compile time?
For system partitioning / cell creation, you definitely need to execute
the code at least once - you can not drop it during compile time.
But after execution, you can drop it. In the same way, you can drop
init_early, ... and others. The only part that you could drop during
compile time would probably be the whole disabling logic.
Let me try to show what I had in mind:
https://github.com/lfd/jailhouse/tree/detention/rfc
That's a very early hack of what I was thinking about. The idea is as
follows: Simply lock access to the hypercall subsystem, after the new
detention hypercall was issued. With this, we can remove everything,
that is only reachable from the interface. Runs on Qemu.
For the Intel version of the hypervisor, before that patch, the .text
section contained 48182 bytes, with that patch, 40616 byte remain in
.text, the rest can be dropped. 16% less assembly, and I'm sure we can
find way more routines that can be annotated: init stuff, pagers, ...
That's a first step, but I'm sure much more can be done when there is no
concept of a root cell in the first place. It means, e.g., that cell
creation would try to stealing from a root cell anymore. All that code
would not be there in the first place.
My approach to this would be aggressively hacking all unneeded code (and
data) away and then look for how to encapsulate that removal best for
the classic Jailhouse use case. We could still decide afterwards if
there is a way to have it run-time dropped, but I'm almost sure that the
safety case will benefit a lot for build-time dropping option. So this
will come as well.
Ah by the way, what I realised during my experiments: The .text section
of Jailhouse is RW mapped. I wondered that I didn't receive an exception
when I tried to overwrite code. Is that intended?
I don't recall any code-patching right now, so we can likely make that
read-only. It was just simpler to handle the whole hypervisor blob as
one thing. If we start coloring the hypervisor, possibly replicating the
text section into each color, the extra section identification logic
would likely come for free.
Jan
--
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/fe0d27f0-cb8b-871e-c8e8-c898e4436570%40web.de.
