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  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:	Fri, 19 Sep 2014 15:09:11 -0700
From:	Andy Lutomirski <>
To:	Filipe Brandenburger <>
Cc:	"H. Peter Anvin" <>, Greg Thelen <>,
	X86 ML <>, Thomas Gleixner <>,
	Michael Davidson <>,
	Ingo Molnar <>,
	Richard Larocque <>,
	"" <>,
	Linux API <>
Subject: Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load

On Fri, Sep 19, 2014 at 3:02 PM, Filipe Brandenburger
<> wrote:
> Hi Andy,
> On Fri, Sep 19, 2014 at 12:27 PM, Andy Lutomirski <> wrote:
>> I have this (special mapping tracking) 3/4 implemented.  I'm planning
>> on making it fully functional for 64-bit programs and almost correct
>> for 32-bit.  (You'll still crash if you have multiple threads, you use
>> sysenter, and you remap the vdso, but I think that this is essentially
>> unavoidable until someone lets mremap work on multiple vmas at once.)
> In case that's useful, I was looking at swapping the vvar page by
> changing the vm_special_mapping to change the pages array between the
> actual vvar page and the zero page and using zap_page_range to force
> the next access to go through a page fault that would remap it.

That will do it globally, since the vm_special_mapping is global.  I
was just thinking of using remap_pfn_range.

> I didn't have all the details figured out (I was closer to 1/4 of it
> implemented) but I didn't see any issues on 32-bit programs.

The 32-bit issue comes from mremap.

> Let me know if you'd like to see some of my patches or if you think I
> should keep working on them.

Give me another day or two to straighten out the vma stuff, although
it shouldn't impact your patches too much.  The main effect will be
that you'll be able to rely on mm->context.vdso (renamed to
vvar_vma_start, most likey) being correct.  Currently, you should
*not* rely on it, especially if CRIU is involved.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists