linux-kernel - Re: [PATCHv2 3/6] x86/arch_prctl/vdso: add ARCH_MAP_VDSO

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: <CALCETrW+xWp-xVDjOyPkB5P3-zAubt4U65R4tVNsY34+406tTg@mail.gmail.com>
Date:	Wed, 6 Jul 2016 07:30:18 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Dmitry Safonov <dsafonov@...tuozzo.com>,
	Michal Hocko <mhocko@...e.com>,
	Vladimir Davydov <vdavydov@...tuozzo.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dmitry Safonov <0x7f454c46@...il.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Ingo Molnar <mingo@...hat.com>,
	Cyrill Gorcunov <gorcunov@...nvz.org>, xemul@...tuozzo.com,
	Oleg Nesterov <oleg@...hat.com>,
	Andy Lutomirski <luto@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>
Subject: Re: [PATCHv2 3/6] x86/arch_prctl/vdso: add ARCH_MAP_VDSO_*

On Wed, Jun 29, 2016 at 3:57 AM, Dmitry Safonov <dsafonov@...tuozzo.com> wrote:
> Add API to change vdso blob type with arch_prctl.
> As this is usefull only by needs of CRIU, expose
> this interface under CONFIG_CHECKPOINT_RESTORE.

> +#ifdef CONFIG_CHECKPOINT_RESTORE
> +       case ARCH_MAP_VDSO_X32:
> +               return do_map_vdso(VDSO_X32, addr, false);
> +       case ARCH_MAP_VDSO_32:
> +               return do_map_vdso(VDSO_32, addr, false);
> +       case ARCH_MAP_VDSO_64:
> +               return do_map_vdso(VDSO_64, addr, false);
> +#endif
> +

This will have an odd side effect: if the old mapping is still around,
its .fault will start behaving erratically.  I wonder if we can either
reliably zap the old vma (or check that it's not there any more)
before mapping a new one or whether we can associate the vdso image
with the vma (possibly by having a separate vm_special_mapping for
each vdso_image.  The latter is quite easy: change vdso_image to embed
vm_special_mapping and use container_of in vdso_fault to fish the
vdso_image back out.  But we'd have to embed another
vm_special_mapping for the vvar mapping as well for the same reason.

I'm also a bit concerned that __install_special_mapping might not get
all the cgroup and rlimit stuff right.  If we ensure that any old
mappings are gone, then the damage is bounded, but otherwise someone
might call this in a loop and fill their address space with arbitrary
numbers of special mappings.

--Andy