Add unsafe_protocol macro and drop use of the unstable negative_impls feature

[nicholasbishop]

Our protocols are all marked !Send and !Sync using the unstable negative_impls feature. There's another way to mark things !Send and !Sync though: add a field that itself is !Send and !Sync, for example a raw pointer. We don't want to actually change the struct layout of course, but we can use the PhantomData type for this.

The new unsafe_protocol macro implements this idea; it's an attribute macro that combines the functionality of the unsafe_guid attribute macro and the Protocol derive macro, as well as adding a hidden core::marker::PhantomData<*const u8> field for !Send and !Sync.

The real purpose of this change is to remove use of the unstable negative_impls feature towards our goal of building on the stable channel. But it also ends up with a slightly nicer API as well.

Short log:

• uefi-macros: Refactor GUID tests
• uefi: Remove non-protocol uses of unsafe_guid
• uefi-macros: Add unsafe_protocol macro
• uefi: Use unsafe_protocol! for all protocol impls
• uefi-macros: Drop the unsafe_guid and Protocol macros
• Drop use of unstable negative_impls feature
• Update changelog

Tracking issue for unstable features: #452

Checklist

• Sensible git history (for example, squash "typo" or "fix" commits). See the Rewriting History guide for help.
• Update the changelog (if necessary)

[phip1611]

general question: why does it need to be called unsafe, tho? Why can't the attribute be called uefi_protocol("...")? I do not see a benefit of the prefix unsafe here and it only adds confusion.

What do you think?

@nicholasbishop

[blitz]

If it's called unsafe_protocol my question would be what makes it unsafe / how do I use it safely?

[nicholasbishop]

It's prefixed with unsafe_ because passing in the wrong GUID can easily lead to unsoundness.

Here's a quick example of how bad things can happen:

The definition of EFI_DISK_IO_PROTOCOL from the spec is:

#define EFI_DISK_IO_PROTOCOL_GUID \
    {0xCE345171,0xBA0B,0x11d2,\
    {0x8e,0x4F,0x00,0xa0,0xc9,0x69,0x72,0x3b}}

typedef struct _EFI_DISK_IO_PROTOCOL {
    UINT64 Revision;
    EFI_DISK_READ ReadDisk;
    EFI_DISK_WRITE WriteDisk;
} EFI_DISK_IO_PROTOCOL;

Now consider this Rust code:

#[repr(C)]
// Bad!
#[unsafe_protocol("ce345171-ba0b-11d2-8e4f-00a0c969723b")]
pub struct MyCoolType {
    do_it: extern "efiapi" fn(),
}

let handle = bt.get_handle_for_protocol::<MyCoolType>().unwrap();
let c = bt.open_protocol_exclusive::<MyCoolType>(handle).unwrap();
(c.do_it)();

I've defined a protocol called MyCoolType with the same GUID as EFI_DISK_IO_PROTOCOL. When I call get_handle_for_protocol and open_protocol_exclusive, UEFI will think it's looking for a disk handle and opening the disk IO protocol. So those calls will succeed, and although c will be a ScopedProtocol<MyCoolType>, it will contain completely invalid data.

The docstring has a # Safety section: https://github.com/rust-osdev/uefi-rs/pull/607/files#diff-ff7f936d7319fc633630baca626659855f359b7185c91237bc9d68bd798256aeR33. There's not much too it; you have to make sure the type and GUID are correct and match up. Definitely open to improving or expanding that paragraph if you have suggestions though.

[phip1611]

Alright, thanks for the clarification.

[blitz]

Thanks!

[phip1611]

good catch! thanks for fixing this

[phip1611]

Awesome work @nicholasbishop, thanks!