linux-kernel - Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction

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: <11ce9291-c17f-e73d-fb5d-13d5386fe6be@asahilina.net>
Date:   Thu, 9 Mar 2023 15:04:13 +0900
From:   Asahi Lina <lina@...hilina.net>
To:     Björn Roy Baron <bjorn3_gh@...tonmail.com>
Cc:     Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Miguel Ojeda <ojeda@...nel.org>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Wedson Almeida Filho <wedsonaf@...il.com>,
        Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Christian König <christian.koenig@....com>,
        Luben Tuikov <luben.tuikov@....com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Karol Herbst <kherbst@...hat.com>,
        Ella Stanforth <ella@...unix.org>,
        Faith Ekstrand <faith.ekstrand@...labora.com>,
        Mary <mary@...y.zone>, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, rust-for-linux@...r.kernel.org,
        linux-media@...r.kernel.org, linaro-mm-sig@...ts.linaro.org,
        linux-sgx@...r.kernel.org, asahi@...ts.linux.dev
Subject: Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction

On 08/03/2023 02.34, Björn Roy Baron wrote:
>> +                            // SAFETY: This is just the ioctl argument, which hopefully has the right type
>> +                            // (we've done our best checking the size).
> 
> In the rust tree there is the ReadableFromBytes [1] trait which indicates that it is safe to read arbitrary bytes into the type. Maybe you could add it as bound on the argument type when it lands in rust-next? This way you can't end up with for example a struct containing a bool with the byte value 2, which is UB.

There's actually a much bigger story here, because that trait isn't
really very useful without a way to auto-derive it. I need the same kind
of guarantee for all the GPU firmware structs...

There's one using only declarative macros [1] and one using proc macros
[2]. And then, since ioctl arguments are declared in C UAPI header
files, we need a way to be able to derive those traits for them... which
I guess means bindgen changes?

For now though, I don't think this is something we need to worry about
too much for this particular use case because the macro forces all
struct types to be part of `bindings`, and any driver UAPI should
already follow these constraints if it is well-formed (and UAPIs are
going to already attract a lot of scrutiny anyway). Technically you
could try taking a random kernel struct containing a `bool` in an ioctl
list, but that would stand out as nonsense just as much as trying to
unsafe impl ReadableFromBytes for it so... it's kind of an academic
problem ^^

Actually, I think we talked of moving UAPI types to a separate crate (so
drivers can get access to those types and only those types, not the main
bindings crate). Then maybe we could just say that if the macro forces
the type to be from that crate, it's inherently safe since all UAPIs
should already be castable to/from bytes if properly designed.

Aside: I'm not sure the ReadableFromBytes/WritableToBytes distinction is
very useful. I know it exists (padding bytes, uninit fields, and
technically bool should be WritableToBytes but not ReadableFromBytes),
but I can't think of a good use case for it... I think I'd rather start
with a single trait and just always enforce the union of the rules,
because pretty much any time you're casting to/from bytes you want
well-defined "bag of bytes" struct layouts anyway. ioctls can be R/W/RW
so having separate traits depending on ioctl type complicates the code...

[1]
https://github.com/QubesOS/qubes-gui-rust/blob/940754bfefb7325548eece658c307a0c41c9bc7c/qubes-castable/src/lib.rs
[2] https://docs.rs/pkbuffer/latest/pkbuffer/derive.Castable.html

> 
> https://rust-for-linux.github.io/docs/kernel/io_buffer/trait.ReadableFromBytes.html [1]
> 

~~ Lina