On Mon, Nov 9, 2015 at 3:26 PM, Barret Rhoden <[email protected]> wrote:
> > kern/arch/x86/uaccess.h | 98 ++++++++++++++-----------
>
> Minor thing, but anytime we add a arch-specific header that gets used in
> arch-independent code (as this one is later), please add a header with
> stubs to the other architectures.
>
Are you going to add it this time?
> + if (unlikely(!is_user_raddr((void *) src, 1)))
> > + return -EFAULT;
>
> Is this unlikely() necessary? We already have the unlikely() inside
> is_user_raddr, which is static inlined. I'd like to limit the
> unlikely() calls a bit.
>
If you want to bolt in the knowledge that a function is static inlined,
then no, it is not.
>
> More importantly, what happens if the user picks an address close to the
> border of the an area where it does not have access, but the string goes
> into that area. For instance, in copy_to_user, I think the user could
> pick UWLIM - 1, then trick the kernel into writing above that into
> memory that is read-only.
>
The code assume that there is one (at least) separation page between user
and kernel VMAs.
Should have made it more clear.
>
> > + for (;; dst++, src++) {
> > + int error = __get_user(dst, src, 1);
> >
> > - static_assert(ULIM % PGSIZE == 0 && ULIM != 0); // prevent
> wrap-around
> > + if (unlikely(error))
> > + return error;
> > + if (unlikely(!*dst))
> > + break;
>
> How unlikely is this? It'll happen once per strcpy, right? Is that
> going to be a TLB miss or something based on what the compiler does to
> make something unlikely? This example gets at the tradeoff of using
> likely/unlikely.
>
If AVG string length is, say, 8, then that is more unlikely than likely.
So the question is, in a tight loop like that, out of 8 times, would you
prefer to be kicked in the ankle 7 times out of 8, or 1 out of 8? ☺
--
You received this message because you are subscribed to the Google Groups
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
