linux-kernel - Re: arch_check_bp_in_kernelspace: fix the range check

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: <20121124141458.CB215592076@miso.sublimeip.com>
Date:	Sun, 25 Nov 2012 01:14:58 +1100 (EST)
From:	u3557@...o.sublimeip.com (Amnon Shiloh)
To:	oleg@...hat.com (Oleg Nesterov)
Cc:	gorcunov@...nvz.org (Cyrill Gorcunov),
	xemul@...allels.com (Pavel Emelyanov),
	rostedt@...dmis.org (Steven Rostedt),
	fweisbec@...il.com (Frederic Weisbecker),
	mingo@...hat.com (Ingo Molnar),
	a.p.zijlstra@...llo.nl (Peter Zijlstra),
	linux-kernel@...r.kernel.org
Subject: Re: arch_check_bp_in_kernelspace: fix the range check

Hi Oleg,

This patch may look ugly, but it is one way to solve my problem.

This way, "strace" too, which is broken since the introduction of
the vsyscall page, will again be able to report when the program
calls "time()" or "gettimeofday()" - currently it cannot!

I think that allowing to set the x86 debug-registers to the
vsyscall page is more elegant - but do whatever you prefer.

Best Regards,
Amnon.



> forgot to mention...
> 
> On 11/23, Oleg Nesterov wrote:
> >
> > On 11/23, Amnon Shiloh wrote:
> > >
> > > Or, there is an alternative: if only I (the ptracer or the traced process)
> > > was allowed to munmap the vsyscall page,
> >
> > It is not possible to unmap it. The kernel (swapper_pg_dir) has this
> > mapping, not the process. Unlike vdso. IOW, you can only "unmap" it
> > globally and obviously you can't do this from the userspace.
> 
> And even if this were possible, this can't help. Please look at
> __bad_area_nosemaphore()->emulate_vsyscall(), the process won't get
> SIGSEGV. IOW, in fact EMULATE already "unmaps" this page (sets _NX)
> to trigger the fault.
> 
> Sure, we can do something like below, but it doesn't look very nice
> too.
> 
> Oleg.
> 
> --- x/arch/x86/mm/fault.c
> +++ x/arch/x86/mm/fault.c
> @@ -744,7 +744,8 @@ __bad_area_nosemaphore(struct pt_regs *r
>  		 */
>  		if (unlikely((error_code & PF_INSTR) &&
>  			     ((address & ~0xfff) == VSYSCALL_START))) {
> -			if (emulate_vsyscall(regs, address))
> +			if (!(tsk->ptrace & PTRACE_O_DONTEMULATE) &&
> +			    emulate_vsyscall(regs, address))
>  				return;
>  		}
>  #endif
> 
> 

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