linux-kernel - Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface

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: <20200610081011.GA2689@bogus>
Date:   Wed, 10 Jun 2020 09:10:11 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Will Deacon <will@...nel.org>
Cc:     devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, Marc Zyngier <maz@...nel.org>,
        tabba@...gle.com, qwandor@...gle.com, ardb@...nel.org
Subject: Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface

Hi Will,

On Wed, Jun 10, 2020 at 08:57:12AM +0100, Will Deacon wrote:
> Hi Sudeep,
>
> On Tue, Jun 09, 2020 at 06:41:23PM +0100, Sudeep Holla wrote:

[...]

> >
> > Agreed, I added for RxTx buffers and initially to build the parent/child
> > hierarchy for all users of the driver. Initially I was assuming only
> > in-kernel users and now I agree we should avoid any in kernel users if
> > possible.
> >
> > One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the
> > information to the caller. So we need to have established buffers before
> > that and one of the reason you don't find that in this RFC. I dropped that
> > too which I wanted initially.
>
> Ok, sounds like we should at least get to a position where we can enumerate
> things, though.
>

Yes.

[...]

> >
> > OK, IIUC that covers mostly KVM implementation. We still need a way to
> > share the RxTx buffer info to the partitions and DT/ACPI(?) is one
> > possible way. Based on you comment about not needing DT node, do you have
> > any other way to communicate the buffer info to the partitions ?
>
> This is only a concern if KVM chooses to provide the Rx/Tx buffer pair
> though, right? If we punt that down the road for the moment, then we can
> just rely on FFA_RXTX_MAP for now.
>

Ah OK, I was under the assumption that we didn't want to use FFA_RXTX_{,UN}MAP

[...]

> >
> > I am confused a bit. When you refer drivers above, are you referring to
> > drivers in host kernel(hypervisor) or in the partitions. I fail to
> > imagine need for the former.
>
> I'm referring to in-kernel users in the host kernel. For KVM-managed guests,
> we may not need these, although signalling things like system shutdown might
> be better off done without relying on userspace. But my point is really that
> separating the buffer management from the users means we can serialise
> consumers, whether they are in-kernel or out in userspace.
>

Understood.

> > > What do you think, and do you reckon you can spin a cut-down driver that
> > > implements the common part of the logic (since I know you've written much
> > > of this code already)?
> > >
> >
> > I am not sure if I am aligned with your thoughts on the buffer sharing
> > yet.
>
> Ok, please let me know if you have any more questions.
>

None ATM. As I mentioned I had ruled out RXTX_{,UN}MAP which was my
misunderstanding.

--
Regards,
Sudeep