netdev - Re: Proposal: r8152 firmware patching framework

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]

Date:   Sat, 31 Aug 2019 00:53:35 +0000
From:   Amber Chen <amber.chen@...ltek.com>
To:     Prashant Malani <pmalani@...omium.org>
CC:     Hayes Wang <hayeswang@...ltek.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Bambi Yeh <bambi.yeh@...ltek.com>,
        Ryankao <ryankao@...ltek.com>, Jackc <jackc@...ltek.com>,
        Albertk <albertk@...ltek.com>,
        "marcochen@...gle.com" <marcochen@...gle.com>,
        nic_swsd <nic_swsd@...ltek.com>,
        Grant Grundler <grundler@...omium.org>
Subject: Re: Proposal: r8152 firmware patching framework

+ acct mgr, Stephen



> Prashant Malani <pmalani@...omium.org> 於 2019年8月31日 上午6:24 寫道：
> 
> (Adding a few more Realtek folks)
> 
> Friendly ping. Any thoughts / feedback, Realtek folks (and others) ?
> 
>> On Thu, Aug 29, 2019 at 11:40 AM Prashant Malani <pmalani@...omium.org> wrote:
>> 
>> Hi,
>> 
>> The r8152 driver source code distributed by Realtek (on
>> www.realtek.com) contains firmware patches. This involves binary
>> byte-arrays being written byte/word-wise to the hardware memory
>> Example: grundler@...omium.org (cc-ed) has an experimental patch which
>> includes the firmware patching code which was distributed with the
>> Realtek source :
>> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1417953
>> 
>> It would be nice to have a way to incorporate these firmware fixes
>> into the upstream code. Since having indecipherable byte-arrays is not
>> possible upstream, I propose the following:
>> - We use the assistance of Realtek to come up with a format which the
>> firmware patch files can follow (this can be documented in the
>> comments).
>>       - A real simple format could look like this:
>>               +
>> <section1><size_in_bytes><address1><data1><address2><data2>...<addressN><dataN><section2>...
>>                + The driver would be able to understand how to parse
>> each section (e.g is each data entry a byte or a word?)
>> 
>> - We use request_firmware() to load the firmware, parse it and write
>> the data to the relevant registers.
>> 
>> I'm unfamiliar with what the preferred method of firmware patching is,
>> so I hope the maintainers can help suggest the best path forward.
>> 
>> As an aside: It would be great if Realtek could publish a list of
>> fixes that the firmware patches implement (I think a list on the
>> driver download page on the Realtek website would be an excellent
>> starting point).
>> 
>> Thanks and Best regards,
>> 
>> -Prashant
> 
> ------Please consider the environment before printing this e-mail.