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 20:27:31 -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 8:10 PM, Filipe Brandenburger
<> wrote:
> Hi Andy,
> On Fri, Sep 19, 2014 at 3:31 PM, Andy Lutomirski <> wrote:
>>> Sorry if I wasn't clear... That's the exact point of my patch, to make
>>> vm_special_mapping local to the task.
>>> I started with an approach of keeping a struct vm_special_mapping + a
>>> struct page * array per mm_struct.
>>> I was also looking at keeping two static vm_special_mapping structs,
>>> one with the actual vvar page and the other with the zero page and
>>> then swapping vma->vm_private_data to point to the appropriate one.
>> This sounds like it may be more complicated than necessary.  Is there
>> any reason that just doing remap_pfn_range on the vvar page isn't
>> enough?
> I thought of doing that from the prctl but AFAICT remap_pfn_range
> requires that it's unmapped before the call (remap_pte_range has
> BUG_ON(!pte_none(*pte));) and doing a zap_page_range followed by
> remap_pfn_range might incur a race condition if another thread of the
> same process is accessing the vvar page at that time... Am I wrong
> about that race?

No, you're right.  Ugh.

It might pay to add an explicit .fault callback to vm_special_mapping,
but your approach will work, too.  The main downside is more memory
overhead per mm.

>> Changing out the text is a whole can of worms involving self-modifying
>> code, although it may be completely safe if done through the page
>> tables.  But I don't think you can't use remap_pfn_range for that.
> No, I'm not planning to change the text, just replacing the vvar page
> swapping the one where the vsyscall_gtod_data lives with a zero page
> (and back depending on the parameter of the prctl.)

Hmm.  This will break the _COARSE timing functions as well as
__vdso_time.  That'll need fixing, either by swapping out the code
(yuck!) or by adding a branch to all of those code paths.

Maybe there's a non-branchy way, though.  Let me think.

>> Maybe better: what exactly are you trying to do?
> Just replace the page mapped to the vvar address.
> But nevermind my ramblings here, looks like you're almost there so go
> ahead and when you have a working patch I'll take a look at it.


> My offer to help still stands, so let me know if you'd like to see
> some of my code (unfinished as it is now or if you'd like me to show
> you something that works in a few days.)
> Cheers,
> Filipe

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