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: <20231021.223115.1115424295905877996.fujita.tomonori@gmail.com> Date: Sat, 21 Oct 2023 22:31:15 +0900 (JST) From: FUJITA Tomonori <fujita.tomonori@...il.com> To: benno.lossin@...ton.me Cc: fujita.tomonori@...il.com, netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, andrew@...n.ch, 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 Sat, 21 Oct 2023 13:05:59 +0000 Benno Lossin <benno.lossin@...ton.me> wrote: > On 21.10.23 15:00, FUJITA Tomonori wrote: >> On Sat, 21 Oct 2023 12:50:10 +0000 >> Benno Lossin <benno.lossin@...ton.me> wrote: >>>>>>> I think this is very weird, do you have any idea why this >>>>>>> could happen? >>>>>> >>>>>> DriverVtable is created on kernel stack, I guess. >>>>> >>>>> But how does that invalidate the function pointers? >>>> >>>> Not only funciton pointers. You can't store something on stack for >>>> later use. >>> >>> It is not stored on the stack, it is only created on the stack and >>> moved to a global static later on. The `module!` macro creates a >>> `static mut __MOD: Option<Module>` where the module data is stored in. >> >> I know. The problem is that we call phy_drivers_register() with >> DriverVTable on stack. Then it was moved. > > I see, what exactly is the problem with that? In other words: > why does PHYLIB need `phy_driver` to stay at the same address? phy_driver_register stores addresses that you passed. > This is an important requirement in Rust. Rust can ensure that > types are not moved by means of pinning them. In this case, Wedson's > patch below should fix the issue completely. > > But we should also fix this in the abstractions, the `DriverVTable` > type should only be constructible in a pinned state. For this purpose > we have the `pin-init` API [2]. You can create DriverVTable freely. The restriction is what phy_driver_register takes. Currently, it needs &'static DriverVTable array so it works. The C side uses static allocation too. If someone asks for, we could loosen the restriction with a complicated implentation. But I doubt that someone would ask for such. > Are there any other things in PHY that must not change address? I don't think so.
Powered by blists - more mailing lists