netdev - Re: Realtek 8169 problems with net booting

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: <20081204.101503.154423248.davem@davemloft.net>
Date:	Thu, 04 Dec 2008 10:15:03 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	mbrown@...systems.co.uk
Cc:	alan@...rguk.ukuu.org.uk, netdev@...r.kernel.org
Subject: Re: Realtek 8169 problems with net booting

From: Michael Brown <mbrown@...systems.co.uk>
Date: Thu, 4 Dec 2008 17:22:26 +0000

> On Monday 24 November 2008 21:57:10 David Miller wrote:
> > Yes, a lot of drivers will enable bus mastering before resetting
> > the chip.
> >
> > The basic assumption is that the chip is quiescent at driver load
> > time.
> >
> > Since switching around this order across the board is too
> > gigantic a project, I would suggest just handling things on
> > a case-by-case basis where we know the BIOS or firmware leave
> > the chip in a crud state like this.
> 
> The assumption that the chip is quiescent is invalid in the case of any kind 
> of boot from SAN (e.g. iSCSI, AoE) via the net device.  The INT13-based 
> bootloader has no way to signal to the boot firmware that it is finished 
> using the INT13 interface, so the card will always be left in an active 
> state.

So there is no "close" method for the boot loader to call?
Who designs this crud? :-(

> In gPXE, we do what we can to ensure that the card is safe to use when the OS 
> loads; we edit the RX buffers, ISR, etc. out of the system memory map prior 
> to starting an iSCSI boot.  We don't, however, get a chance to actually 
> quiesce the chip before the OS driver loads up, so the OS driver must be 
> prepared to discover the chip in an active state.

It's really unfortunate that things have been setup so poorly.

So OK, we have to handle this.
--
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