linux-kernel - Re: [PATCH] Add VDSO time function support for x86 32-bit kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Dec 2012 16:20:14 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Stefani Seibold <stefani@...bold.net>,
	linux-kernel@...r.kernel.org, x86@...nel.org, tglx@...utronix.de,
	mingo@...hat.com, ak@...ux.intel.com, aarcange@...hat.com,
	john.stultz@...aro.org
Subject: Re: [PATCH] Add VDSO time function support for x86 32-bit kernel

On Thu, Dec 13, 2012 at 4:09 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 12/13/2012 11:32 AM, Andy Lutomirski wrote:
>>
>>
>> x32's vdso cheats -- x32 code can see high addresses just fine.  The
>> toolchain just makes it difficult.
>>
>> Your best bet is probably to just map the vvar page twice -- once at
>> the same address as native 32-bit mode (but only for compat tasks)
>> would use and once in the usual fixmap location.  You can't use the
>> fixmap for the compat mapping, though, since it would be a *user*
>> address.
>>
>> For HPET support, you'd have to have special support.  I'd say to skip
>> it for compat mode.
>>
>
> Whatever data you need you can just map it into the vdso range.  There
> really shouldn't be anything special about that at all.
>
> The fixmap stuff is an x86-64 legacy that you don't have to worry about,
> obviously.

The fixmap page is new.  It's not ABI -- the layout can freely change,
but the vdso needs to be able to see.  It would make no sense to cow
that page, and it would be more complicated to make it be part of the
(64-bit) vdso, so I left it as a fixmap when I did the vvar cleanups.

For compat mode, though, I don't think it can be in the fixmap unless
there are segmentation games that I think are impossible, or unless
the vdso wants to do a far call (which I would guess is not much
faster than a system call, although I haven't benchmarked it).  This
is because there are no addresses at all that can be seen from 32-bit
code segments and that are in the kernel address range.

What you could do is probably arrange (using some linker script magic)
for a symbol to exist that points at the page *before* the vdso
starts.  Then just map the vvar page there when starting a compat
task.  You could then address it using a normal symbol reference by
tweaking the vvar macro.  (I think this'll access it via the GOT.)
Alternatively, you could just pick an absolute address -- the page is
NX, so you don't really need to worry about randomization.

--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/