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:   Sat, 19 Jun 2021 10:55:35 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     David Laight <David.Laight@...LAB.COM>,
        Greg KH <gregkh@...uxfoundation.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Marek Behún <kabel@...nel.org>
Subject: Re: xhci_pci & PCIe hotplug crash

On Saturday 19 June 2021 09:53:58 Lukas Wunner wrote:
> On Wed, May 05, 2021 at 05:39:42PM +0200, Pali Rohár wrote:
> > On Wednesday 05 May 2021 15:20:11 David Laight wrote:
> > > From: Pali Rohár
> > > Sent: 05 May 2021 14:03
> > > > So seems that PCIe controller HW triggers these external aborts when
> > > > device on PCIe bus is not accessible anymore.
> > > > 
> > > > If this issue is really caused by MMIO access from xhci driver when
> > > > device is not accessible on the bus anymore, can we do something to
> > > > prevent this kernel crash? Somehow mask that external abort in kernel
> > > > for a time during MMIO access?
> > > 
> > > If it is a cycle abort then the interrupted address is probably
> > > that of the MMIO instruction.
> > > So you need to catch the abort, emulate the instruction and
> > > then return to the next one.
> > 
> > Has kernel API & infrastructure for catching these aborts and executing
> > own driver handler when abort happens?
> 
> Yes, see here for an example:
> 
> https://lore.kernel.org/linux-pci/20210615191405.21878-4-jim2101024@gmail.com/

What I do not see here how to catch and recover from error. It looks
like that in above patch is just implemented catching error, printing
more verbose output and let kernel continue in rebooting / crashing.

At least I do not see how to "catch the abort, emulate the instruction
and then return to the next one" as David wrote.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ