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

Date:   Mon, 25 Nov 2019 17:13:11 -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 2:46 PM Heiner Kallweit <hkallweit1@...il.com> wrote:
> On 23.11.2019 01:51, Brian Norris wrote:
> > On Wed, Nov 13, 2019 at 09:30:42PM +0100, Heiner Kallweit wrote:
> >> If recompiling the BIOS isn't an option,
> >
> > It's not 100% impossible, but it seems highly unlikely to happen. To me
> > (and likely the folks responsible for this BIOS), this looks like a
> > kernel regression (this driver worked just fine for me before commit
> > 89cceb2729c7).
> >
> On an additional note:
> The referenced coreboot driver is part of the Google JECHT baseboard
> support. Most likely the driver is just meant to support the Realtek
> chip version found on this board. I doubt the driver authors intended
> to support each and every Realtek NIC chip version.

I understand that -- I'm specifically seeing problems on the Jecht
family of devices (Jecht was the reference board), which is why I
pointed you there :) All devices in that family use a Realtek chipset
that appears to be RTL8168G, and they all only program the registers I
pointed at in the first place.

One side note: I'm not quite sure how (again, no documentation...) but
some devices appear to have a different valid MAC address in the
GigaMAC register, which is why I see this problem. If they all just
left it 0x00, then I'd be in OK shape.

Brian