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
| ||
|
Message-ID: <5e493b59-728a-43ee-a503-3ad989579720@proton.me> Date: Sat, 21 Oct 2023 16:31:32 +0000 From: Benno Lossin <benno.lossin@...ton.me> To: Andrew Lunn <andrew@...n.ch> Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, miguel.ojeda.sandonis@...il.com, tmgross@...ch.edu, boqun.feng@...il.com, wedsonaf@...il.com, greg@...ah.com Subject: Re: [PATCH net-next v5 1/5] rust: core abstractions for network PHY drivers On 21.10.23 17:57, Andrew Lunn wrote: >> I see, what exactly is the problem with that? In other words: >> why does PHYLIB need `phy_driver` to stay at the same address? > > Again, pretty standard kernel behaviour. The core keeps a linked list > of drivers which have been registered with it. So when the driver > loads, it calls phy_driver_register() and the core adds the passed > structure to a linked list of drivers. Sometime later, the bus is > enumerated and devices found. The core will read a couple of registers > which contain the manufactures ID, model and revision. The linked list > of drivers is walked and a match is performed on the IDs. When a match > is found, phydev->drv is set to the driver structure. Calls into the > driver are then performed through this pointer. We have several examples of abstractions over things that embed linked lists upstream already (e.g. `mutex`) and have developed a special API that handles them very well. This API ensures that the values cannot be moved (and if one tries to move it, the compiler errors). In this case I was not aware of the requirement -- and it was also not noted in any SAFETY comment (e.g. on `phy_drivers_register`). > A typically C driver has statically initialised driver structures > which are placed in the data section, or better still the rodata > section. They are not going anywhere until the driver is unloaded. So > there is no problem keeping them on a linked list. Dynamically > creating them is unusual. They are just structures of pointers to > functions, everything is known at link time. In the ideal case I would just like to store them inside of the `Module` struct (which is placed in the data section). However, that requires Wedson's patch I linked in this thread. -- Cheers, Benno
Powered by blists - more mailing lists