mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ekansh Gupta <quic_ekangupt@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: <srinivas.kandagatla@linaro.org>, <linux-arm-msm@vger.kernel.org>,
	<gregkh@linuxfoundation.org>, <quic_bkumar@quicinc.com>,
	<linux-kernel@vger.kernel.org>, <quic_chennak@quicinc.com>,
	stable <stable@kernel.org>
Subject: Re: [PATCH v3 8/9] misc: fastrpc: Restrict untrusted app to spawn signed PD
Date: Thu, 6 Jun 2024 12:52:15 +0530	[thread overview]
Message-ID: <becf237b-1f46-46cd-b196-fdfca35ef736@quicinc.com> (raw)
In-Reply-To: <7eygwrefc43aaqeihir3odjhdseeewweqvabvq6jg5bbmnhrkz@p33mhebq5v3w>



On 6/3/2024 3:32 PM, Dmitry Baryshkov wrote:
> On Mon, Jun 03, 2024 at 11:57:52AM +0530, Ekansh Gupta wrote:
>> On 5/31/2024 5:19 AM, Dmitry Baryshkov wrote:
>>> On Thu, May 30, 2024 at 03:50:26PM +0530, Ekansh Gupta wrote:
>>>> Some untrusted applications will not have access to open fastrpc
>>>> device nodes and a privileged process can open the device node on
>>>> behalf of the application. Add a check to restrict such untrusted
>>>> applications from offloading to signed PD.
>>>>
>>>> Fixes: 7f1f481263c3 ("misc: fastrpc: check before loading process to the DSP")
>>>> Cc: stable <stable@kernel.org>
>>>> Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
>>>> ---
>>>>   drivers/misc/fastrpc.c | 23 ++++++++++++++++++-----
>>>>   1 file changed, 18 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
>>>> index 73fa0e536cf9..32615ccde7ac 100644
>>>> --- a/drivers/misc/fastrpc.c
>>>> +++ b/drivers/misc/fastrpc.c
>>>> @@ -328,6 +328,7 @@ struct fastrpc_user {
>>>>   	int pd;
>>>>   	bool is_secure_dev;
>>>>   	bool is_unsigned_pd;
>>>> +	bool untrusted_process;
>>>>   	char *servloc_name;
>>>>   	/* Lock for lists */
>>>>   	spinlock_t lock;
>>>> @@ -1249,13 +1250,17 @@ static bool is_session_rejected(struct fastrpc_user *fl, bool unsigned_pd_reques
>>>>   		 * channel is configured as secure and block untrusted apps on channel
>>>>   		 * that does not support unsigned PD offload
>>>>   		 */
>>>> -		if (!fl->cctx->unsigned_support || !unsigned_pd_request) {
>>>> -			dev_err(&fl->cctx->rpdev->dev, "Error: Untrusted application trying to offload to signed PD\n");
>>>> -			return true;
>>>> -		}
>>>> +		if (!fl->cctx->unsigned_support || !unsigned_pd_request)
>>>> +			goto reject_session;
>>>>   	}
>>>> +	/* Check if untrusted process is trying to offload to signed PD */
>>>> +	if (fl->untrusted_process && !unsigned_pd_request)
>>>> +		goto reject_session;
>>>>   	return false;
>>>> +reject_session:
>>>> +	dev_dbg(&fl->cctx->rpdev->dev, "Error: Untrusted application trying to offload to signed PD\n");
>>>> +	return true;
>>>>   }
>>>>   static void fastrpc_mmap_remove_pdr(struct fastrpc_static_pd *spd)
>>>> @@ -1504,12 +1509,20 @@ static int fastrpc_init_create_process(struct fastrpc_user *fl,
>>>>   		goto err;
>>>>   	}
>>>> +	/*
>>>> +	 * Third-party apps don't have permission to open the fastrpc device, so
>>> Permissions depend on the end-user setup. Is it going to break if the
>>> user sets 0666 mode for fastrpc nodes?
>> If the root user sets 0666 for fastrpc nodes, it is expected that this check will get bypassed.
> So, any process will be trusted? This looks so Android-centric. Please come
> with a better way to define 'trusted'.
>
> On a typical UNIX system a used has multiple supplementary GIDs (which
> can be used to allow access to the devices) which have no relationship
> to the process effective GID. On a multi-user machine it might be
> logical that fastrpc nodes have separate group-id and group's read/write
> permissions. But then each of the users has their own unique 'effective'
> GID. Which of those should be using for computing the 'trusted' status?
Thanks for your suggestions, Dmitry. I am considering dropping this patch and system unsignedPD patch
from this series(due to the dependency). I'm redesigning the trusted-process term to make it more generic.
Planning to make it depend on the group IDs and have a check with both primary and supplementary GIDs
of the process. I'll share the design with you along with the changes once it's ready.
>
>>>> +	 * it is opened on their behalf by a priveleged process. This is detected
>>>> +	 * by comparing current PID with the one stored during device open.
>>>> +	 */
>>>> +	if (current->tgid != fl->tgid)
>>>> +		fl->untrusted_process = true;
>>> If the comment talks about PIDs, when why are you comparing GIDs here?
>> It should be GID, I'll update the comment in next spin.
>>
>>>> +
>>>>   	if (init.attrs & FASTRPC_MODE_UNSIGNED_MODULE)
>>>>   		fl->is_unsigned_pd = true;
>>>>   	if (is_session_rejected(fl, fl->is_unsigned_pd)) {
>>>> -		err = -ECONNREFUSED;
>>>> +		err = -EACCES;
>>>>   		goto err;
>>>>   	}
>>>> -- 
>>>> 2.43.0
>>>>


  reply	other threads:[~2024-06-06  7:22 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-30 10:20 [PATCH v3 0/9] Add missing features to FastRPC driver Ekansh Gupta
2024-05-30 10:20 ` [PATCH v3 1/9] misc: fastrpc: Add missing dev_err newlines Ekansh Gupta
2024-05-30 10:20 ` [PATCH v3 2/9] misc: fastrpc: Fix DSP capabilities request Ekansh Gupta
2024-05-30 10:59   ` Dmitry Baryshkov
2024-06-03  6:15     ` Ekansh Gupta
2024-06-03  9:54       ` Dmitry Baryshkov
2024-05-31  9:33   ` Srinivas Kandagatla
2024-06-03  7:05     ` Ekansh Gupta
2024-06-03  9:56       ` Dmitry Baryshkov
2024-05-30 10:20 ` [PATCH v3 3/9] misc: fastrpc: Fix memory corruption in DSP capabilities Ekansh Gupta
2024-05-30 11:00   ` Dmitry Baryshkov
2024-05-31  9:36   ` Srinivas Kandagatla
2024-06-03  6:23     ` Ekansh Gupta
2024-05-30 10:20 ` [PATCH v3 4/9] misc: fastrpc: Add static PD restart support Ekansh Gupta
2024-05-30 11:04   ` Dmitry Baryshkov
2024-06-03 10:53   ` Caleb Connolly
2024-06-04  9:23     ` Bharath Kumar V
2024-06-04  9:34       ` Dmitry Baryshkov
2024-06-04 11:24       ` Caleb Connolly
2024-05-30 10:20 ` [PATCH v3 5/9] misc: fastrpc: Redesign remote heap management Ekansh Gupta
2024-05-30 11:14   ` Dmitry Baryshkov
2024-06-03  6:25     ` Ekansh Gupta
2024-05-30 10:20 ` [PATCH v3 6/9] misc: fastrpc: Fix unsigned PD support Ekansh Gupta
2024-05-30 23:44   ` Dmitry Baryshkov
2024-05-30 10:20 ` [PATCH v3 7/9] misc: fastrpc: Restrict untrusted app to attach to privileged PD Ekansh Gupta
2024-05-30 23:46   ` Dmitry Baryshkov
2024-05-31  9:48   ` Srinivas Kandagatla
2024-05-30 10:20 ` [PATCH v3 8/9] misc: fastrpc: Restrict untrusted app to spawn signed PD Ekansh Gupta
2024-05-30 23:49   ` Dmitry Baryshkov
2024-06-03  6:27     ` Ekansh Gupta
2024-06-03 10:02       ` Dmitry Baryshkov
2024-06-06  7:22         ` Ekansh Gupta [this message]
2024-05-30 10:20 ` [PATCH v3 9/9] misc: fastrpc: Add system unsigned PD support Ekansh Gupta
2024-05-30 23:50   ` Dmitry Baryshkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=becf237b-1f46-46cd-b196-fdfca35ef736@quicinc.com \
    --to=quic_ekangupt@quicinc.com \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_bkumar@quicinc.com \
    --cc=quic_chennak@quicinc.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=stable@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®