Proposal to Adopt aarch64-cpu Crate for Our aarch64 Development

[bitboom]

I propose that we transition our aarch64 development to use the aarch64-cpu crate for the following reasons:

Background

• Controlling hardware registers in Rust requires calling assembly code, which inherently uses unsafe code.
• The aarch64-cpu crate, which is the most widely used crate for creating OS or Hypervisor on Aarch64 targets with approximately 300,000 downloads, defines and uses registers via the tock-register-interface. (Ref. crate.io)

Key Differences

• The primary difference between the aarch64-cpu crate and our current approach is that the aarch64-cpu crate does not exposeunsafe by default for setting and getting registers.

• This decision was made after extensive discussions (tock-registers: Make Register Access Unsafe tock/tock#2593), RFC: Unsafe WriteOnly, ReadWrite, and ReadOnly (?) variants for tock-register-interface? tock/tock#3244) and concluded that:

  1. If the hardware specification explicitly states that usage can lead to undefined behavior, developers should explicitly mark functions as unsafe.
  2. For memory-direct operations such as MMU settings, developers should explicitly mark functions as unsafe.

• Additional Features:

  • The aarch64-cpu crate allows us to define register permissions such as Read Only and Read Write, which we currently do not have.

Proposed Actions

1. Transition to aarch64-cpu:

   • Modify our current approach to use the aarch64-cpu crate, implying that register settings do not use unsafe by default.
   • This change means reusing a well-defined and actively used crate, improving our codebase's maintainability.

2. Explicit unsafe Usage:

   • Based on our current unsafe code level, explicitly mark functions related to setup_el2 and MMU settings as unsafe and provide detailed safety documentation for them.

By adopting these changes, we can leverage a more robust and community-supported approach to hardware register management while maintaining the safety and clarity of our code.

Reference Links

• Documentation for aarch64-cpu crate

Please share your thoughts and any concerns you might have regarding this proposal.

[zpzigi754]

Good to bring up using aarch64-cpu crate and the good discusion link!

It seems that using aarch64-cpu would not imply avoiding unsafe in register settings, as the exposed functions would use unsafe inside them. Thus, it would be more about how to encapsulate unsafe blocks in aarch64's assembly usages.

I am totally fine with using aarch64-cpu which is used by many including Amazon. Since it uses both apache and mit license, we might need to clarify using these licenses. Also, it might be missing some armv9a features which might need to be supported internally (in the forked one) or remotely.

[bitboom]

Thanks for your opinion!

Since it uses both apache and mit license, we might need to clarify using these licenses

According to the specified terms, we can use the Apache License that fits our needs. We do not need to additionally include the MIT notice.

Licensed under either of

- Apache License, Version 2.0 
- MIT License

at your option.

[jinbpark]

I like the idea of reusing aarch64-cpu rather than creating a similar one.

Regarding the strategy of exposing unsafe in aarch64-cpu--

If the hardware specification explicitly states that usage can lead to undefined behavior, developers should explicitly mark functions as unsafe.

This is very neat, I like this principle. One thing that is interesting to add might be--
restricting the read/write of registers based on a given context.

For example, in either InstructionAbort or DataAbort, HPFAR_EL2 and FAR_EL2 are only allowed to access.
I don't know how effective it is regarding register access.

However, it might be effective for restricting access to specific asm instructions (e.g., tlb flush).
For example, tlb_flush_instruction is only allowed to be called within appropriate RMI/RSI calls. (e.g., RMI/RSI calls that affect RTT tables)

For memory-direct operations such as MMU settings, developers should explicitly mark functions as unsafe.

It totally makes sense as well. We need some ways to ensure the logic of MMU settings is implemented correctly. (e.g., tlb_flush should be called at the right time) This seems like a special case of "safety" tag as it involves assembly instructions.
I'm not sure whether we need to care about this stuff. But, I think it's worth doing.

[bitboom]

Applied. #331