Re: [tip:x86/vdso] x86/vdso32/syscall.S: Do not load __USER32_DS to %ss

[Linus Torvalds]

On Thu, Apr 23, 2015 at 11:24 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>
> 1. Do we consider this to be enough of a security issue that we want
> to fix it for 64-bit userspace as well?
>
> 2. Do we fix it at sysret time (at the cost of an ss read even in the
> best case on AMD chips) or at context switch time (with the risk of
> more ss writes than necessary)?

So I'm ok with doing it in the sysret path, and just know that we
randomly have 0 or __KERNEL_DS in %ss while in kernel mode depending
on how we entered it.

But I'd like to make sure it is:

 - documented somewhere (I feel that I understand the problem better
now, but three years from now I will have forgotten all the details
and be surprised about the 0/__KERNEL_DS issue all over again)

   And by "documented somewhere" I very much mean _both_ the
0/__KERNEL_DS issue _and_ the odd 'AMD sysret buglet'

 - I think we should do it for both 32-bit and 64-bit, or at the very
least add a comment to the 64-bit path about this

 - I think the sysret code should also make it clear that this is a CPU buglet

That "sysret code should make it clear" coould possibly be just by
commenting on it (so that "document it clearly" could be the entire
solution), but possibly by even making the fixup be something that
uses the instruction rewriting logic so that it is both (a) very
explicit as a "these CPU's have a problem" and (b) cheaper on CPU's
that don't have the issue. I don't think anybody really cares about a
few cycles in the 32-bit compat path on a 64-bit kernel, but the pure
64-bit case we might care about an extra cycle or three.

Considering that it apparently _is_ a CPU buglet, I don't think we
want to touch the schedule path after all. The odd behavior wrt %ss is
kind of confusing, but if we document it and just clarify that all
returns to user space fix things up, I guess I don't care.

Hmm?

                             Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/