linux-kernel - Re: [PATCH v5 3/4] remoteproc: qcom: Make secure world call for mem ownership switch

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] [day] [month] [year] [list]

Date:   Wed, 7 Jun 2017 14:20:26 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     "Dwivedi, Avaneesh Kumar (avani)" <akdwived@...eaurora.org>
Cc:     sboyd@...eaurora.org, agross@...eaurora.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-remoteproc@...r.kernel.org
Subject: Re: [PATCH v5 3/4] remoteproc: qcom: Make secure world call for mem
 ownership switch

On Wed 07 Jun 09:27 PDT 2017, Dwivedi, Avaneesh Kumar (avani) wrote:

> 
> 
> On 6/2/2017 11:25 PM, Bjorn Andersson wrote:
> > On Thu 01 Jun 14:42 PDT 2017, Dwivedi, Avaneesh Kumar (avani) wrote:
> > 
> > > Hi Bjorn,
> > > 
> > > Thanks lot many for such a blazing fast response :)
> > > 
> > > regarding your points.
> > > 
> > > a- Do you mean caller's of q6v5_xfer_mem_ownership() should pass two
> > > additional inputs i.e. *next_perm and *next_vmid
> > > 
> > You have two cases; assign to HLOS and assign to MSS, so I imagine that
> > you pass a single indicator of which you want to assign. I.e. rather
> > than looking at what the current state is and flipping you pass the
> > conditional of that if statement as a parameter.
> OK
> > 
> > >      and that based on successful return of qcom_scm_assign () they should be
> > > treated as *current_perm and *current_vmid
> > > 
> > Instead of your index, you take a "int *curr_perms", which you use as
> > the current vmid list and you assign at the end of the function (like
> > you do today).
> > 
> > So to transfer the ownership to the MSS you would make a function call
> > like:
> > 
> > ret = q6v5_xfer_mem_ownership(qproc, &qproc->mpss_owner, ..., true);
> > 
> > mpss_owner would have to be initialize to HLOS before calling this, but
> > will always be holding the current value.
> i am not finding compelling enough region to carry an input pointer to hold
> current ownership
> specially when i am carrying a boolean flag to check whether next->vmid will
> be MSS or HLOS
> I mean where am i going to use this current owner info in mss rproc driver,
> i am yet not getting enough reason.
> while the local array did job of maintaining and flipping the ownership
> based on info if which image ownership transfer is being called.
> 

As far as I can see your patch works fine, every code path will end up
calling xfer_mem() an even number of times, meaning that when we're done
the ownership is on the HLOS side.

But the reason I don't like this flip-flop mechanism is that it forces
us to _always_ exit every code path with an even number of calls.
Meaning that if we ever refactor any of this code and accidentally add
another flip, we will start seeing "random" crashes. This is the reason
why I want the code to be explicit in "transfer permission to X".

The reason for not using the "destination owner" for figuring out the
current owner is that in the even that you call "transfer permission to
HLOS" twice in a row, you will call TZ saying that the current ownership
is MSS and the call will fail. In this case the calling code has no
chance to know if we failed because we have called xfer_mem() an odd
number of times or something else and although we are good (HLOS is
owner) we have to treat this as a fatal error.

So, it's all about future maintainability - not about it currently
working.

Regards,
Bjorn