netdev - Re: [PATCH net-next] rtnetlink: Allow setting IFLA_PERM

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]

Message-ID: <874j0ro1pd.fsf@toke.dk>
Date: Tue, 18 Feb 2025 13:51:42 +0100
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon Horman
 <horms@...nel.org>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] rtnetlink: Allow setting IFLA_PERM_ADDRESS at
 device creation time

Jakub Kicinski <kuba@...nel.org> writes:

> On Thu, 13 Feb 2025 17:13:53 +0100 Toke Høiland-Jørgensen wrote:
>> Jakub Kicinski <kuba@...nel.org> writes:
>> 
>> > On Thu, 13 Feb 2025 14:45:22 +0100 Toke Høiland-Jørgensen wrote:  
>> >> Eric suggested[0] allowing user-settable values for dev->perm_addr at
>> >> device creation time, instead of mucking about with netdevsim to get a
>> >> virtual device with a permanent address set.  
>> >
>> > I vote no. Complicating the core so that its easier for someone 
>> > to write a unit test is the wrong engineering trade off.
>> > Use a VM or netdevsim, that's what they are for.  
>> 
>> Hmm, and you don't see any value in being able to specify a permanent
>> identifier for virtual devices? That bit was not just motivated
>> reasoning on my part... :)
>
> I can't think of any :( Specifying an address is already possible.

Right, but the address can be changed later. Setting the perm_addr makes
it possible for a management daemon to set a unique identifier at device
creation time which is guaranteed to persist through any renames and
address changes that other utilities may perform. That seems like a
useful robustness feature that comes at a relatively low cost (the patch
is fairly small and uncomplicated)?

> Permanent address is a property of the hardware platform.
> Virtual devices OTOH are primarily used by containers, 
> which are ephemeral by design. At least that's my mental model.

Sure, any device feature that comes from hardware is only going to fit
virtual devices by analogy. But I don't think the analogy here is super
far fetched (cf the above)? :)

-Toke