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: <ZT6M6WPrCaLb-0QO@Boquns-Mac-mini.home> Date: Sun, 29 Oct 2023 09:48:41 -0700 From: Boqun Feng <boqun.feng@...il.com> To: FUJITA Tomonori <fujita.tomonori@...il.com> Cc: benno.lossin@...ton.me, andrew@...n.ch, netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, tmgross@...ch.edu, miguel.ojeda.sandonis@...il.com, wedsonaf@...il.com Subject: Re: [PATCH net-next v7 1/5] rust: core abstractions for network PHY drivers On Sun, Oct 29, 2023 at 01:21:12PM +0900, FUJITA Tomonori wrote: [...] > > The current code is fine from Rust perspective because the current > code copies phy_driver on stack and makes a reference to the copy, if > I undertand correctly. > I had the same thought Benno brought the issue on `&`, but unfortunately it's not true ;-) In the following code: let phydev = unsafe { *self.0.get() }; , semantically the *whole* `bindings::phy_device` is being read, so if there is any modification (i.e. write) that may happen in the meanwhile, it's data race, and data races are UB (even in C). So both implementations have the problem because of the same cause. > It's not nice to create an 500-bytes object on stack. It turned out > that it's not so simple to avoid it. As you can see, copying is not the way to work around this. Regards, Boqun
Powered by blists - more mailing lists