Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1350682 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: soft lockup when passing vvar address to write(2) Andy Lutomirski <luto@amacapital.net> - 2016-03-05 00:50 +0100
    Re: soft lockup when passing vvar address to write(2) Thomas Gleixner <tglx@linutronix.de> - 2016-03-05 09:30 +0100
      Re: soft lockup when passing vvar address to write(2) Ingo Molnar <mingo@kernel.org> - 2016-03-05 10:10 +0100
        Re: soft lockup when passing vvar address to write(2) Andy Lutomirski <luto@amacapital.net> - 2016-03-06 04:00 +0100

#1350682 — Re: soft lockup when passing vvar address to write(2)

On Thu, Mar 3, 2016 at 11:26 PM, Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
> On 4 March 2016 at 01:17, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Thu, Mar 3, 2016 at 2:58 PM, Rasmus Villemoes
>> <linux@rasmusvillemoes.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@kernel.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

[toc] | [next] | [standalone]

#1350841

On Fri, 4 Mar 2016, Andy Lutomirski wrote:
> 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.

No objection from my side, really.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1350854

* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Fri, 4 Mar 2016, Andy Lutomirski wrote:
> > 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.
> 
> No objection from my side, really.

Seconded. HPET hardware overhead is typically horrifically large in any case, no 
need to memory map it and expose hardware breakages to user-space ...

It's also a (mild) security hole: a well-known HPET address can be abused as a 
statistical trampoline periodically cycling through 'dangerous' instruction 
values.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1351031

On Mar 5, 2016 1:04 AM, "Ingo Molnar" <mingo@kernel.org> wrote:
>
>
> * Thomas Gleixner <tglx@linutronix.de> wrote:
>
> > On Fri, 4 Mar 2016, Andy Lutomirski wrote:
> > > 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.
> >
> > No objection from my side, really.
>
> Seconded. HPET hardware overhead is typically horrifically large in any case, no
> need to memory map it and expose hardware breakages to user-space ...

I'll do it for 4.7.

>
> It's also a (mild) security hole: a well-known HPET address can be abused as a
> statistical trampoline periodically cycling through 'dangerous' instruction
> values.

That weakness has closed for quite a while -- it's mapped NX and it's
randomized.

I'm also not planning to revert the mapping security improvement --
even if we remove the HPET code, it still applies to kvmclock and to
anything else that gets added in the future.  It's also very little
code.

--Andy

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web