linux-kernel - Re: + fully-honor-vdso_enabled.patch added to -mm tree

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, 2 Mar 2007 22:32:19 +0300
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Paul Mundt <lethal@...ux-sh.org>,
	John Reiser <jreiser@...Wagon.com>, Andi Kleen <ak@...e.de>,
	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: + fully-honor-vdso_enabled.patch added to -mm tree

On 03/02, Paul Mundt wrote:
>
> On Thu, Mar 01, 2007 at 08:52:07PM +0300, Oleg Nesterov wrote:
> > >
> > > @@ -105,10 +107,25 @@ int arch_setup_additional_pages(struct l
> > >  {
> > >  	struct mm_struct *mm = current->mm;
> > >  	unsigned long addr;
> > > +	unsigned long flags;
> > >  	int ret;
> > >
> > > +	switch (vdso_enabled) {
> > > +	case 0:  /* none */
> > > +		return 0;
> > 
> > This means we don't initialize mm->context.vdso and ->sysenter_return.
> > 
> > Is it ok? For example, setup_rt_frame() uses VDSO_SYM(&__kernel_rt_sigreturn),
> > sysenter_past_esp pushes ->sysenter_return on stack.
>
> The setup_rt_frame() case is fairly straightforward, both PPC and SH
> already check to make sure there's a valid context before trying to use
> VDSO_SYM(), I'm not sure why x86 doesn't.
>
> Though I wonder if there's any point in checking binfmt->hasvdso here?
> There shouldn't be a valid mm->context.vdso in the !hasvdso case..

setup_rt_frame() is obviously wrong? Surely it must check ->hasvdso like
setup_frame() does! Otherwise, we will have SIGSEGV on SA_SIGINFO if
->load_binary() does not call arch_setup_additional_pages(), no?

If no, what ->hasvdso is?

> Someone else will have to comment on ->sysenter_return.

It is needed for sysexit. If we don't use sysenter (and we shouldn't, because
syscall_page is not mapped), we don't need to initialize it. Note also that
sys_execve() sets TIF_IRET, so we are safe even if sys_execve() was called
using __kernel_vsyscall.

Still, I don't understand why we don't pass NEW_AUX_ENT(AT_SYSINFO) when
vdso_enabled == 0. We don't need linux-gate.so to use __kernel_vsyscall,
we have FIX_VDSO. In that case we should s/PAGE_KERNEL_RO/PAGE_READONLY/
of course. I guess the reason is some magic in glibc.

Oleg.

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