From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753897AbaBBAmh (ORCPT ); Sat, 1 Feb 2014 19:42:37 -0500 Received: from terminus.zytor.com ([198.137.202.10]:37106 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752398AbaBBAmg (ORCPT ); Sat, 1 Feb 2014 19:42:36 -0500 User-Agent: K-9 Mail for Android In-Reply-To: References: <1391268756-10766-1-git-send-email-stefani@seibold.net> <1391268756-10766-4-git-send-email-stefani@seibold.net> <52ED90A3.9080802@zytor.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCH 3/4] Add 32 bit VDSO time support for 32 bit kernel From: "H. Peter Anvin" Date: Sat, 01 Feb 2014 16:41:46 -0800 To: Andy Lutomirski CC: Stefani Seibold , Greg KH , "linux-kernel@vger.kernel.org" , X86 ML , Thomas Gleixner , Ingo Molnar , Andi Kleen , Andrea Arcangeli , John Stultz , Pavel Emelyanov , Cyrill Gorcunov , andriy.shevchenko@linux.intel.com, Martin.Runge@rohde-schwarz.com, Andreas.Brief@rohde-schwarz.com Message-ID: <384f3ba9-ce01-4779-8988-556cea724f07@email.android.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Yes, that we can move, of course. On February 1, 2014 4:30:17 PM PST, Andy Lutomirski wrote: >On Sat, Feb 1, 2014 at 4:26 PM, H. Peter Anvin wrote: >> On 02/01/2014 03:59 PM, Andy Lutomirski wrote: >>> >>> If it is, indeed, okay to use non-fixed maps on 32-bit, it might >>> also be okay on 64-bit. If so, it could be useful to implement >that, >>> which would remove a bit of a wart and allow PR_SET_TSC to work >>> usefully for 64-bit userspace. (This would remove the need for the >>> VVAR macro and would allow shorter rip-relative address modes.) >>> >> >> We can't really move the 64-bit legacy vsyscall area, though, as it >is >> an ABI. It can be disabled with vsyscall=none, but Linus has >vehemently >> vetoed removing them. > >VVAR != vsyscall. They've been different pages since I wrote the >vsyscall emulation stuff. Any userspace code that relies on any of >the contents of the VVAR page is totally screwed already, since the >layout changes semi-regularly and depends on whether lockdep is >enabled. > >> >>> (Note that those fixmaps are a security problem on native 32-bit if >>> NX is not available. We may not care.) >> >> Not only on native 32 bit... although the amount of 64-bit hardware >> without NX is quite small, the same is true for anywhere near modern >> 32-bit hardware. > >It can't be a problem for 32-bit compat mode, though, >since userspace can't address the fixmap anyway. > >> >>>> >>>> -#define VDSO_HIGH_BASE 0xffffe000U /* CONFIG_COMPAT_VDSO >address */ >>>> +#define VDSO_HIGH_BASE 0xffffc000U /* CONFIG_COMPAT_VDSO >address */ >>> >>> This is odd. Can you explain it? >>> >> >> He needs 3 pages instead of 1 after his changes. > >Right. But there's some obscure ABI reason for CONFIG_COMPAT_VDSO, >and if this breaks it, then it's no good. From extremely vague >memory, there's some version of SuSE that breaks if the 32-bit vdso >moves. I have no idea what the bug is, but moving a "compat" address >seems suspect. > >--Andy -- Sent from my mobile phone. Please pardon brevity and lack of formatting.