linux-kernel - Re: forcedeth ?

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: <46B351FB.1000507@gmx.net>
Date:	Fri, 03 Aug 2007 18:04:11 +0200
From:	Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@....net>
To:	Kay Sievers <kay.sievers@...y.org>
CC:	Gabriel C <nix.or.die@...glemail.com>,
	Sasa Ostrouska <casaxa@...il.com>,
	Avuton Olrich <avuton@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: forcedeth ?

On 02.08.2007 13:33, Kay Sievers wrote:
> On 7/31/07, Kay Sievers <kay.sievers@...y.org> wrote:
>> On 7/31/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@....net> wrote:
>>> On 31.07.2007 00:17, Gabriel C wrote:
>>>> Sasa Ostrouska wrote:
>>>>
>>>>> Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
>>>>> to check that, thx for the tip.
>>>> Yes udev does this based on the MAC address but AFAIK forcedeth is 'special' for some reason
>>>> ( which I can really remember now and gets on each boot a new MAC address or alike )
>>> Ah yes, that's a workaround for certain buggy boards to make sure you're
>>> not left without networking even if the MAC address stored on the board
>>> is bogus.
>>>
>>> Basically, forcedeth checks if the MAC address supplied by your
>>> mainboard is bogus and autogenerates a random MAC address from a private
>>> range (prefix 00:00:6c) as workaround. However, it will complain loudly
>>> if it has to do that.
>>>
>>> Quoting from forcedeth.c:
>>>> if (!is_valid_ether_addr(dev->perm_addr)) {
>>>>       /*
>>>>        * Bad mac address. At least one bios sets the mac address
>>>>        * to 01:23:45:67:89:ab
>>>>        */
>>>>       printk(KERN_ERR "%s: Invalid Mac address detected: %02x:%02x:%02x:%02x:%02x:%02x\n",
>>>>               pci_name(pci_dev),
>>>>               dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2],
>>>>               dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]);
>>>>       printk(KERN_ERR "Please complain to your hardware vendor. Switching to a random MAC.\n");
>>>>       dev->dev_addr[0] = 0x00;
>>>>       dev->dev_addr[1] = 0x00;
>>>>       dev->dev_addr[2] = 0x6c;
>>>>       get_random_bytes(&dev->dev_addr[3], 3);
>>>> }
>>> Sometimes it helps to update the BIOS and/or set the MAC address which
>>> is printed on the board as MAC address in the BIOS.
>> In any case, it would be nice if the network core could add something like:
>>   MAC_ORIGIN=device
>>   MAC_ORIGIN=user
>>   MAC_ORIGIN=random
>> or whatever makes sense here, to the uevent environment. So userspace
>> can handle according to that, like falling back using the
>> bus-slot-number to lookup the persistent name, or whatever is
>> appropriate.
> 
> Can't we use the "locally administered" bit in the MAC address? By
> checking for ENV{address}=="?[2367abef]:*", we would skip the
> persistent rule generation based on the MAC address?

Yes and no. Theoretically, that would work. However, there are two
problems with your rule specification:
- ENV{address}=="?[13579bdf]:*" are multicast addresses, so you wouldn't
want them tobe part of a network card MAC address at all.
- http://standards.ieee.org/regauth/oui/oui.txt tells us that the
following OIDs would be excluded by your rule:
02-07-01   (hex)                RACAL-DATACOM
02-1C-7C   (hex)                PERQ SYSTEMS CORPORATION
02-60-86   (hex)                LOGIC REPLACEMENT TECH. LTD.
02-60-8C   (hex)                3COM CORPORATION
02-70-01   (hex)                RACAL-DATACOM
02-70-B0   (hex)                M/A-COM INC. COMPANIES
02-70-B3   (hex)                DATA RECALL LTD
02-9D-8E   (hex)                CARDIAC RECORDERS INC.
02-AA-3C   (hex)                OLIVETTI TELECOMM SPA (OLTECO)
02-BB-01   (hex)                OCTOTHORPE CORP.
02-C0-8C   (hex)                3COM CORPORATION
02-CF-1C   (hex)                COMMUNICATION MACHINERY CORP.
02-E6-D3   (hex)                NIXDORF COMPUTER CORPORATION
AA-00-00   (hex)                DIGITAL EQUIPMENT CORPORATION
AA-00-01   (hex)                DIGITAL EQUIPMENT CORPORATION
AA-00-02   (hex)                DIGITAL EQUIPMENT CORPORATION
AA-00-03   (hex)                DIGITAL EQUIPMENT CORPORATION
AA-00-04   (hex)                DIGITAL EQUIPMENT CORPORATION

Since it seems that real OIDs conflict with the "locally adminstered"
bit of the MAC address, I don't see a way to use the MAC address as
indicator for persistent rule eligibility.


Regards,
Carl-Daniel
-
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/