On Tue, Apr 13, 2021 at 6:54 PM Mathieu Desnoyers
<[email protected]> wrote:
>
> ----- On Apr 13, 2021, at 12:22 PM, Eric Dumazet [email protected] wrote:
>
> > From: Eric Dumazet <[email protected]>
> >
> > Commit ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union,
> > update includes") added regressions for our servers.
> >
> > Using copy_from_user() and clear_user() for 64bit values
> > is suboptimal.
> >
> > We can use faster put_user() and get_user().
> >
> > 32bit arches can be changed to use the ptr32 field,
> > since the padding field must always be zero.
> >
> > v2: added ideas from Peter and Mathieu about making this
> > generic, since my initial patch was only dealing with
> > 64bit arches.
>
> Ah, now I remember the reason why reading and clearing the entire 64-bit
> is important: it's because we don't want to allow user-space processes to
> use this change in behavior to figure out whether they are running on a
> 32-bit or in a 32-bit compat mode on a 64-bit kernel.
>
> So although I'm fine with making 64-bit kernels faster, we'll want to keep
> updating the entire 64-bit ptr field on 32-bit kernels as well.
>
> Thanks,
>
So... back to V1 then ?
On Tue, Apr 13, 2021 at 6:57 PM Eric Dumazet <[email protected]> wrote:
>
> On Tue, Apr 13, 2021 at 6:54 PM Mathieu Desnoyers
> <[email protected]> wrote:
> >
> > ----- On Apr 13, 2021, at 12:22 PM, Eric Dumazet [email protected] wrote:
> >
> > > From: Eric Dumazet <[email protected]>
> > >
> > > Commit ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union,
> > > update includes") added regressions for our servers.
> > >
> > > Using copy_from_user() and clear_user() for 64bit values
> > > is suboptimal.
> > >
> > > We can use faster put_user() and get_user().
> > >
> > > 32bit arches can be changed to use the ptr32 field,
> > > since the padding field must always be zero.
> > >
> > > v2: added ideas from Peter and Mathieu about making this
> > > generic, since my initial patch was only dealing with
> > > 64bit arches.
> >
> > Ah, now I remember the reason why reading and clearing the entire 64-bit
> > is important: it's because we don't want to allow user-space processes to
> > use this change in behavior to figure out whether they are running on a
> > 32-bit or in a 32-bit compat mode on a 64-bit kernel.
> >
> > So although I'm fine with making 64-bit kernels faster, we'll want to keep
> > updating the entire 64-bit ptr field on 32-bit kernels as well.
> >
> > Thanks,
> >
>
> So... back to V1 then ?
Or add more stuff as in :
#ifdef CONFIG_64BIT
+ return put_user(0UL, &t->rseq->rseq_cs.ptr64);
+#else
+ return put_user(0UL, &t->rseq->rseq_cs.ptr.ptr32) |
put_user(0UL, &t->rseq->rseq_cs.ptr.padding);
+#endif
----- On Apr 13, 2021, at 12:57 PM, Eric Dumazet [email protected] wrote:
> On Tue, Apr 13, 2021 at 6:54 PM Mathieu Desnoyers
> <[email protected]> wrote:
>>
>> ----- On Apr 13, 2021, at 12:22 PM, Eric Dumazet [email protected] wrote:
>>
>> > From: Eric Dumazet <[email protected]>
>> >
>> > Commit ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union,
>> > update includes") added regressions for our servers.
>> >
>> > Using copy_from_user() and clear_user() for 64bit values
>> > is suboptimal.
>> >
>> > We can use faster put_user() and get_user().
>> >
>> > 32bit arches can be changed to use the ptr32 field,
>> > since the padding field must always be zero.
>> >
>> > v2: added ideas from Peter and Mathieu about making this
>> > generic, since my initial patch was only dealing with
>> > 64bit arches.
>>
>> Ah, now I remember the reason why reading and clearing the entire 64-bit
>> is important: it's because we don't want to allow user-space processes to
>> use this change in behavior to figure out whether they are running on a
>> 32-bit or in a 32-bit compat mode on a 64-bit kernel.
>>
>> So although I'm fine with making 64-bit kernels faster, we'll want to keep
>> updating the entire 64-bit ptr field on 32-bit kernels as well.
>>
>> Thanks,
>>
>
> So... back to V1 then ?
In terms of behavior, yes. And it's probably the "easy" fix, but I hate that
it adds lots of preprocessor ifdefs into the rseq code.
But this would require auditing get_user()/put_user() for each architecture
supported by rseq to ensure they support 8-byte load/store. And it would become
an added burden on architecture maintainers wishing to add rseq support for their
architecture.
One alternative would be to implement rseq_get_user_u64 and rseq_put_user_u64
wrappers as static functions within rseq.c to hide the preprocessor ifdeffery
from the higher-level code. I try very hard to avoid mixing preprocessor ifdefs
with C code logic whenever I can.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
On Tue, Apr 13, 2021 at 7:01 PM Eric Dumazet <[email protected]> wrote:
>
> On Tue, Apr 13, 2021 at 6:57 PM Eric Dumazet <[email protected]> wrote:
> >
> > On Tue, Apr 13, 2021 at 6:54 PM Mathieu Desnoyers
> > <[email protected]> wrote:
> > >
> > > ----- On Apr 13, 2021, at 12:22 PM, Eric Dumazet [email protected] wrote:
> > >
> > > > From: Eric Dumazet <[email protected]>
> > > >
> > > > Commit ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union,
> > > > update includes") added regressions for our servers.
> > > >
> > > > Using copy_from_user() and clear_user() for 64bit values
> > > > is suboptimal.
> > > >
> > > > We can use faster put_user() and get_user().
> > > >
> > > > 32bit arches can be changed to use the ptr32 field,
> > > > since the padding field must always be zero.
> > > >
> > > > v2: added ideas from Peter and Mathieu about making this
> > > > generic, since my initial patch was only dealing with
> > > > 64bit arches.
> > >
> > > Ah, now I remember the reason why reading and clearing the entire 64-bit
> > > is important: it's because we don't want to allow user-space processes to
> > > use this change in behavior to figure out whether they are running on a
> > > 32-bit or in a 32-bit compat mode on a 64-bit kernel.
> > >
> > > So although I'm fine with making 64-bit kernels faster, we'll want to keep
> > > updating the entire 64-bit ptr field on 32-bit kernels as well.
> > >
> > > Thanks,
> > >
> >
> > So... back to V1 then ?
>
> Or add more stuff as in :
diff against v2, WDYT ?
diff --git a/kernel/rseq.c b/kernel/rseq.c
index f2eee3f7f5d330688c81cb2e57d47ca6b843873e..537b1f684efa11069990018ffa3642c209993011
100644
--- a/kernel/rseq.c
+++ b/kernel/rseq.c
@@ -136,6 +136,10 @@ static int rseq_get_cs_ptr(struct rseq_cs __user **uptrp,
{
u32 ptr;
+ if (get_user(ptr, &rseq->rseq_cs.ptr.padding))
+ return -EFAULT;
+ if (ptr)
+ return -EINVAL;
if (get_user(ptr, &rseq->rseq_cs.ptr.ptr32))
return -EFAULT;
*uptrp = (struct rseq_cs __user *)ptr;
@@ -150,8 +154,9 @@ static int rseq_get_rseq_cs(struct task_struct *t,
struct rseq_cs *rseq_cs)
u32 sig;
int ret;
- if (rseq_get_cs_ptr(&urseq_cs, t->rseq))
- return -EFAULT;
+ ret = rseq_get_cs_ptr(&urseq_cs, t->rseq);
+ if (ret)
+ return ret;
if (!urseq_cs) {
memset(rseq_cs, 0, sizeof(*rseq_cs));
return 0;
@@ -237,7 +242,8 @@ static int clear_rseq_cs(struct task_struct *t)
#ifdef CONFIG_64BIT
return put_user(0UL, &t->rseq->rseq_cs.ptr64);
#else
- return put_user(0UL, &t->rseq->rseq_cs.ptr.ptr32);
+ return put_user(0UL, &t->rseq->rseq_cs.ptr.ptr32) |
+ put_user(0UL, &t->rseq->rseq_cs.ptr.padding);
#endif
}