linux-kernel - Re: [RFC PATCH] kvm: Make KVM DF intercept configurable

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:	Tue, 1 Mar 2016 23:41:32 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	Jörg Rödel <joro@...tes.org>,
	Andy Lutomirski <luto@...capital.net>, x86-ml <x86@...nel.org>,
	kvm ML <kvm@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] kvm: Make KVM DF intercept configurable

On Tue, Mar 01, 2016 at 10:11:57PM +0100, Paolo Bonzini wrote:
> I just use QEMU's binary translation mode to debug this kind of code (-d
> in_asm is useful and relatively compact (because it only shows loops
> once),

Ha, I had forgotten about "in_asm"! Thanks for reminding me, that's a
really cool feature I'm going to use. With it I see:

----------------
IN: 
0x0000000001000000:  mov    0xffffffff81cba1f8,%rsp
0x0000000001000008:  callq  0x10001a9

----------------

Now, it is obvious that 0xffffffff81cba1f8 is not mapped yet and we're
running from physical addresses. The DF tracepoint shows, in addition,
the previous exception vector causing the DF and I think that's useful.
As an additional debugging aid. Oh, and that doesn't need ept=0 and runs
at full speed.

> or alternatively ept=0. But perhaps... why not. :) It's not like it
> adds overhead.

Yeah, it is off by default and doesn't hurt anyone. And the diff size
is ok, IMHO. Lemme code the Intel side too and see how the whole thing
turns out.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.