Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933613AbYBVMzQ (ORCPT ); Fri, 22 Feb 2008 07:55:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752599AbYBVMzE (ORCPT ); Fri, 22 Feb 2008 07:55:04 -0500 Received: from colin.muc.de ([193.149.48.1]:4001 "EHLO mail.muc.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751582AbYBVMzD (ORCPT ); Fri, 22 Feb 2008 07:55:03 -0500 Date: 22 Feb 2008 13:55:01 +0100 Date: Fri, 22 Feb 2008 13:55:00 +0100 From: Andi Kleen To: Thomas Gleixner Cc: john stultz , Arne Georg Gleditsch , LKML , Ingo Molnar , Roman Zippel , "H. Peter Anvin" , Arjan van de Ven Subject: Re: arch/x86/kernel/vsyscall_64.c: overeager NOP of syscalls Message-ID: <20080222125500.GB81921@muc.de> References: <20080221155852.GA42442@muc.de> <1203624160.6150.5.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1814 Lines: 38 On Thu, Feb 21, 2008 at 09:59:24PM +0100, Thomas Gleixner wrote: > On Thu, 21 Feb 2008, Thomas Gleixner wrote: > > > That or we need to do the NOP/un-NOP part in the update_vsyscall code > > > dependent on if the current clocksource supports vread, instead of on > > > the /proc entry access. > > > > That won't fly. We need to sychronize the CPUs when we patch the code, > > which is not possible from update_wall_time with interrupts disabled. > > Also this is utterly stupid as we keep the syscall in cases where we > do not have vread anyway, so we keep the attack point open for a lot > of existing machines due to TSC wreckage and HPET unavailability. Yes that is true, but I didn't find a cheap way around it without breaking binary compatibility. I found an expensive way (essentially just putting a trampoline to a variable mapped vsyscall page on the old static address), but since it would have added quite a lot of complexity (vsyscall is inside the kernel mapping and would need to be rewritten at context switch) and memory overhead in page tables and one more page per process I didn't do that. I also considered doing boot time randomization only (which would avoid a lot of these problems), but it didn't seem worth it. Also one must say I don't consider it a big security improvement on most systems. That is because most programs are not PIC, but linked at a fixed address and usually if you grep the larger binary for the few bytes needed for a system call you'll find it at some known offset as part of another instruction sequence. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/