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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 24 Nov 2017 10:43:57 +0100
From:   Paolo Bonzini <>
To:     丁飞 <>
Subject: Re: Fwd: Why qemu with kvm enabled can boot kernel even if identity
 page map is not set correctly?

On 22/11/2017 03:58, 丁飞 wrote:
> ---------- Forwarded message ----------
> From: 丁飞 <>
> Date: Wed, Nov 22, 2017 at 12:58 AM
> Subject: Why qemu with kvm enabled can boot kernel even if identity
> page map is not set correctly?
> To:
> Hi, KVM developers. Firstly, sorry if it's the wrong place to ask such
> a question!
> In the early stages of boot process, kernel need identity mapped page setup
> when switching gdt
> []
> as code here []
> implies. That's why the first few entries
> of early_dynamic_pgts are set to map the kernel text range [_text, _end].
> But as we discussed about the role of the first few entries of
> early_dynamic_pgts,
> we delete them []
> and recompile the kernel, then test it on qemu.
> Without '-enable-kvm' option the kernel won't boot as we expected, but with kvm
> option on, the kernel can boot and everything runs well, really to our surprise.
> So I guess there are something under the hood done by kvm, which doesn't obey
> the rules of how a real physical machine behaves.
> I've setup a debug environment that the page table mis-configed kernel
> runs inside
> qemu, which nested inside vmware workstation with EPT enabled, and gdb
> on the host to debug the kernel kvm of vmware kernel.
> But without any luck I've spent a whole day try to catch what is
> happening inside kvm,
> I still can't figure out the real magic point that jump through the
> broken page table.
> It seems that the code just jumps randomly.
> Can anyone confirm what we've observed? Is it designed to be like that?
> Any details or explanation would be really appreciated!

I'm sorry, I don't know.  There are many differences in TLB behavior
between emulation and real hardware, those could be the culprit.


Powered by blists - more mailing lists