linux-kernel - Re: [CRIU] [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]

Message-ID: <50CB716D.6020501@zytor.com>
Date:	Fri, 14 Dec 2012 10:35:25 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Pavel Emelyanov <xemul@...allels.com>
CC:	Andy Lutomirski <luto@...capital.net>, aarcange@...hat.com,
	ak@...ux.intel.com, Stefani Seibold <stefani@...bold.net>,
	x86@...nel.org, linux-kernel@...r.kernel.org, criu@...nvz.org,
	mingo@...hat.com, john.stultz@...aro.org, tglx@...utronix.de
Subject: Re: [CRIU] [PATCH] Add VDSO time function support for x86 32-bit
 kernel

On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
> On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
>> 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?
> 
> It's not yet, but we'd still appreciate the criu-friendly vdso redesign.
> 
>> (In brief summary: how annoying would it be if the vdso was no longer
>> just a bunch of constant bytes that lived somewhere?)
> 
> It depends on what vdso is going to be. In the perfect case it should
> a) be mremap-able to any address (or be at fixed address _forever_, but
>    I assume this is not feasible);
> b) have entry points at fixed (or somehow movable) places.
> 
> I admit that I didn't understand your question properly, if I did,
> please correct me.
> 

mremap() should work.  At the same time, the code itself is not going to
have any stability guarantees between kernel versions -- it obviously
cannot.

Incidentally, the MAYWRITE bit which is there to allow breakpoints is
obviously problematic for the vvar page.  We could mark the vvar page
differently, meaning more vmas, or we could decide it just doesn't
matter and that if you mprotect() the vvar page and write to it you get
exactly what you asked for...

	-hpa


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