linux-kernel - Re: [PATCH 6/6] misc: fastrpc: Restrict untrusted app to attach to privileged PD

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: <fde72c34-889a-4dd7-a1cb-fec1d1b3c6a3@linaro.org>
Date: Thu, 15 Aug 2024 14:30:19 +0100
From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To: "Selvaraj, Joel (MU-Student)" <jsbrq@...souri.edu>,
 "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Ekansh Gupta <quic_ekangupt@...cinc.com>, stable <stable@...nel.org>,
 Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Subject: Re: [PATCH 6/6] misc: fastrpc: Restrict untrusted app to attach to
 privileged PD



On 15/08/2024 03:34, Selvaraj, Joel (MU-Student) wrote:
> Hi Srinivas Kandagatla and Ekansh Gupta,
> 
> On 6/28/24 06:45, srinivas.kandagatla@...aro.org wrote:
>> From: Ekansh Gupta <quic_ekangupt@...cinc.com>
>>
>> Untrusted application with access to only non-secure fastrpc device
>> node can attach to root_pd or static PDs if it can make the respective
>> init request. This can cause problems as the untrusted application
>> can send bad requests to root_pd or static PDs. Add changes to reject
>> attach to privileged PDs if the request is being made using non-secure
>> fastrpc device node.
>>
>> Fixes: 0871561055e6 ("misc: fastrpc: Add support for audiopd")
>> Cc: stable <stable@...nel.org>
>> Signed-off-by: Ekansh Gupta <quic_ekangupt@...cinc.com>
>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
>> ---
>>    drivers/misc/fastrpc.c      | 22 +++++++++++++++++++---
>>    include/uapi/misc/fastrpc.h |  3 +++
>>    2 files changed, 22 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
>> index 5680856c0fb8..a7a2bcedb37e 100644
>> --- a/drivers/misc/fastrpc.c
>> +++ b/drivers/misc/fastrpc.c
>> @@ -2087,6 +2087,16 @@ static int fastrpc_req_mem_map(struct fastrpc_user *fl, char __user *argp)
>>    	return err;
>>    }
>>    
>> +static int is_attach_rejected(struct fastrpc_user *fl)
>> +{
>> +	/* Check if the device node is non-secure */
>> +	if (!fl->is_secure_dev) {
>> +		dev_dbg(&fl->cctx->rpdev->dev, "untrusted app trying to attach to privileged DSP PD\n");
>> +		return -EACCES;
>> +	}
>> +	return 0;
>> +}
> 
> This broke userspace for us. Sensors stopped working in SDM845 and other
> qcom SoC devices running postmarketOS. Trying to communicate with the
> fastrpc device just ends up with a permission denied error. This was
> previously working. I am not sure if this is intended. Here are my two
> observations:
> 
> 1. if change the if condition to
> 
> `if (!fl->is_secure_dev && fl->cctx->secure)`
> 
> similar to how it's done in fastrpc's `is_session_rejected()` function,
> then it works. But I am not sure if this is an valid fix. But currently,
> fastrpc will simply deny access to all fastrpc device that contains the
> `qcom,non-secure-domain` dt property. Is that the intended change?
> Because I see a lot of adsp, cdsp and sdsp fastrpc nodes have that dt
> property.
> 
> 2. In the `fastrpc_rpmsg_probe()` function, it is commented that,
> 
> "Unsigned PD offloading is only supported on CDSP"
> 
> Does this mean adsp and sdsp shouldn't have the `qcom,non-secure-domain`
> dt property? In fact, it was reported that removing this dt property and
> using the `/dev/fastrpc-sdsp-secure` node instead works fine too. Is
> this the correct way to fix it?

Yes, this is the ideal way to fix this, Audio DSP and Sensor DSPs are by 
default secure DSP's.

usage of "qcom,non-secure-domain" has been abused on all the platforms 
as the device tree bindings are not enforcing this checks to any new 
device tree entries. This needs fixing properly.

Ideally this patch has to fix the existing dts and update bindings to 
reflect that.

Sorry this has been over looked!

On the library side that you are using consider non-secure node as 
fallback only when secure node is missing.

given the mess with the current state of patch, reverting sounds good 
for me to start with.

--srini

> 
> I don't know much about fastrpc, just reporting the issue and guessing
> here. It would be really if this can be fixed before the stable release.
> 
> Thank you,
> Joel Selvaraj
> 
>