From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:40728 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755024AbbHFQAz (ORCPT ); Thu, 6 Aug 2015 12:00:55 -0400 Subject: Re: [Patch V3] x86/ldt: correct fpu emulation access to ldt To: Andy Lutomirski References: <1438852904-12848-1-git-send-email-jgross@suse.com> Cc: billm@melbpc.org.au, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , X86 ML , "linux-kernel@vger.kernel.org" , Andrew Lutomirski , stable From: Juergen Gross Message-ID: <55C384AB.9070400@suse.com> Date: Thu, 6 Aug 2015 18:00:43 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: On 08/06/2015 05:15 PM, Andy Lutomirski wrote: > On Thu, Aug 6, 2015 at 2:21 AM, Juergen Gross wrote: >> Commit 37868fe113ff ("x86/ldt: Make modify_ldt synchronous") introduced >> a new struct ldt_struct anchored at mm->context.ldt. >> >> Adapt the x86 fpu emulation to use that new structure. >> >> Cc: # 37868fe113ff: x86/ldt: Make modify_ldt synchronous >> Cc: # a5b9e5a2f14f: x86/ldt: Make modify_ldt optional >> Signed-off-by: Juergen Gross >> --- >> arch/x86/math-emu/fpu_entry.c | 3 +-- >> arch/x86/math-emu/fpu_system.h | 21 ++++++++++++++++++--- >> arch/x86/math-emu/get_address.c | 3 +-- >> 3 files changed, 20 insertions(+), 7 deletions(-) >> >> diff --git a/arch/x86/math-emu/fpu_entry.c b/arch/x86/math-emu/fpu_entry.c >> index f37e84a..203318a 100644 >> --- a/arch/x86/math-emu/fpu_entry.c >> +++ b/arch/x86/math-emu/fpu_entry.c >> @@ -29,7 +29,6 @@ >> >> #include >> #include >> -#include >> #include >> #include >> >> @@ -181,7 +180,7 @@ void math_emulate(struct math_emu_info *info) >> math_abort(FPU_info, SIGILL); >> } >> >> - code_descriptor = LDT_DESCRIPTOR(FPU_CS); >> + code_descriptor = *FPU_get_ldt_descriptor(FPU_CS); >> if (SEG_D_SIZE(code_descriptor)) { >> /* The above test may be wrong, the book is not clear */ >> /* Segmented 32 bit protected mode */ >> diff --git a/arch/x86/math-emu/fpu_system.h b/arch/x86/math-emu/fpu_system.h >> index 9ccecb6..d4a49d7 100644 >> --- a/arch/x86/math-emu/fpu_system.h >> +++ b/arch/x86/math-emu/fpu_system.h >> @@ -16,9 +16,24 @@ >> #include >> #include >> >> -/* s is always from a cpu register, and the cpu does bounds checking >> - * during register load --> no further bounds checks needed */ >> -#define LDT_DESCRIPTOR(s) (((struct desc_struct *)current->mm->context.ldt)[(s) >> 3]) >> +#include >> +#include >> + >> +static inline struct desc_struct *FPU_get_ldt_descriptor(unsigned seg) >> +{ >> + static struct desc_struct zero_desc; >> + struct desc_struct *ret = &zero_desc; >> + >> +#ifdef CONFIG_MODIFY_LDT_SYSCALL >> + seg >>= 3; >> + mutex_lock(¤t->mm->context.lock); >> + if (current->mm->context.ldt && seg < current->mm->context.ldt->size) >> + ret = current->mm->context.ldt->entries + seg; >> + mutex_unlock(¤t->mm->context.lock); >> +#endif > > Is there a good reason to return a pointer instead of returning struct > desc_struct directly? I think that, if you return a pointer, the > locking is still wrong. context.ldt can change at any point during > which IRQs are enabled (unless you hold the mutex), so I don't think > the mutex is sufficient -- the pointer can become invalid even after > this function returns. Aah, of course. Sorry about that. I just wanted to avoid returning a 8 byte structure on 32 bit. I'll send V4... Thanks, Juergen