linux-kernel - Re: [PATCH] [RFC] r8169: check for valid MAC before clobbering

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]

Date:   Mon, 25 Nov 2019 17:23:29 -0800
From:   Brian Norris <briannorris@...omium.org>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Realtek linux nic maintainers <nic_swsd@...ltek.com>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        "<netdev@...r.kernel.org>" <netdev@...r.kernel.org>,
        Chun-Hao Lin <hau@...ltek.com>
Subject: Re: [PATCH] [RFC] r8169: check for valid MAC before clobbering

On Sat, Nov 23, 2019 at 1:59 AM Heiner Kallweit <hkallweit1@...il.com> wrote:
> Realtek doesn't provide any public datasheets, only very few leaked
> old datasheets are available. Only public source of information is
> the vendor drivers: r8168/r8101/r8125.
> Check the vendor drivers for where they read the MAC from.

Thanks, I looked it up, and IIUC the chips I'm using would fall under
the vendor driver's 'CFG_METHOD_21', which does indeed check the GMAC
registers as a priority. (It's also even worse than the upstream
driver here: although it reads out the active MAC register first, it
doesn't end up using the value and instead just clobbers it, even if
the GMAC value is empty/garbage.)

So I guess the vendor driver "always" failed me in the same way, and
it's just the Coreboot authors who were misinformed. :(

Thanks for the pointers,
Brian