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

[Asahi Lina <lina@asahilina.net>]

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