linux-kernel - Re: [PATCH 6/6] x86/vdso: Move out the CPU number store

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51587908-9652-6a8e-0e01-f387e3ae5852@zytor.com>
Date:   Mon, 4 Jun 2018 22:36:27 -0700
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Mika Penttilä <mika.penttila@...tfour.com>,
        "Chang S. Bae" <chang.seok.bae@...el.com>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>
Cc:     Andi Kleen <ak@...ux.intel.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Markus T Metzger <markus.t.metzger@...el.com>,
        "Ravi V . Shankar" <ravi.v.shankar@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 6/6] x86/vdso: Move out the CPU number store

On 06/04/18 20:57, Mika Penttilä wrote:
> 
> This won't work on X86-32 because it actually uses the segment limit with fs: access. So there 
> is a reason why the lsl based method is X86-64 only.
> 

<thinks out loud>

Why does that matter in any shape, way, or form?  The LSL instruction
doesn't touch any of the segment registers, it just uses a segment
selector number.

<looks at code>

I see... we have a VERY unfortunate name collision: the x86-64
GDT_ENTRY_PERC_PU and the i386 GDT_ENTRY_PERCPU are in fact two
completely different things, with the latter being the actual percpu
offset used by the kernel.

So yes, this patch is wrong, because the naming of the x86-64 segment is
insane especially in the proximity of the  -- it should be something
like GDT_ENTRY_CPU_NUMBER.

Unfortunately we probably can't use the same GDT entry on x86-32 and
x86-64, because entry 15 (selector 0x7b) is USER_DS, which is something
we really don't want to screw with.  This means i386 programs that
execute LSL directly for whatever reason will have to understand the
difference, but most of the other segment numbers differ as well,
including user space %cs (USER_CS/USER32_CS) and %ds/%es/%ss (USER_DS).
Perhaps we could bump down segments 23-28 by one and put it as 23, that
way the CPU_NUMBER segment would always be at %ss+80 for the default
(flat, initial) user space %ss.  (We want to specify using %ss rather
than %ds, because it is less likely to be changed and because 64 bits,
too, have %ss defined, but not %ds.)

<action item>

Rename the x86-64 segment to CPU_NUMBER, fixing the naming conflict.
Add 1 to GDT entry numbers 23-28 for i386 (all of these are
kernel-internal segments and so have no impact on user space).
Add i386 CPU_NUMBER equivalent to x86-64 at GDT entry 23.
Document the above relationship between segments.

OK, everyone?

	-hpa