linux-kernel - Re: [PATCH] net/r8169: Update the new parser for the new firmware

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] [day] [month] [year] [list]

Message-ID: <20110614230438.GA1746@electric-eye.fr.zoreil.com>
Date:	Wed, 15 Jun 2011 01:04:38 +0200
From:	Francois Romieu <romieu@...zoreil.com>
To:	hayeswang <hayeswang@...ltek.com>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net/r8169: Update the new parser for the new firmware

hayeswang <hayeswang@...ltek.com> :
[...]
> I want to keep the old firmware used by the old paser. The old paser cannot
> use the new firmware and the new paser cannot use the old firmware, so I
> separate them.

Two points:
1. it can be done anyway. See below.
2. I agree with a different name, thoug only in the linux-firmware git
   repository and in the local filesystem firmware directory. Naming the
   relevant file for FIRMWARE_8168D_1 something like "rtl8168d-1[_-.]x.y.z"
   in the linux-firmware repository exhibits some self documenting virtues.
   rtl8168d-1.fw only needs to link to the firmware of the day. On the other
   hand, retrieving FIRMWARE_8168D_1 through rtl8168d-3.fw - and tomorrow
   through rtl8168d-7.fw ? - is imho convoluted and mildly nice to maintain
   when there are FIRMWARE_8168D_1, FIRMWARE_8168D_2 etc.

[...]
> > Imho the new firmware format could include some specific 
> > string so that the driver can identify the new firmware 
> > format and fallback to the old format otherwise. Any fixed 
> > magic prefix would be enough as the new format mandates the 
> > version information.
> > 
> > This way Linus's test machine won't risk of breaking 
> > (again...) if he builds a new kernel without updating the 
> > firmware at the same time.
> > 
> 
> I plan to let the old paser loads the old firmware and the new paser loads the
> new firmware. If you build the new kernel without updating the firmware, you
> just load no firmware because the new firmware doesn't exist. However, it is
> more dangerous for the old paser to load the new firmware. That is why I
> create the new ones, not replace the existing files.

Regarding the old driver and new firmware combination, it is possible to
design the new firmware format so that it gets ignored by the old driver.
If the new firmware format starts with a huge PHY_SKIPN instruction,
the old parser will not use it and will emit an "Out of range of firmware"
error message. Add a magic prefix and the new driver has some decent
heuristic to figure if it handles a new / old format firmware.

Regarding the new driver and old firmware combination, why should the new
driver be allowed to refuse working with the old firmware if the old firmware
is not known broken ?

-- 
Ueimor
--
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/