linux-kernel - Re: [KVM paravirt issue?] Re: vsyscall=emulate regression

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: <4F3D395B.1000708@redhat.com>
Date:	Thu, 16 Feb 2012 19:14:03 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	Amit Shah <amit.shah@...hat.com>, tglx@...utronix.de,
	mingo@...hat.com, hpa@...or.com, x86@...nel.org,
	linux-kernel@...r.kernel.org, kvm list <kvm@...r.kernel.org>
Subject: Re: [KVM paravirt issue?] Re: vsyscall=emulate regression

On 02/16/2012 06:45 PM, Andy Lutomirski wrote:
> >
> >> So I could have messed up, or there could be a subtle
> >> bug somewhere.  Any ideas?
> >
> > What's the code trying to do?  Execute an instruction from an
> > non-executable page, trap the #PF, and emulate?  And what are the
> > symptoms? wrong error code for the #PF?  That could easily be a kvm bug.
> >
>
> The symptom is that some kind of access to a page that's supposed to
> be readable, NX is reporting error 5.  I'm not quite sure what kind of
> access is causing that.

Might it be a fetch access, with kvm forgetting to set bit 4 correctly?

> >
> > Can you point me at the code in question?
>
> The setup code is in arch/x86/kernel/vsyscall_64.c in map_vsyscall.
> The bad access is to the vsyscall page.

The bad access is on purpose, yes?

>From fault.c:

#ifdef CONFIG_X86_64
                /*
                 * Instruction fetch faults in the vsyscall page might need
                 * emulation.
                 */
                if (unlikely((error_code & PF_INSTR) &&
                             ((address & ~0xfff) == VSYSCALL_START))) {
                        if (emulate_vsyscall(regs, address))
                                return;
                }
#endif

so it seems like kvm doesn't set PF_INSTR?

I thought we unit tested that, but maybe not this exact scenario.


-- 
error compiling committee.c: too many arguments to function

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