linux-kernel - Re: soft lockup when passing vvar address to write(2)

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: <CALCETrVLbXpqUCdsFrHD+jBx=+fUb6=00j=-_v22VPdYEY-aTg@mail.gmail.com>
Date:	Fri, 4 Mar 2016 15:44:31 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:	Andy Lutomirski <luto@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>
Subject: Re: soft lockup when passing vvar address to write(2)

On Thu, Mar 3, 2016 at 11:26 PM, Rasmus Villemoes
<linux@...musvillemoes.dk> wrote:
> On 4 March 2016 at 01:17, Andy Lutomirski <luto@...capital.net> wrote:
>> On Thu, Mar 3, 2016 at 2:58 PM, Rasmus Villemoes
>> <linux@...musvillemoes.dk> wrote:
>>> Looking up the vvar mapping and dumping its contents sometimes results
>>> in a soft lockup. On 4.5-rc6+ (master from earlier today) it seems to be
>>> a little harder to trigger than on the 4.2something Ubuntu kernel I
>>> first saw it on, but in both cases it's easy to reproduce (10s of
>>> iterations at most) by running the below program in a loop.
>>>
>>
>> I can't reproduce this.  Do you have a .config or some other hint?
>
> 4.2 config below, the 4.5 one is made from that with make olddefconfig.
>
>> Can you also give me the contents of
>> /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> tsc
>
>> the output from 'dmesg |grep -i hpet'?
>
> $ dmesg | grep -i hpet
> [    0.000000] ACPI: HPET 0x00000000C8FE6238 000038 (v01 DELL   CBX3
>   01072009 AMI. 00000005)
> [    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
> [    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles:
> 0xffffffff, max_idle_ns: 133484882848 ns
> [    0.000000] hpet clockevent registered
> [    0.034922] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
> [    0.181862] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
> [    0.181865] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
> [    0.183894] clocksource: Switched to clocksource hpet
> [    0.597484] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes
> nvram, hpet irqs
>
>
>> And is this in a VM or on a native boot?
>
> It's on a Dell precision M2800 laptop (8 core, core-i7).

This presumably means that your HPET is unusually crappy.

An upcoming mitigation in 4.6 should prevent you from observing this
problem on your laptop:

commit bd902c536298830e4d126dcf6491b46d3f1bf96e
Author: Andy Lutomirski <luto@...nel.org>
Date:   Tue Dec 29 20:12:24 2015 -0800

    x86/vdso: Disallow vvar access to vclock IO for never-used vclocks


Thomas, I still think we should consider just deleting the HPET vclock
code and accept the syscall overhead on systems that are stuck using
HPET.  If fast syscalls are available (which should include every
system with HPET, unless there are some 32-bit AMD systems lying
around), then the overhead in a syscall is *tiny* compared to the code
of the HPET read itself.

--Andy