linux-kernel - Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 15 Jun 2020 12:55:49 +0100
From:   Will Deacon <will@...nel.org>
To:     Achin Gupta <achin.gupta@....com>
Cc:     Rob Herring <robh@...nel.org>, Sudeep Holla <Sudeep.Holla@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Marc Zyngier <maz@...nel.org>, nd <nd@....com>
Subject: Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for
 non-secure VM partitions

On Mon, Jun 15, 2020 at 12:42:20PM +0100, Achin Gupta wrote:
> On Mon, Jun 15, 2020 at 10:51:34AM +0100, Will Deacon wrote:
> > On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote:
> > > Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to
> > > determine partition properties. It assumes that EL2 SW has already read each
> > > partition's manifest and will reply to this ABI.
> > >
> > > IIUC, with protected KVM, this information will have to be a part of the
> > > manifest that the KVM host consumes.
> >
> > The host does not consume the manifest directly -- instead, the bootloader
> > will use the manifest to populate these DT nodes. Again, these are *only*
> > for non-secure virtual partitions which are to be managed by KVM.
> 
> Yes. Understand and agree. Manifest is an overloaded term. I was using it to
> describe the DT nodes that the host will consume.

Hmm, I think that conflates two things though because only the partitions
managed by KVM will have DT nodes.

> > > Separate topic, protected KVM does not get dibs on the manifest and it relies on
> > > the KVM host to specify the address ranges for each partition? Does this not
> > > mean that the KVM host can control the physical address space each partition
> > > sees. This seems contrary to the isolation guarantees that protected KVM must
> > > provide?
> >
> > The host is trusted during early boot, and gives up this trust after
> > initialising EL2 fully. So roughly speaking, we:
> >
> > 	* Boot at EL2 and install a shim
> > 	* Drop down to EL2 and start the host kernel
> > 	* Before some initialisation (DT parsing, SMP bringup, etc)
> > 	* Init KVM by calling back up to EL2 to install the full hypervisor
> >
> > At that point, the EL1 host is no longer trusted and the last call
> > effectively "locks it out" from EL2.
> 
> Ok. Protected KVM (PKVM) must create S2 tables when asked to setup a partition
> by the Host. My main concern is if PKVM must trust the Host to provide the
> correct physical address space ranges for a partition?

Yes, but that all happens as part of KVM initialisation: the host parses
the DT nodes and memory reservations, and then passes this information
up to EL2.

> I guess your point is this is not a problem since PKVM can lock the Host out of
> those address ranges in any case?

It has to do this, regardless of how they are probed. Once KVM has
initialised, the host will have a stage-2 which limits it to the memory that
it is allowed to access.

> It is a bit counter intuitive that the Host gets to see and potentially
> manipulate information that was verified and extracted by the bootloader from
> the partition's manifest. This hapens before PKVM sees the same
> information. Can't put my finger on what could go wrong though. Depends upon the
> threat model too!

I think you're trying too hard to separate the host from the EL2 code during
early boot. Don't forget -- this is all part of the same binary payload that
is loaded and initially run at EL2. Having the host take care of early boot
/significantly/ reduces the amount of code at EL2, which has a very
clear security benefit.

Will