linux-kernel - Re: [CRIU] [PATCH] Add VDSO time function support for x86 32-bit kernel

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: <50CBA171.4080403@zytor.com>
Date:	Fri, 14 Dec 2012 14:00:17 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	Cyrill Gorcunov <gorcunov@...nvz.org>, aarcange@...hat.com,
	ak@...ux.intel.com, Pavel Emelyanov <xemul@...allels.com>,
	Stefani Seibold <stefani@...bold.net>, x86@...nel.org,
	linux-kernel@...r.kernel.org, criu@...nvz.org, mingo@...hat.com,
	john.stultz@...aro.org, tglx@...utronix.de
Subject: Re: [CRIU] [PATCH] Add VDSO time function support for x86 32-bit
 kernel

On 12/14/2012 01:27 PM, Andy Lutomirski wrote:
> 
> I don't know all that much about the linux vm.  Can we create a
> special vdso address_space or struct inode or something so that a
> single vma can contain pages with different flags?
> 

No, that is still different vmas, but it probably isn't a big deal.

The advantage of having an inode/namespace is that it lets you use
mmap() as opposed to mremap() with it, which might be useful, I don't know.

One option for the checkpoint people might actually be to not use the
vdso for a process that needs to be checkpointed and restarted on a
different machine or different kernel version.  Instead they can install
a pseudo-vdso which just calls normal system calls, and is simply a
static piece of code that makes normal system calls ... since the
internals of the kernel are hidden from userspace it is "clean" that way.

With any actual vdso you risk something like:

	-> vdso entry
	-> signal received, transfer to signal handler
	-> checkpoint
	-> restart
	-> signal handler exit

... and now you return to the address in the old vdso, but the internals
of the vdso may have changed.

	-hpa

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