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: <e7da93d6-b938-4558-95b2-e9d2e0194621@proton.me>
Date: Sat, 28 Oct 2023 08:35:38 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Boqun Feng <boqun.feng@...il.com>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, andrew@...n.ch, 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 28.10.23 01:26, Boqun Feng wrote:
> On Fri, Oct 27, 2023 at 10:50:45PM +0000, Benno Lossin wrote:
> [...]
>>>
>>> Hmm... but does it mean even `set_speed()` has the similar issue?
>>>
>>> 	let phydev: *mut phy_device = self.0.get();
>>> 	unsafe { (*phydev).speed = ...; }
>>
>> No that should be fine, take a look at the MIR output of the following
>> code [1]:
>>
>>      struct Foo {
>>          a: usize,
>>          b: usize,
>>      }
>>
>>      fn foo(ptr: *mut Foo) {
>>          unsafe { (*ptr).b = 0; }
>>      }
>>
>>      fn bar(ptr: *mut Foo) {
>>          unsafe { (&mut *ptr).b = 0; }
>>      }
>>
>> Aside from some alignment checking, foo's MIR looks like this:
>>
>>      bb1: {
>>          ((*_1).1: usize) = const 0_usize;
>>          return;
>>      }
>>
>> And bar's MIR like this:
>>
>>      bb1: {
>>          _2 = &mut (*_1);
>>          ((*_2).1: usize) = const 0_usize;
>>          return;
>>      }
>>
>> [1]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f7c4d87bf29a64af0acc09ff75d3716d
>>
>> So I think that is fine, but maybe Gary has something else to say about it.
>>
> 
> Well when `-C opt-level=2`, they are the same:
> 
> 	https://godbolt.org/z/hxxo75YYh

It doesn't matter what the optimizer does, `bar` is unsound in our use-case
and `foo` is fine (I think).

-- 
Cheers,
Benno



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ