linux-kernel - Re: [PREEMPT-RT] Oops in rapl_cpu

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] [day] [month] [year] [list]

Date:   Thu, 3 Nov 2016 21:21:15 +0300
From:   "M. Vefa Bicakci" <m.v.b@...box.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Charles (Chas) Williams" <ciwillia@...cade.com>
Subject: Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

On 11/02/2016 08:23 PM, Sebastian Andrzej Siewior wrote:
> On 2016-11-01 13:15:53 [+0300], M. Vefa Bicakci wrote:
>> Hello Sebastian,
>
> Hi,
> 
>> The patch fixes the kernel oops for me.
>>
>> I am using a custom 4.8.5-based kernel on Qubes OS R3.2, which is based
>> on Xen 4.6.3. Apparently, Xen also has a similar bug/flaw/quirk regarding
>> the allocation of package identifiers for the virtual CPUs.
>>
>> Prior to your patch, my Xen-based virtual machines would intermittently
>> crash most of the time at boot-up with the backtrace reported by Charles.
>> Due to this, I was under the impression that this is a subtle race
>> condition.
> 
> how hard is it to get such a xen setup up and running?

Hello Sebastian,

Sorry about my late reply!

The set-up I use is a bit involved/complicated. To replicate it, you
would need to install Qubes OS R3.2 (assuming that you have compatible
hardware with a lot of RAM) and then build a custom 4.8.y-based kernel
with a set of cherry-picked commits. After installing this kernel in
dom0 with dnf or rpm, you would need to run:

  # Generate a domU initrd and copy the kernel image and the generated
  # initrd to Qubes OS's domU kernel directory (/var/lib/qubes/...)
  $ sudo /usr/sbin/qubes-prepare-vm-kernel <kernel_version>

  # From now on, use kernel_version when starting domU instances.
  $ qubes-prefs -s default-kernel <kernel_version>

Afterwards, starting a domU (i.e., AppVM in Qubes OS terminology) should
exhibit the issue in question related to RAPL:

  $ sudo truncate -s0 /var/log/xen/console/guest-<app_vm_name>.log
  $ qvm-start --debug <app_vm_name>
  $ cat /var/log/xen/console/guest-<app_vm_name>.log

As you may appreciate, the set-up is a bit involved. Nevertheless, in
case you would like to replicate my set-up, I can try to publish my
linux-4.8.y-based git branch so that you can build a similar kernel as
the one I use.

Vefa