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]

Message-ID: <20200615164814.GG46361@C02TC1ARHF1T>
Date:   Mon, 15 Jun 2020 17:48:14 +0100
From:   Achin Gupta <achin.gupta@....com>
To:     Will Deacon <will@...nel.org>
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:55:49PM +0100, Will Deacon wrote:
> 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.

Sure. I am realising the need to maintain the distinction :o)

>
> > > > 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.

Ok. Good to know this.

>
> > 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.

Agree.

>
> > 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.

Fair point!

cheers,
Achin

>
> Will