linux-kernel - Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 07 Mar 2014 22:53:40 +0100
From:	Stefani Seibold <stefani@...bold.net>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Fengguang Wu <fengguang.wu@...el.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [x86, vdso] BUG: unable to handle kernel paging request at
 d34bd000


Am Freitag, den 07.03.2014, 10:56 -0800 schrieb Andy Lutomirski:
> On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold <stefani@...bold.net> wrote:
> > Hi Fengguang,
> >
> > i have build a kernel with the config, but my kvm is unable to start it.
> > I will try to find a way to test your kernek config.
> >
> > One thing is the crash point:
> >
> > The function sysenter_setup was modified by Andy, maybe he has an idea
> > what fails.
> 
> *sigh*
> 
> My host kernel is currently fscked up and won't run KVM.  Also, I want
> to confirm that I'm reproducing exactly what you're seeing, and I
> think it depends on the toolchain.  Can you (Fenguang) do:
> 
> $ ls -l arch/x86/vdso/vdso32*.so
> -rwxrwxr-x. 1 luto luto 4096 Mar  7 10:19 arch/x86/vdso/vdso32-int80.so
> -rwxrwxr-x. 1 luto luto 4116 Mar  7 10:19 arch/x86/vdso/vdso32-sysenter.so
> 
> (Of course, triggering this depends on which image gets selected.)
> 

Yes, that what i also figured out. There are two culprits:
CONFIG_OPTIMIZE_INLINING and CONFIG_X86_PPRO_FENCE. Each of them
increase the size of the code by about 500 bytes.

When i add to file arch/x86/vdso/vdso32/vclock_gettime.c

#undef CONFIG_OPTIMIZE_INLINING
#undef CONFIG_X86_PPRO_FENCE

this will solve the issue.

> Note that we have a .so file that exceeds 4k, i.e. one page.  Then
> read the relevant code and wonder what everyone was smoking when they
> wrote it.  There are so many buffer overflows, screwed up
> initializations, unnecessary and incorrect copies, etc, that I don't
> even want to speculate on what the first failure will be when the
> image is bigger than a page.
>

Right. So the above one will not really solve it. At least when
__vdso_getcpu() code will also become a part of the 32 bit VDSO.
 
> It's easy enough to fix, but someone should figure out what the impact
> will be on the compat vdso case.
> 
> I wonder how hard it would be to change the compat vdso do be a dummy
> image a la the x86_64 fake vsyscall page so that old code can keep
> working (maybe with a performance hit) and new code can use a sane
> image.
> 

That is exactly what i wrote one week ago:

Move the VDSO code before the VDSO compat fixmap area and create a kind
of helper VDSO for the VDSO compat fixmap page, which only calls the
real VDSO. But this would result in a performance regression for the
VDSO compat mode.

- Stefani


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