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: <CADU+-uBoMrF=vbOM4TW7YzD5cdHSn8BJdfs5nnPM6uS9-6n_Ag@mail.gmail.com>
Date:	Fri, 19 Sep 2014 20:10:18 -0700
From:	Filipe Brandenburger <filbranden@...gle.com>
To:	Andy Lutomirski <luto@...capital.net>
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

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?

> 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.)

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