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: <20230331012006.251b5729.gary@garyguo.net>
Date:   Fri, 31 Mar 2023 01:20:06 +0100
From:   Gary Guo <gary@...yguo.net>
To:     Alice Ryhl <alice@...l.io>
Cc:     y86-dev@...tonmail.com, Miguel Ojeda <ojeda@...nel.org>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Wedson Almeida Filho <wedsonaf@...il.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Björn Roy Baron <bjorn3_gh@...tonmail.com>,
        rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
        patches@...ts.linux.dev
Subject: Re: [PATCH v3 09/13] rust: init: add `Zeroable` trait and
 `init::zeroed` function

On Fri, 31 Mar 2023 00:40:34 +0200
Alice Ryhl <alice@...l.io> wrote:

> On 3/30/23 00:33, y86-dev@...tonmail.com wrote:
> > From: Benno Lossin <y86-dev@...tonmail.com>
> > 
> > Add the `Zeroable` trait which marks types that can be initialized by
> > writing `0x00` to every byte of the type. Also add the `init::zeroed`
> > function that creates an initializer for a `Zeroable` type that writes
> > `0x00` to every byte.
> > 
> > Signed-off-by: Benno Lossin <y86-dev@...tonmail.com>
> > ---
> > +// SAFETY: `null` pointer is valid.
> > +unsafe impl<T: ?Sized> Zeroable for *mut T {}
> > +unsafe impl<T: ?Sized> Zeroable for *const T {}  
> 
> Actually, I just realized that this is not ok for unsized types. When T 
> is unsized, the raw pointer is a fat pointer with a vtable, and the 
> vtable part is not necessarily zeroable.
> 
> However, it would be ok to do it for `*const [T]` since the fat part of 
> the pointer is just the length in this case, and a length of zero is fine.
> 
> See more here:
> https://github.com/Lokathor/bytemuck/blob/8391afa876ba2e99dffb0c991cc7fa775287d106/src/zeroable.rs#L56-L65

Good catch. vtable completely slipped my mind when I am reviewing this
code.

Vtable is not *not necessary zeroable*, but actually never zeroable.
Although currently not yet formally specified, the compiler has always
assumed vtable part of fat pointers to be non-null, well aligned and
dereferenceable.

Best,
Gary

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ