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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 13 Dec 2012 18:20:00 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	criu@...nvz.org, 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 6:18 PM, H. Peter Anvin <hpa@...or.com> wrote:
> Wouldn't the vdso get mapped already and could be mremap()'d.  If we really need more control I'd almost push for a device/filesystem node that could be mmapped the usual way.

Hmm.  That may work, but it'll still break ABI.  I'm not sure that
criu is stable enough yet that we should care.  Criu people?

(In brief summary: how annoying would it be if the vdso was no longer
just a bunch of constant bytes that lived somewhere?)

--Andy

>
> Andy Lutomirski <luto@...capital.net> wrote:
>
>>On Thu, Dec 13, 2012 at 5:49 PM, H. Peter Anvin <hpa@...or.com> wrote:
>>> On 12/13/2012 05:42 PM, Andy Lutomirski wrote:
>>>>
>>>> The 64-bit/x32 case is currently very simple and fast because it
>>uses
>>>> absolute addressing.  Admittedly, pcrel references are free, so
>>>> changing this wouldn't cost much.  For native, it'll be slower, but
>>>> maybe no one cares.  I seem to care about this more than anyone
>>else,
>>>> and I don't use 32 bit code. :)
>>>>
>>>
>>> pcrel is actually cheaper than absolute addressing in 64-bit mode.
>>>
>>>> The benefit of switching is that the vdso code could be the same in
>>>> all three cases.  (Actually, it's even better than that.  All of the
>>>> VVAR magic could be the same in the vdso and the kernel -- the
>>kernel
>>>> linker script would just have to have an appropriate symbol to see
>>the
>>>> appropriate mapping.)
>>>>
>>>>
>>>> This:
>>>>
>>>> __attribute__((visibility("hidden"))) int foo;
>>>>
>>>> int get_foo(void)
>>>> {
>>>>   return foo;
>>>> }
>>>>
>>>> generates a rip-relative access on 64 bits and GOTOFF on 32 bits.
>>>>
>>>> The only reason I didn't use a real symbol in the first place is
>>>> because I couldn't figure out how to get gcc to emit an absolute
>>>> relocation in pic code.
>>>
>>> Well, then, we wouldn't need to do that... this is starting to sound
>>> like a significant win.
>>
>>How will this avoid breaking checkpoint/restore in userspace?  If the
>>vdso is not just plain old code, criu presumably needs to know about
>>it.  Should there be an arch_prctl(ARCH_MAP_VDSO, addr) to create a
>>vdso mapping somewhere?
>>
>>--Andy
>
> --
> Sent from my mobile phone. Please excuse brevity and lack of formatting.



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/