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-next>] [day] [month] [year] [list]
Date:   Thu, 8 Nov 2018 15:23:59 -0700
From:   Rian Quinn <rianquinn@...il.com>
To:     linux-kernel@...r.kernel.org
Subject: x86_64 INIT/SIPI Bug

I apologize upfront if this is the wrong place to post this, pretty new to this.

We are working on the Bareflank Hypervisor (www.bareflank.org), and we
are passing through the INIT/SIPI process (similar to how a VMX
rootkit from EFI might boot the OS) and we noticed that on Arch Linux,
the INIT/SIPI process stalls, something we are not seeing on Ubuntu.

Turns out, to fix the issue, we had to turn on cpu_init_udelay=10000.
The problem is, once a hypervisor is turned on, even one that is doing
nothing but passing through the instructions, the "quick" that is
detailed below fails as the kernel is not giving the CPU enough time
to perform a VMExit/VMEntry (even through the VMExit is not doing
anything).
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/smpboot.c?h=v4.20-rc1#n650

You can see our INIT/SIPI code here if you are interested:
https://github.com/rianquinn/extended_apis/blob/hyperkernel_1/bfvmm/src/hve/arch/intel_x64/vmexit/init_signal.cpp

The reason I suggest this is a bug is the manual clearly states that a
wait is required and the "quirk" that turns off this delay prevents
code like this from working. Would it be possible to either:
- Turn this off by default, but still allow someone to turn it on if
they are confident the delay is not needed?
- Provide a generic way to turn this off (maybe if a hypervisor is
detected, it defaults to off)?

I'd be more than happy to provide a patch and test, but I'm not sure
if there is any interest in changing this code.

Thanks,
- Rian Quinn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ