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]
Date: Mon, 30 Oct 2023 07:58:52 +0900 (JST)
From: FUJITA Tomonori <>
Subject: Re: [PATCH net-next v7 1/5] rust: core abstractions for network
 PHY drivers

On Sun, 29 Oct 2023 09:48:41 -0700
Boqun Feng <> wrote:

> 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).

Benno said so? I'm not sure about the logic (whole v.s. partial). Even
if you read partially, the part might be modified by the C side during

For me, the issue is that creating &T for an object that might be

Powered by blists - more mailing lists