On 5/25/2023 6:25 AM, Mickaël Salaün wrote:
On 24/05/2023 23:04, Trilok Soni wrote:
On 5/5/2023 8:20 AM, Mickaël Salaün wrote:
Hi,
This patch series is a proof-of-concept that implements new KVM features
(extended page tracking, MBEC support, CR pinning) and defines a new
API to
protect guest VMs. No VMM (e.g., Qemu) modification is required.
The main idea being that kernel self-protection mechanisms should be
delegated
to a more privileged part of the system, hence the hypervisor. It is
still the
role of the guest kernel to request such restrictions according to its
Only for the guest kernel images here? Why not for the host OS kernel?
As explained in the Future work section, protecting the host would be
useful, but that doesn't really fit with the KVM model. The Protected
KVM project is a first step to help in this direction [11].
In a nutshell, KVM is close to a type-2 hypervisor, and the host kernel
is also part of the hypervisor.
Embedded devices w/ Android you have mentioned below supports the host
OS as well it seems, right?
What do you mean?
I think you have answered this above w/ pKVM and I was referring the
host protection as well w/ Heki. The link/references below refers to the
Android OS it seems and not guest VM.
Do we suggest that all the functionalities should be implemented in the
Hypervisor (NS-EL2 for ARM) or even at Secure EL like Secure-EL1 (ARM).
KVM runs in EL2. TrustZone is mainly used to enforce DRM, which means
that we may not control the related code.
This patch series is dedicated to hypervisor-enforced kernel integrity,
then KVM.
I am hoping that whatever we suggest the interface here from the Guest
to the Hypervisor becomes the ABI right?
Yes, hypercalls are part of the KVM ABI.
Sure. I just hope that they are extensible enough to support for other
Hypervisors too. I am not sure if they are on this list like ACRN / Xen
and see if it fits their need too.
Is there any other Hypervisor you plan to test this feature as well?
# Current limitations
The main limitation of this patch series is the statically enforced
permissions. This is not an issue for kernels without module but this
needs to
be addressed. Mechanisms that dynamically impact kernel executable
memory are
not handled for now (e.g., kernel modules, tracepoints, eBPF JIT),
and such
code will need to be authenticated. Because the hypervisor is highly
privileged and critical to the security of all the VMs, we don't want to
implement a code authentication mechanism in the hypervisor itself
but delegate
this verification to something much less privileged. We are thinking
of two
ways to solve this: implement this verification in the VMM or spawn a
dedicated
special VM (similar to Windows's VBS). There are pros on cons to each
approach:
complexity, verification code ownership (guest's or VMM's), access to
guest
memory (i.e., confidential computing).
Do you foresee the performance regressions due to lot of tracking here?
The performance impact of execution prevention should be negligible
because once configured the hypervisor do nothing except catch
illegitimate access attempts.
Yes, if you are using the static kernel only and not considering the
other dynamic patching features like explained. They need to be thought
upon differently to reduce the likely impact.
Production kernels do have lot of tracepoints and we use it as feature
in the GKI kernel for the vendor hooks implementation and in those cases
every vendor driver is a module.
As explained in this section, dynamic kernel modifications such as
tracepoints or modules are not currently supported by this patch series.
Handling tracepoints is possible but requires more work to define and
check legitimate changes. This proposal is still useful for static
kernels though.
Separate VM further fragments this
design and delegates more of it to proprietary solutions?
What do you mean? KVM is not a proprietary solution.
Ah, I was referring the VBS Windows VM mentioned in the above text. Is
it open-source? The reference of VM (or dedicated VM) didn't mention
that VM itself will be open-source running Linux kernel.
For dynamic checks, this would require code not run by KVM itself, but
either the VMM or a dedicated VM. In this case, the dynamic
authentication code could come from the guest VM or from the VMM itself.
In the former case, it is more challenging from a security point of view
but doesn't rely on external (proprietary) solution. In the latter case,
open-source VMMs should implement the specification to provide the
required service (e.g. check kernel module signature).
The goal of the common API layer provided by this RFC is to share code
as much as possible between different hypervisor backends.
Do you have any performance numbers w/ current RFC?
No, but the only hypervisor performance impact is at boot time and
should be negligible. I'll try to get some numbers for the
hardware-enforcement impact, but it should be negligible too.
Thanks. Please share the data once you have it ready.
---Trilok Soni
