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
| ||
|
Date: Tue, 10 Dec 2013 22:23:13 -0500 (EST) From: David Miller <davem@...emloft.net> To: mchan@...adcom.com Cc: sergei.shtylyov@...entembedded.com, natg@...gle.com, nsujir@...adcom.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] net-tg3: Initialize REG_BASE_ADDR at PCI config offset 120 to 0 From: Michael Chan <mchan@...adcom.com> Date: Tue, 10 Dec 2013 10:49:39 -0800 > On Tue, 2013-12-10 at 13:43 -0500, David Miller wrote: > >> What if the kernel is booted via kexec, and the driver in the kernel >> we are kexec'ing from left indirect access enabled in MISC_HOST_CTRL? > > That should be ok. The driver will only use valid register offsets in > indirect mode during run time, so register 0x78 should point to a valid > register. If indirect mode is never used by the driver, it will point > to zero with this patch. So register 0x78 will be valid (or zero) in > the kexec'ed kernel. Ok, that may be true, but I'd like to consider the much larger issue at hand. If the indirect mechanism is enabled, some of the offsets that may be in there might be value, but would be entirely undesirable to be read because the read has side effects. What if the interrupt status register is what gets read if the user scans config space at just the wrong moment, and therefore an interrupt gets lost? I understand that the patch we are discussing is a serious improvement from the current situation, so I will apply it and queue it up for -stable. However I think we need to do something reasonable to prevent the kinds of situations I described above. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists