linux-kernel - Re: [PATCH] net-tg3: Initialize REG_BASE

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: <20131210.222313.694303616856894486.davem@davemloft.net>
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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/