LWN: Comments on "KVM for Android"

KVM for Android

mountainlion0523 — Wed, 10 Nov 2021 02:53:20 +0000

What distinguishes Protected KVM with lowvisor in nVHE?
before VHE, there was already a lowvisor which does handle hypervisor requests and it runs on EL2, it seems very similiar with Protected KVM

KVM for Android

jserra — Wed, 27 Jan 2021 14:26:27 +0000

How does this fit within ARM Trusted Frmware(ATF) architecture. Will ATF no longer be used?
I'm assuming that ATF's BL3 that implements the SMC interface will bot be running at EL3. In practice this means Trustzone will not be used at all?
Will your EL3 code also implement PSCI?
What about Android's Keymaster TA that runs in the TEE? Also moved to a KVM guest?

KVM for Android

rmayr — Fri, 20 Nov 2020 07:49:24 +0000

Yes, that is one of the main drives - TrustZone (where most of this code lives today) is highly privileged and opaque, and TEE implementations certainly have had their share of vulnerabilities. Sandboxing that code in VMs helps the whole system and therefore users.

KVM for Android

wildea01 — Mon, 16 Nov 2020 11:09:49 +0000

Thanks for the excellent write-up, Jake!

One thing I feel that I should clarify is my use of the term "VMM", which I used to refer to the _userspace_ component of KVM on the host (e.g. QEMU, crosvm or kvmtool). This always lives in userspace, regardless of VHE/nVHE. The primary difference between VHE and nVHE is that the host _kernel_ runs at EL2 or EL1 respectively. With nVHE, EL2 contains some small "world-switch" code installed by the kernel and it is this layer that we are working to extend for Protected KVM.

Will

KVM for Android

sbaugh — Fri, 13 Nov 2020 15:45:19 +0000

Protecting the Android system and the user could be done by running these DRM blobs under normal KVM. The "protected KVM" project isn't necessary to achieve that - regular KVM would work fine.

"Protected KVM" is only necessary if you don't want the Android kernel and user to have a higher privilege level than the DRM blobs - which is a requirement specific to DRM and anti-user things like it.

KVM for Android

mzyngier — Fri, 13 Nov 2020 13:40:34 +0000

That's indeed the goal. We can't really get rid of it (apparently, people really want 4K N*****x on a 15cm screen), but we can move that code to a place where it won't risk harming the rest of the system if it goes mad.

At least, that's the plan.

KVM for Android

jezuch — Fri, 13 Nov 2020 12:12:08 +0000

That's how I read it too. Currently it's forced upon the user and runs in a super-privileged context with no oversight at all. Sandboxing this code can only benefit the user. (Though I agree that removing it would be best.)

KVM for Android

smurf — Fri, 13 Nov 2020 07:48:21 +0000

> digital rights management

Well … actually I think the defectivebydesign.org people have gotten that right when they renamed the acronym to Digital Restrictions Management.

There's no rights being "managed" here. Only withheld.

KVM for Android

adam820 — Thu, 12 Nov 2020 15:32:53 +0000

I suppose that depends on how you read the context of that whole sentence. It sounded to me like the goal was to protect the Android system (and thus, the user) from whatever this third-party code is doing, since there's no control over it. Not necessarily to enable that code (it's enabled regardless).

KVM for Android

sbaugh — Thu, 12 Nov 2020 15:19:53 +0000

>third-party code for digital rights management (DRM), various opaque binary blobs, cryptographic code, and so on

So in the end, the "security" gains of the "protected KVM" project are securing the device against the user, not actual improved security for the user. That's pretty disappointing. When people talk about shrinking the TCB, and how that improves security, I generally take them at their word, not as this kind of masked anti-user effort...

KVM for Android

pabs — Thu, 12 Nov 2020 07:38:45 +0000

Would this work allow for running the distros in VMs on Android devices?