[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAObL_7H=M7-wxobKkj+K2fcrpEv0Nfp8=6gV2yvdb2hqxCTAGg@mail.gmail.com>
Date: Tue, 21 Feb 2012 11:40:38 -0800
From: Andrew Lutomirski <luto@....edu>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
mingo@...nel.org, tglx@...utronix.de,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
hjl.tools@...il.com
Subject: Re: [PATCH 30/30] x32: Add x32 VDSO support
On Tue, Feb 21, 2012 at 11:37 AM, H. Peter Anvin <hpa@...or.com> wrote:
> On 02/21/2012 11:29 AM, Andrew Lutomirski wrote:
>>>
>>> The vsyscall page shouldn't be mapped for x32 tasks...
>>
>> How is that possible? It lives in the fixmap and is presumably
>> visible from any 64-bit code.
>>
>> Admittedly, x32 tasks are probably somewhat difficult to trick into
>> calling addresses with high bits set, but it's not necessarily
>> impossible.
>>
>
> Fair enough, and it's not necessarily all that hard either.
>
> And it's visible even in a 32-bit task, although a 32-bit task has to
> switch into 64-bit mode. Yet another reason the vsyscall page needs to die.
>
> I was having delusions that we could have a task-owned PDT in negative
> space, but that would require unsharing the third level, too, which is
> just way too messy.
I'd like to do that, too, and I'd also like to have a per-cpu
kernel-only page in there, but that's even worse. If we had a
separate cr3-like register for negative addresses, life would be good
:)
--Andy
--
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