linux-kernel - Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load

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: <CALCETrUgtveB-ddeL2t0cK18r_VeP5T7LrWCzszfFo+8GcdmEg@mail.gmail.com>
Date:	Fri, 19 Sep 2014 20:27:31 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Filipe Brandenburger <filbranden@...gle.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Greg Thelen <gthelen@...gle.com>,
	X86 ML <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
	Michael Davidson <md@...gle.com>,
	Ingo Molnar <mingo@...hat.com>,
	Richard Larocque <rlarocque@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load

On Fri, Sep 19, 2014 at 8:10 PM, Filipe Brandenburger
<filbranden@...gle.com> wrote:
> Hi Andy,
>
> On Fri, Sep 19, 2014 at 3:31 PM, Andy Lutomirski <luto@...capital.net> 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.

See:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=vdso/vma_tracking

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