Yes, that we can move, of course. On February 1, 2014 4:30:17 PM PST, Andy Lutomirski <l...@amacapital.net> wrote: >On Sat, Feb 1, 2014 at 4:26 PM, H. Peter Anvin <h...@zytor.com> 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. > ><irrelevant>It can't be a problem for 32-bit compat mode, though, >since userspace can't address the fixmap anyway.</irrelevant> > >> >>>> >>>> -#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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
