linux-kernel - Re: x86/irq: Unbreak interrupt affinity setting

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: <014fd671-73c1-97f3-cc92-73c2cf9576af@amazon.com>
Date:   Thu, 27 Aug 2020 00:52:48 +0200
From:   Alexander Graf <graf@...zon.com>
To:     David Laight <David.Laight@...LAB.COM>,
        'Thomas Gleixner' <tglx@...utronix.de>,
        'X86 ML' <x86@...nel.org>
CC:     'Andy Lutomirski' <luto@...nel.org>,
        'LKML' <linux-kernel@...r.kernel.org>,
        'Andrew Cooper' <andrew.cooper3@...rix.com>,
        "'Paul E. McKenney'" <paulmck@...nel.org>,
        'Alexandre Chartre' <alexandre.chartre@...cle.com>,
        'Frederic Weisbecker' <frederic@...nel.org>,
        'Paolo Bonzini' <pbonzini@...hat.com>,
        'Sean Christopherson' <sean.j.christopherson@...el.com>,
        'Masami Hiramatsu' <mhiramat@...nel.org>,
        'Petr Mladek' <pmladek@...e.com>,
        'Steven Rostedt' <rostedt@...dmis.org>,
        'Joel Fernandes' <joel@...lfernandes.org>,
        'Boris Ostrovsky' <boris.ostrovsky@...cle.com>,
        'Juergen Gross' <jgross@...e.com>,
        "'Mathieu Desnoyers'" <mathieu.desnoyers@...icios.com>,
        'Josh Poimboeuf' <jpoimboe@...hat.com>,
        'Will Deacon' <will@...nel.org>,
        'Tom Lendacky' <thomas.lendacky@....com>,
        'Wei Liu' <wei.liu@...nel.org>,
        'Michael Kelley' <mikelley@...rosoft.com>,
        'Jason Chen CJ' <jason.cj.chen@...el.com>,
        "'Zhao Yakui'" <yakui.zhao@...el.com>,
        "'Peter Zijlstra (Intel)'" <peterz@...radead.org>,
        'Avi Kivity' <avi@...lladb.com>,
        "'Herrenschmidt, Benjamin'" <benh@...zon.com>,
        "'robketr@...zon.de'" <robketr@...zon.de>,
        "'amos@...lladb.com'" <amos@...lladb.com>,
        'Brian Gerst' <brgerst@...il.com>,
        "'stable@...r.kernel.org'" <stable@...r.kernel.org>,
        'Alex bykov' <alex.bykov@...lladb.com>
Subject: Re: x86/irq: Unbreak interrupt affinity setting



On 26.08.20 23:47, David Laight wrote:
> 
> From: David Laight
>> Sent: 26 August 2020 22:37
>>
>> From: Thomas Gleixner
>>> Sent: 26 August 2020 21:22
>> ...
>>> Moving interrupts on x86 happens in several steps. A new vector on a
>>> different CPU is allocated and the relevant interrupt source is
>>> reprogrammed to that. But that's racy and there might be an interrupt
>>> already in flight to the old vector. So the old vector is preserved until
>>> the first interrupt arrives on the new vector and the new target CPU. Once
>>> that happens the old vector is cleaned up, but this cleanup still depends
>>> on the vector number being stored in pt_regs::orig_ax, which is now -1.
>>
>> I suspect that it is much more 'racy' than that for PCI-X interrupts.
>> On the hardware side there is an interrupt disable bit, and address
>> and a value.
>> To raise an interrupt the hardware must write the value to the address.
>>
>> If the cpu needs to move an interrupt both the address and value
>> need changing, but the cpu wont write the address and value using
>> the same TLP, so the hardware could potentially write a value to
>> the wrong address.
>> Worse than that, the hardware could easily only look at the address
>> and value in the clocks after checking the interrupt is enabled.
>> So masking the interrupt immediately prior to changing the vector
>> info may not be enough.
>>
>> It is likely that a read-back of the mask before updating the vector
>> is enough.
> 
> But not enough to assume you won't receive an interrupt after reading
> back that interrupts are masked.
> 
> (I've implemented the hardware side for an fpga ...)

Do we actually care in this context? All we want to know here is whether 
a device (or irqchip in between) has actually noticed that it should 
post to a new vector. If we get interrupts on random other vectors in 
between, they would simply show up as spurious, no?

So I don't quite see where this patch makes the situation any worse than 
before.


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879