[Feature]: config_tables: Use the zerocopy crate to Reduce Unsafe Code Blocks

[VivekYadav7272]

Feature Overview

The zerocopy crate provides safe (wrapped unsafe) memory manipulations. This offers the ability to remove a lot of unsafe blocks in Patina and rely on zerocopy to convert to and from bytes, etc.

Solution Overview

Use zerocopy in config_tables module to remove unsafe usage (I'm assuming the ones that pertains to pointer-object casting?)

Alternatives Considered

No response

Urgency

Medium

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

Maintainer feedback requested

Anything else?

It'd be nice to get more clarification on exactly the kind of unsafe usage we want prevented. To be specific, for example:

In config_tables/memory_attributes_table.rs:

match core_allocate_pool(efi::BOOT_SERVICES_DATA, size_of::<efi::MemoryAttributesTable>()) {
            Ok(empty_ptr) => {
                if let Some(empty_mat) = unsafe { (empty_ptr as *mut efi::MemoryAttributesTable).as_mut() } {
...

1. Now this sort of unsafe usage seems like a good candidate for using zerocopy. However, regardless, it will still require a cast to a byte slice, which would be an unsafe operation. That could probably also be eliminated if we have a Box-like allocation API -- is that something that's in-scope for this feature or should we let the unsafe needed to cast into a byte slice remain?
2. Also, looks like zerocopy is primarily driven by derive macros and you can't provide custom implementations for those traits. But that means we have a recursive dependency for all children members to also have it implemented. In this case specifically, pub struct MemoryAttributesTable(*mut efi::MemoryAttributesTable); can't implement it until efi::MemoryAttributesTable does, which is an external dependency. Do I duplicate the struct? Is there some other way to implement these traits that I'm missing? Sorry if that's a stupid question.

[VivekYadav7272]

Sorry btw I do not understand how to add an issue as a sub-issue. The instructions online from GitHub states that there should be a link/button below the parent issue's description but I couldn't find it.

[Javagedes]

You probably cannot do it with your permissions. I've done it for you :)

[VivekYadav7272]

cc @os-d

[os-d]

@VivekYadav7272 a few things:

• A possible outcome of this investigation will be saying that zerocopy is not the right abstraction for the config_tables
• @Javagedes do you have a suggestion for deriving the zerocopy traits? I'm not opposed to reimplementing the structs locally for now to prove this out if it works. If it does, we can take up upstreaming the changes to r-efi as needed.
• We definitely can explore other allocation options, as long as we maintain the requirements for the tables (allocated in runtime memory is the main one). The memory manager service may work here, which was not in place when this was written. This allows specifying the runtime allocator for Box::new_in:

  patina/patina_dxe_core/src/memory_manager.rs

  Line 88 in 764522e

  fn get_allocator(&self, memory_type: EfiMemoryType) -> Result<&'static dyn core::alloc::Allocator, MemoryError> {

  .

[makubacki]

In general, I think we're going to have to create wrapper types. That's what I did for r_efi::efi::Guid.