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
| ||
|
Date: Mon, 8 Dec 2008 00:02:20 +0100 From: Eric Lacombe <goretux@...il.com> To: Jeremy Fitzhardinge <jeremy@...p.org> 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 Hi, I'm sorry to insist, but I really want to understand what occurs in this portion of kernel code. And that's why I resend my previous message with the hope that someone could enlighten my mind. Thanks in advance, Eric Le lundi 24 novembre 2008 19:22:18 Jeremy Fitzhardinge, vous avez écrit : > 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. The task_struct is also updated in sys_arch_prctl (ARCH_SET_FS and ARCH_SET_GS), so not just on a context switch. How the task structure could be out of date wrt thread.gs and thread.fs? What could be a typical scenario that could induced gs or fs to be modified and not thread.gs and thread.fs? Why we have a difference between ARCH_GET_GS : > 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 } and ARCH_GET_FS : > 821 else if (doit) > 822 rdmsrl(MSR_FS_BASE, base); If I follow what you say, why can't we have the same optimization in ARCH_GET_FS? thanks, Eric -- 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/
Powered by blists - more mailing lists