On Fri, Jul 9, 2021 at 10:20 PM Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Jul 09, 2021 at 10:00:32PM +0800, Zheyu Ma wrote: > > On Thu, Jul 8, 2021 at 3:13 AM Jiri Slaby <jirislaby@xxxxxxxxxx> wrote: > > > > > > On 07. 07. 21, 14:52, Andy Shevchenko wrote: > > > > On Wed, Jul 7, 2021 at 10:50 AM Jiri Slaby <jirislaby@xxxxxxxxxx> wrote: > > > >> On 05. 07. 21, 14:53, Zheyu Ma wrote: > > > > > > > >> So how it comes an interrupt came before > > > >> neo_param() in jsm_tty_open was called? > > > > > > > > If IRQ is shared we have a special debug feature to test shared IRQs > > > > on freeing IRQ stage (*). > > > > But it doesn't matter, the IRQ handler must survive at any stage after > > > > the action has been listed. > > > > > > Yes, but IRQ_NONE is returned from the ISR in that case. > > > > > > The issue the patch is fixing is for a "malicious" device and I am not > > > sure we want to fix this -- if I can put in a malicious device, I can > > > use hammer to kill the box too… > > > > Well, this threat assumption is indeed strong, but this attack may be > > real. For example, some programmable USB devices (such as FaceDancer) > > may exploit vulnerabilities in the USB device driver to attack. Of > > course, there has not been such an attack in the real world for PCI > > devices. Or, some devices with DMA functions may also send malicious > > data and some previous kernel commits have also fixed such bugs. > > > > Anyway, thanks for your patient comments. > > Right now, yes, we treat USB devices as "possibly malicious". We do not > do so for PCI devices yet. If we want to do that, then we need to do a > lot of work, not just "this one call in this one driver" type of thing > as there are much bigger issues involved here. > > If you wish to take on this work, as you feel PCI devices should be > treated this way, please do so! But start in the PCI core at the very > least, before worrying about the thousands of individual drivers. Alright, I understand. Thank you for your valuable suggestions, I will continue to learn and make more contributions to the kernel. Regards, Zheyu Ma
