linux-kernel - Re: [x86] do_arch

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: <492AF0DA.3060702@goop.org>
Date:	Mon, 24 Nov 2008 10:22:18 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Eric Lacombe <goretux@...il.com>
CC:	Arjan van de Ven <arjan@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [x86] do_arch_prctl

Eric Lacombe wrote:
> Hello,
>
> Does the "doit case" (line 822 in ARCH_GET_FS, function do_arch_prctl) exist 
> for performance reasons? Else, why "task->thread.fs" (line 824) does not 
> contain the fs base in the "doit case"?
>   

"doit" gets set when you're operating on yourself.  If you're operating 
on another process, then you need to use their task structure values 
rather than the current process's values.  If you're doing it to 
yourself, then the task structure may be out of date because its only 
updated on a context switch.

> Can someone explain _precisely_ the lines 835 through 838 (ARCH_GET_GS)?
> (I thought that just the line 836 was sufficient, but I 
> obviously miss the case where MSR_KERNEL_GS_BASE does not reflect the value 
> requested)
>   

gsindex and gs store the same information in two ways.  gsindex is the 
GDT selector number which contains the (32-bit) base address, and gs is 
the raw 64-bit base address.  If gsindex != 0 then it prevails, 
otherwise gs contains the right value.

When you load %gs with a selector, the MSR is updated with the value 
from the GDT.  Rather than parsing the GDT entry manually to get the 
encoded base address, the code in 836 fetches it out of the MSR.  On the 
other hand, if you're using a raw gs base (ie gsindex==0), then you can 
simply read the base directly from the task structure.  rdmsr would work 
as well, but be less efficient.

    J

> Thanks again for all your previous answers.
>
> 	Eric
>
> 828 case ARCH_GET_GS: {
> 829                 unsigned long base;
> 830                 unsigned gsindex;
> 831                 if (task->thread.gsindex == GS_TLS_SEL)
> 832                         base = read_32bit_tls(task, GS_TLS);
> 833                 else if (doit) {
> 834                         asm("movl %%gs,%0" : "=r" (gsindex));
> 835                         if (gsindex)
> 836                                 rdmsrl(MSR_KERNEL_GS_BASE, base);
> 837                         else
> 838                                 base = task->thread.gs;
> 839                 }
> 840                 else
> 841                         base = task->thread.gs;
> 842                 ret = put_user(base, (unsigned long __user *)addr);
> 843                 break;
> 844         }
>
> ---
>
> 817         case ARCH_GET_FS: {
> 818                 unsigned long base;
> 819                 if (task->thread.fsindex == FS_TLS_SEL)
> 820                         base = read_32bit_tls(task, FS_TLS);
> 821                 else if (doit)
> 822                         rdmsrl(MSR_FS_BASE, base);
> 823                 else
> 824                         base = task->thread.fs;
> 825                 ret = put_user(base, (unsigned long __user *)addr);
> 826                 break;
> 827         }
>
>   

--
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/