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: <41e9ec99-6993-4bb4-a5e5-ade7cf4927a4@proton.me>
Date: Mon, 30 Oct 2023 08:34:46 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Boqun Feng <boqun.feng@...il.com>, FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: 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 30.10.23 01:19, Boqun Feng wrote:
> On Mon, Oct 30, 2023 at 07:58:52AM +0900, FUJITA Tomonori wrote:
>> if you read partially, the part might be modified by the C side during
>> reading.
> 
> If you read the part protected by phy_device->lock, C side shouldn't
> modify it, but the case here is not all fields in phy_device stay
> unchanged when phy_device->lock (and Rust side doesn't mark them
> interior mutable), see the discussion drom Andrew and me.
> 
>>
>> For me, the issue is that creating &T for an object that might be
>> modified.
> 
> The reason a `&phy_device` cannot be created here is because concurrent
> writes may cause a invalid phy_device (i.e. data race), the same applies
> to a copy.

Both comments by Boqun above are correct. Additionally even if the write
would not have a data race with the read, it would still be UB. (For example
when the write is by the same thread)

If you just read the field itself then it should be fine, since it is
protected by a lock, see Boqun's patch for manually accessing the bitfields.

But I would wait until we see a response from the bindgen devs on the issue.

-- 
Cheers,
Benno



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ