netdev - Re: [PATCH net-next v7 1/5] rust: core abstractions for network PHY drivers

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: <20231030.214906.1040067379741914267.fujita.tomonori@gmail.com>
Date: Mon, 30 Oct 2023 21:49:06 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: benno.lossin@...ton.me
Cc: boqun.feng@...il.com, fujita.tomonori@...il.com, 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 Mon, 30 Oct 2023 08:34:46 +0000
Benno Lossin <benno.lossin@...ton.me> wrote:

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

The rust code can access to only fields in phy_device that the C side
doesn't modify; these fields are protected by a lock or in other ways
(resume/suspend cases).

Right?

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

You meant that they might have a different option on this?