netdev - Re: [PATCH net-next] net/ncsi: allow to customize BMC MAC Address offset

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 9 Aug 2019 05:29:39 +0000
From:   Tao Ren <taoren@...com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "openbmc@...ts.ozlabs.org" <openbmc@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Samuel Mendoza-Jonas <sam@...dozajonas.com>,
        "David S . Miller" <davem@...emloft.net>,
        William Kennington <wak@...gle.com>
Subject: Re: [PATCH net-next] net/ncsi: allow to customize BMC MAC Address
 offset

On 8/8/19 4:03 PM, Andrew Lunn wrote:
>> After giving it more thought, I'm thinking about adding ncsi dt node
>> with following structure (mac/ncsi similar to mac/mdio/phy):
>>
>> &mac0 {
>>     /* MAC properties... */
>>
>>     use-ncsi;
> 
> This property seems to be specific to Faraday FTGMAC100. Are you going
> to make it more generic? 

I'm also using ftgmac100 on my platform, and I don't have plan to change this property.

>>     ncsi {
>>         /* ncsi level properties if any */
>>
>>         package@0 {
> 
> You should get Rob Herring involved. This is not really describing
> hardware, so it might get rejected by the device tree maintainer.

Got it. Thank you for the sharing, and let me think it over :-)

>> 1) mac driver doesn't need to parse "mac-offset" stuff: these
>> ncsi-network-controller specific settings should be parsed in ncsi
>> stack.
> 
>> 2) get_bmc_mac_address command is a channel specific command, and
>> technically people can configure different offset/formula for
>> different channels.
> 
> Does that mean the NCSA code puts the interface into promiscuous mode?
> Or at least adds these unicast MAC addresses to the MAC receive
> filter? Humm, ftgmac100 only seems to support multicast address
> filtering, not unicast filters, so it must be using promisc mode, if
> you expect to receive frames using this MAC address.

Uhh, I actually didn't think too much about this: basically it's how to configure frame filtering when there are multiple packages/channels active: single BMC MAC or multiple BMC MAC is also allowed?
I don't have the answer yet, but will talk to NCSI expert and figure it out.


Thanks,

Tao