linux-kernel - Re: [RFC PATCH] PCI, kdump: Clear bus master bit upon shutdown in kdump kernel

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200306093829.GA27711@MiWiFi-R3L-srv>
Date:   Fri, 6 Mar 2020 17:38:29 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Deepa Dinamani <deepa.kernel@...il.com>
Cc:     Kairui Song <kasong@...hat.com>,
        Bjorn Helgaas <helgaas@...nel.org>,
        Khalid Aziz <khalid@...ehiking.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-pci@...r.kernel.org, kexec@...ts.infradead.org,
        Jerry Hoemann <jerry.hoemann@....com>,
        Randy Wright <rwright@....com>, Dave Young <dyoung@...hat.com>,
        Myron Stowe <myron.stowe@...hat.com>, jroedel@...e.de
Subject: Re: [RFC PATCH] PCI, kdump: Clear bus master bit upon shutdown in
 kdump kernel

On 03/04/20 at 08:53pm, Deepa Dinamani wrote:
> On Wed, Mar 4, 2020 at 7:53 PM Baoquan He <bhe@...hat.com> wrote:
> >
> > +Joerg to CC.
> >
> > On 03/03/20 at 01:01pm, Deepa Dinamani wrote:
> > > I looked at this some more. Looks like we do not clear irqs when we do
> > > a kexec reboot. And, the bootup code maintains the same table for the
> > > kexec-ed kernel. I'm looking at the following code in
> >
> > I guess you are talking about kdump reboot here, right? Kexec and kdump
> > boot take the similar mechanism, but differ a little.
> 
> Right I meant kdump kernel here. And, clearly the is_kdump_kernel() case below.
> 
> >
> > > intel_irq_remapping.c:
> > >
> > >         if (ir_pre_enabled(iommu)) {
> > >                 if (!is_kdump_kernel()) {
> > >                         pr_warn("IRQ remapping was enabled on %s but
> > > we are not in kdump mode\n",
> > >                                 iommu->name);
> > >                         clear_ir_pre_enabled(iommu);
> > >                         iommu_disable_irq_remapping(iommu);
> > >                 } else if (iommu_load_old_irte(iommu))
> >
> > Here, it's for kdump kernel to copy old ir table from 1st kernel.
> 
> Correct.
> 
> > >                         pr_err("Failed to copy IR table for %s from
> > > previous kernel\n",
> > >                                iommu->name);
> > >                 else
> > >                         pr_info("Copied IR table for %s from previous kernel\n",
> > >                                 iommu->name);
> > >         }
> > >
> > > Would cleaning the interrupts(like in the non kdump path above) just
> > > before shutdown help here? This should clear the interrupts enabled
> > > for all the devices in the current kernel. So when kdump kernel
> > > starts, it starts clean. This should probably help block out the
> > > interrupts from a device that does not have a driver.
> >
> > I think stopping those devices out of control from continue sending
> > interrupts is a good idea. While not sure if only clearing the interrupt
> > will be enough. Those devices which will be initialized by their driver
> > will brake, but devices which drivers are not loaded into kdump kernel
> > may continue acting. Even though interrupts are cleaning at this time,
> > the on-flight DMA could continue triggerring interrupt since the ir
> > table and iopage table are rebuilt.
> 
> This should be handled by the IOMMU, right? And, hence you are getting
> UR. This seems like the correct execution flow to me.

Sorry for late reply.
Yes, this is initializing IOMMU device.

> 
> Anyway, you could just test this theory by removing the
> is_kdump_kernel() check above and see if it solves your problem.
> Obviously, check the VT-d spec to figure out the exact sequence to
> turn off the IR.

OK, I will talk to Kairui and get a machine to test it. Thanks for your
nice idea, if you have a draft patch, we are happy to test it.

> 
> Note that the device that is causing the problem here is a legit
> device. We want to have interrupts from devices we don't know about
> blocked anyway because we can have compromised firmware/ devices that
> could cause a DoS attack. So blocking the unwanted interrupts seems
> like the right thing to do here.

Kairui said it's a device which driver is not loaded in kdump kernel
because it's not needed by kdump. We try to only load kernel modules
which are needed, e.g one device is the dump target, its driver has to
be loaded in. In this case, the device is more like a out of control
device to kdump kernel.