linux-kernel - Re: mm: NULL ptr deref handling mmaping of special mappings

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:	Thu, 15 May 2014 12:45:58 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Sasha Levin <sasha.levin@...cle.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Dave Jones <davej@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Pavel Emelyanov <xemul@...allels.com>
Subject: Re: mm: NULL ptr deref handling mmaping of special mappings

On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
> I can summarize:
> 
> On 3.14 and before, the vdso is just a bunch of ELF headers and
> executable data.  When executed by 64-bit binaries, it reads from the
> fixmap to do its thing.  That is, it reads from kernel addresses that
> don't have vmas.  When executed by 32-bit binaries, it doesn't read
> anything, since there was no 32-bit timing code.
> 
> On 3.15, the x86_64 vdso is unchanged.  The 32-bit vdso is preceded by
> a separate vma containing two pages worth of time-varying read-only
> data.  The vdso reads those pages using PIC references.

Andy, could you please point me where is the code which creates a second vma?
latest 3.15 master branch

[root@fc ~]# cat /proc/self/maps
...
7fff57b6e000-7fff57b8f000 rw-p 00000000 00:00 0                          [stack]
7fff57bff000-7fff57c00000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
[root@fc ~]#

Or you mean vsyscall area? If yes, then in criu we don't dump vsyscall zone.
On restore we don't touch  vsyscall either but for vdso there are two cases

 - if there were no kernel change on vdso contents we simply use vdso provided
   by the kernel at the moment of criu startup

 - if vdso has been changed and looks different from one saved in image during
   checkpoint, we map it from image but then patch (push jmp instruction) so
   when application calls for some of vdso function it jumps into vdso code
   saved in image and then jumps into vdso mapped by the kernel (ie kind of
   proxy calls) This force us to do own Elf parsing inside criu to calculate
   proper offsets.

We don't support (and have no plans to support) x86-32 kernels but there
left a case with compatible mode (32bit app on 64bit kernel) which has
not yet been implemented though.

> On linux-next, all vdsos work the same way.  There are two vmas.  The
> first vma is executable text, which can be poked at by ptrace, etc
> normally.  The second vma contains time-varying state, should not
> allow poking, and is accessed by PIC references.
> 
> What does CRIU do to restore the vdso?  Will 3.15 and/or linux-next
> need to make some concession for CRIU?
--
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/