Date:   Tue, 21 Mar 2023 12:55:54 -0400
From:   Gregory Price <gregory.price@memverge.com>
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Gregory Price <gourry.memverge@gmail.com>,
        linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
        oleg@redhat.com, avagin@gmail.com, peterz@infradead.org,
        luto@kernel.org, krisman@collabora.com, corbet@lwn.net,
        shuah@kernel.org, Mark Rutland <mark.rutland@arm.com>,
        Will Deacon <will@kernel.org>
Subject: Re: [PATCH v13 1/3] syscall_user_dispatch: helper function to
 operate on given task
Message-ID: <ZBnhmtvlenY15P32@memverge.com>
References: <20230301205843.2164-1-gregory.price@memverge.com>
 <20230301205843.2164-2-gregory.price@memverge.com>
 <87cz529kni.ffs@tglx>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87cz529kni.ffs@tglx>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?j+di4o66tgHwGrSva+bvVbIrjBTePb/GwEZEmwrPqoK8RIi/X3nxFadkb5NS?=
 =?us-ascii?Q?s6NBbtM3frniljQ4xjpr+pOEllhrSvXu8hThPq1+kREtotz9LgMNbA43Zy/e?=
 =?us-ascii?Q?rhqBhTMKF/7gGYwnOW5Go4XFWxM7Rc7Zsvd+NWwLyzpCVq0PSIwxqzvOhq5Y?=
 =?us-ascii?Q?8h9A2idEvEOVY7Jq9ut2EtFBCYCUfyDbqTHblsdSMCBk/INaT1u7GJPH/b1d?=
 =?us-ascii?Q?MmrIN4iZ2VjX8z6ffXrq23bwzF1DMnnHJ+yho7idhWK3HwTJ6SciBPFGvS4W?=
 =?us-ascii?Q?fX7jtZozR16KzlanZ6ul6PqhMDWTkHFdOC+hEu32j0R6IJpdGsJZKd79ikdI?=
 =?us-ascii?Q?2BF5OTKEQQHWTDDmZHKj360pVitqeKjG+xwVyWNb803NGDzMHUriTK83cMTt?=
 =?us-ascii?Q?BCdpgwI/fG65oHbun/fs1sHphZHA+7nPDkZ2AF9KcNqtp8+RiQ1nIJGFdtgj?=
 =?us-ascii?Q?DHc+trNEJZNw50yeYCDLzLJWUcgbu6VDNKUzU+hBusHC7P4soszklUKmazt+?=
 =?us-ascii?Q?3BnDrhqIJ1luUeUytwBYBCAlYC7I0wa+rLhUF0C9D3qv1E7t4RKGqmes4/wN?=
 =?us-ascii?Q?VUBtgdtCF/vy5jrX7ou03+bt1x95Vu0Tx/FzAPE1ybQ2emdrIVcJlLZ9VDYO?=
 =?us-ascii?Q?sT7UrdiaOsfyKaqbLe7+3jFXVrsnO7Iu5fmOe6/MmlkzG7der7jSqfslPleG?=
 =?us-ascii?Q?y4ayl0mn8h7vbI+89taXwDXaAb2gUM140c2GEejThTxKGu43usR3dIW0rRTR?=
 =?us-ascii?Q?M7OlTfWhiqSXLZz83nhT+Myk5L6Y7Ikp24HXZvXnN/QZNPIFG/8E00zXwacv?=
 =?us-ascii?Q?/x7qUndJ+t+uWTaLyQQnr+iE/7SLZ4KBU5ZGZ1bcAyv76CoA9SHaXRYl39W6?=
 =?us-ascii?Q?kECF6T0YMEjsBtc7NdA83VroIeKy6z+bbmofwl5CpSl+pMTKEJMo5P3FxoR0?=
 =?us-ascii?Q?S5z0qOOzwWBz9VRV4qNttewevdG6hHIb5UN3qjGsCFodb37z3gLhRnQHI0mv?=
 =?us-ascii?Q?8IYkOCyoxJgcf2bHBHm0aNceN2/ThdHMiYjFhAn6Wut7xUivBG6zu7Gr5fEt?=
 =?us-ascii?Q?2NxJmcrazSWJy1Re0rGD9Sm8GxnpXDZEpK/ZOoIwEtm9rrJUTt5f30PJjL0f?=
 =?us-ascii?Q?WOTO9TJcYgy/PVWizaugizW0LDocuiSp9ak9v/ZYbvVQWMAxvqUTIvtIgwoa?=
 =?us-ascii?Q?EjVoUlR9Qed4UjjP5mejK2Zb5kIrzhAB+K2yz/IERsn/Ubz6AwtaSwB61Pf2?=
 =?us-ascii?Q?XGJ3xY+wToPhaNtBTi0A2bgTFyqlM7zsKcoW5VGqs+QSm8k5IxfN1//vepZd?=
 =?us-ascii?Q?fsHWAnh6mJon5fFPdJCSAsBic9HqbZmq479352zUQ8Dj5YnX2C7wofFnR3IR?=
 =?us-ascii?Q?Xx3ozGYKRmQcEm606FB7oEEDPjBjPlyLKHrfQm27IjR//Z0/pkbuR50ztLGb?=
 =?us-ascii?Q?/DQWHzFiGPaQXzzYOQ06m5uNtzuT44mqNlRN+yK8xsAWEHn/mnT3afVJ762J?=
 =?us-ascii?Q?j93APqDVfcpMn9QMs5ASn4QlLqXOQH6dE46c0GrD92esTNBe79rtlbNqo78W?=
 =?us-ascii?Q?CqaFPbsFCPn6hlCE7cvBJBUs4ToPivQ9UR5HDauuceEYYwXp5ewxKZ/r6bZ+?=
 =?us-ascii?Q?oTdWlwCFvHR3FEAxEETvu+w=3D?=
X-OriginatorOrg: memverge.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c3824a29-f6a8-467a-61dc-08db2a2d2709
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR17MB5512.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2023 16:56:02.2065
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5c90cb59-37e7-4c81-9c07-00473d5fb682
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: xjulXtamMbjyJK5qc/J8E5UAENWoj5eWgt7SoqmyrRDHFAdAYW5DTw+NtnUNSjEKMcVP7D5sbdbO4I279GULZVeXr1jFBx2U7Lr62s1OaNQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR17MB5996
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Mar 21, 2023 at 04:41:37PM +0100, Thomas Gleixner wrote:
> Gregory!
> 
> On Wed, Mar 01 2023 at 15:58, Gregory Price wrote:
> > +static int task_set_syscall_user_dispatch(struct task_struct *task, unsigned long mode,
> > +					  unsigned long offset, unsigned long len,
> > +					  char __user *selector)
> >  {
> >  	switch (mode) {
> >  	case PR_SYS_DISPATCH_OFF:
>         ...
> 
> 	case PR_SYS_DISPATCH_ON:
> 		if (selector && !access_ok(selector, sizeof(*selector)))
> 			return -EFAULT;
> 
> I'm not seing how this can work on ARM64 when user pointer tagging is
> enabled in the tracee, but not in the tracer. In such a case, if the
> pointer is tagged, access_ok() will fail because access_ok() wont untag
> it.
> 
> Thanks,
> 
>         tglx

I see that untagged_addr(x) is available to clear tags, I don't see an
immediate issues with converting to:

!access_ok(untagged_addr(selector), sizeof(*selector))

In both the tracee calling the prctl interface and the tracer calling
the ptrace interface the tag will be cleared, which appears to be the
intended effect.  Just want a sanity check before i push it through, as
I'm not overly familiar with the ARM/tagging ecosystem.

Seems reasoanble that this change should live with this commit, so i'll
plan to squash and push it up if the change is reasonable.

Thanks for your input
~Gregory