linux-kernel - Re: [RFC] weird crap with vdso on uml/i386

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: <20110820201406.GF2203@ZenIV.linux.org.uk>
Date:	Sat, 20 Aug 2011 21:14:06 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Richard Weinberger <richard@....at>
Cc:	user-mode-linux-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC] weird crap with vdso on uml/i386

On Sat, Aug 20, 2011 at 05:22:23PM +0200, Richard Weinberger wrote:

> Hmmm, very strange.
> Sadly I cannot reproduce the issue. :(
> Everything works fine within UML.
> (Of course I've applied your vDSO/i386 patches)
> 
> My test setup:
> Host kernel: 2.6.37 and 3.0.1
> Distro: openSUSE 11.4/x86_64
> 
> UML kernel: 3.1-rc2
> Distro: openSUSE 11.1/i386
> 
> Does the problem also occur with another host kernel or a different
> guest image?

Could you check what you get in __kernel_vsyscall()?  On iAMD64 box
where that sucker contains sysenter-based variant the bug is not
present.  IOW, it's sensitive to syscall vs. systenter vs. int 0x80
differences.

I can throw the trimmed-down fs image your way, BTW (66MB of bzipped ext2 ;-/)
if you want to see if that gets reproduced on your box.  I'll drop it on
anonftp if you are interested.  FWIW, the same kernel binary/same image
result in
	* K7 box - no breakage, SYSENTER-based vdso
	* K8 box - breakage as described, SYSCALL-based vdso32
	* P4 box - no breakage, SYSENTER-based vdso32
Hell knows...  In theory that would seem to point towards ia32_cstar_target(),
so I'm going to RTFS carefully through that animal.

The thing is, whatever happens happens when victim gets resumed inside
vdso page.  I'll try to dump PTRACE_SETREGS and see the values host
kernel asked to set and work from there, but the interesting part is
bloody hard to singlestep through - the victim is back to user mode and
it is already traced by the guest kernel, so it's not as if we could
attach host gdb to it and walk through that crap.  And guest gdb is not
going to be able to set breakpoints in there - vdso page is r/o...
--
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/