linux-kernel - Re: Assignment of GDT entries

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]

Date:	Wed, 13 Sep 2006 14:47:36 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Linus Torvalds <torvalds@...l.org>
CC:	Ingo Molnar <mingo@...e.hu>, Andi Kleen <ak@...e.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Zachary Amsden <zach@...are.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Michael A Fetterman <Michael.Fetterman@...cam.ac.uk>
Subject: Re: Assignment of GDT entries

Linus Torvalds wrote:
> These _used_ to be the "user CS/DS" respectively, but that got changed 
> around by me when did the "sysenter" support.
>   

So does this mean that moving the user-visible cs/ds isn't likely to 
break stuff, if it has been done before?

> The sysenter logic (or, more properly, the sysexit one) requires that the 
> user code segment number is the same as the kernel code segment +2 (ie 
> "+16" in actual selector term). And the user data segment needs to be +3.
>   

Yep, I'm aware of that constraint.

> And segment #8 (ie 0x40) is special (TLS segment #3), of course. 
> Anybody who wants to emulate windows or use the BIOS needs to use that for 
> their "common BIOS area" thing, iirc.
>   

Do you mean that something like dosemu/Wine needs to be able to use GDT 
#8?  Or is it only used in kernel code?

> See above. The kernel and user segments have to be moved as a block of 
> four, and obviously we'd like to keep them in the same cacheline too. 
> Also, the cacheline that contains segment #8/0x40 is not available,

Why's that?  That cacheline (assuming 64 byte line size) already 
contains the user/kernel/cs/ds descriptors.

I'm thinking of putting together a patch to change the descriptor use to:

    8  - TLS #1
    9  - TLS #2
    10 - TLS #3
    11 - Kernel PDA
    12 - Kernel CS
    13 - Kernel DS
    14 - User CS
    15 - User DS

This has the advantage of leaving the user cs/ds unchanged.  From what 
people had said so far, this should be OK, other than making the heavily 
used TLS #1 share the BIOS common area entry number.  If this needs to 
be usable by userspace for something special, then making it TLS #1 
won't fly...

Alternatively, maybe:

    0  - NULL
    1  - Kernel PDA
    2  - Kernel CS
    3  - Kernel DS
    4  - User CS
    5  - User DS
    6  - TLS #1
    7  - TLS #2

which moves the user cs/ds, but avoids #8.

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