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
| ||
|
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/
Powered by blists - more mailing lists