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]

Date:	Fri, 19 Sep 2014 15:19:24 -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,

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

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.

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

Cool! As I said, let me know if you'd like to see some of my
incomplete patches or if you'd like me to keep working on them to show
you something more complete.

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/