在用户态将 Syscall 转换为 IPC Call

[yfblock]

目标

在用户态使用动态或者静态的方式将 SysCall 指令转换为 IPC。

思路

在 aarch64 上没有 riscv64 jalr 这类方便的指令，只能使用 bl 指令进行跳转，不过 bl 指令有 26 bit 表示地址偏移，也就是 aarch64 的 bl 跳转范围为 +/- 128M。所以理论可行的做法是对 text 段进行扩充，然后将 text 段中插入 syscall 转 ipc 的函数，然后使用工具（目前计划是 lief）将 syscall 指令 (svc #0) 转换为 跳转指令(bl 指令) 跳转到我们新插入的地址，理论上来说，代码段的长度很难超过 +/- 128M。

[yfblock]

下面给出一个简单的示意图

最后一列显示了另外一种情况，就是将 ipc_trans 放在一个固定的地方，然后进行二进制重写将 svc 只转换为 bl 指令即可（不可超过 128M 的范围。）

[yfblock]

在使用 lief 的过程中出现问题，一旦扩大 .text 段的大小，再运行会出现 sigsegv sig_code=2 的错误信号。可能还需要其他代码进行配合修改某些地址。

代码如下

#!/usr/bin/env python
#
# 文档在 https://lief.re/doc/latest/api/binary_abstraction/python.html
#
# Function Examples:
#
#   # Assemble and patch the provided assembly code at the specified address.
#   bin.assemble(0x12000440, """
#   xor rax, rbx;
#   mov rcx, rax;
#   """)
#
#   # Disassemble code starting a the given virtual address.
#   insts = binary.disassemble(0xacde, 100);
#   for inst in insts:
#       print(inst)
#
#   # Disassemble code for the given symbol name
#   insts = binary.disassemble("__libc_start_main");
#   for inst in insts:
#       print(inst)
#
#   # Disassemble code from the provided bytes
#   raw = bytes(binary.get_section(".text").content)
#   insts = binary.disassemble_from_bytes(raw);
#   for inst in insts:
#       print(inst)
#
#   # exported_functions
# 其中还提供了一个 tutorial: https://lief.re/doc/stable/tutorials/

# 需要注意的事情是 一些功能只有在 extend version 中提供
# 比如：Disassembler，Assembler
# https://lief.re/doc/latest/extended/intro.html
import lief
import os
import stat

INST_SVC_BYTES = b'\x01\x00\x00\xd4'  # Aarch64 Instruction "svc #0"

elf = lief.ELF.parse("a.elf")
target_file = "new.elf"

# 遍历所有的段信息
# for section in elf.sections:
#     print(section.name, section.virtual_address)

text_section = elf.get_section(".text")
elf.extend(text_section, 0x4)
# 查找 svc #0 指令所在地，并尝试重写
for pos in text_section.search_all(INST_SVC_BYTES):
    print("find svc #0: " + hex(text_section.virtual_address + pos))
    print("finded text function position", hex(elf.offset_to_virtual_address(pos + text_section.offset)))
    # elf.patch_address(text_section.virtual_address + pos, [0x11, 0x22, 0x33, 0x44])

# for func in elf.exported_functions:
#     print("find function: " + func.name)

# elf.remove_section("")

elf.write(target_file)

# 为目标文件添加可执行权限
st = os.stat(target_file)
os.chmod(target_file, st.st_mode | stat.S_IEXEC)

[yfblock]

在 #4 中采用了新的设计，使用 0xdeadbeef 来替换 svc #0 指令，当执行到这个指令的时候 sel4/rel4 内核就会首先捕捉到这个问题，然后调用 fault_ep 发送一个 fault IPC 到 kernel-thread，然后 kernel-thread 通过读取执行的这一个指令是什么来判断是否是 syscall。如果是 syscall 就接着读取上下文进行处理，处理结束后恢复程序运行状态即可。

[yfblock]

基于 Hello World 来构建一个简单的测例，来实验简单的方案。目前 https://rel4team.github.io/zh/docs/monolithic/funcs/func2ipc/ 已经提出了一些问题，但是需要实践来检验，在此基础上构建一个 hello world 来实践 IPC 到函数的转换比较合适。大概使用一周的时间

[yfblock]

本周遇到了一些问题，比起一套自动化的工具来说，是否符合一定规则的编程方式更加重要。下面给出一些参考信息：

• https://doc.rust-lang.org/book/ch12-03-improving-error-handling-and-modularity.html#splitting-code-into-a-library-crate
• https://github.com/subhojit777/minigrep/blob/master/src/lib.rs

Questions:

1. 修改了调用逻辑，让本来不需要 Mutex 的都需要全局加锁

   1. 原来的调用逻辑就是可以在一个线程中实现所有的逻辑，可以通过传递调用流的方式来传递信息。但是目前

   #![no_std]
   #![no_main]
   
   extern crate alloc;
   
   use alloc::collections::vec_deque::VecDeque;
   use arm_pl011::pl011::Pl011Uart;
   use common::{
       consts::DEFAULT_SERVE_EP,
       ipc::ipc_saver::IpcSaver,
       services::{
           root::{register_irq, register_notify},
           uart::UartEvent,
       },
       slot::alloc_slot,
   };
   use config::{SERIAL_DEVICE_IRQ, VIRTIO_MMIO_VIRT_ADDR};
   use sel4::{MessageInfoBuilder, init_thread, with_ipc_buffer_mut};
   
   sel4_runtime::entry_point!(main);
   
   fn main() -> ! {
       common::init_log!(log::LevelFilter::Error);
       common::init_recv_slot();
   
       log::info!("Booting...");
   
       // 向 root-task 申请一个中断
       let irq_handler = alloc_slot().cap();
       register_irq(SERIAL_DEVICE_IRQ, irq_handler.into()).expect("can't register interrupt handler");
   
       // 向 root-task 申请一个通知
       let ntfn = alloc_slot().cap();
       register_notify(ntfn.into(), usize::MAX).expect("Can't register interrupt handler");
   
       // 设置 pl011 地址空间
       let mut pl011 = Pl011Uart::new(VIRTIO_MMIO_VIRT_ADDR as _);
       pl011.init();
       pl011.ack_interrupts();
   
       irq_handler.irq_handler_set_notification(ntfn).unwrap();
       irq_handler.irq_handler_ack().unwrap();
   
       let rev_msg = MessageInfoBuilder::default();
       let mut buffer = VecDeque::new();
       let mut ipc_saver = IpcSaver::new();
       init_thread::slot::TCB
           .cap()
           .tcb_bind_notification(ntfn)
           .unwrap();
   
       loop {
           let (msg, badge) = DEFAULT_SERVE_EP.recv(());
           if badge == u64::MAX {
               let char = pl011.getchar().unwrap();
               pl011.ack_interrupts();
               irq_handler.irq_handler_ack().unwrap();
   
               if ipc_saver.queue_len() > 0 {
                   with_ipc_buffer_mut(|ib| {
                       ib.msg_bytes_mut()[0] = char;
                       ipc_saver.reply_one(rev_msg.length(1).build()).unwrap();
                   });
               } else {
                   buffer.push_back(char);
               }
           } else {
               let msg_label = match UartEvent::try_from(msg.label()) {
                   Ok(label) => label,
                   Err(_) => continue,
               };
               match msg_label {
                   UartEvent::Ping => {
                       with_ipc_buffer_mut(|ib| {
                           sel4::reply(ib, rev_msg.build());
                       });
                   }
                   UartEvent::GetChar => match buffer.pop_front() {
                       Some(c) => with_ipc_buffer_mut(|ib| {
                           ib.msg_bytes_mut()[0] = c;
                           sel4::reply(ib, rev_msg.length(1).build());
                       }),
                       None => ipc_saver.save_caller().unwrap(),
                   },
               }
           }
       }
   }

   // 现在的代码
   static BUFFER: Mutex<VecDeque<u8>> = Mutex::new(VecDeque::new());
   
   pub struct UartBridgeImpl;
   #[fn_impl]
   impl UartBridge for UartBridgeImpl {
       fn getchar() -> Option<u8> {
           BUFFER.lock().pop_front()
       }
       fn putchar(c: u8) {
           todo!()
       }
       fn ping() {}
   }

2. 函数模型的问题。
   同样是上述的代码，原来时我们的程序在一个调用流之上，可能存在接收消息，然后并没有完全符合的资源，然后保存调用者信息，等待结束后，然后返回消息。这个在单纯的普通函数中很难完成这个事情，因为无法手动的修改调用流，改造之后我们的程序会将原来的程序转发到这个地方，更符合异步模型。但是会产生额外的问题。如果想使用 IPC 的方式来传输，就不能将 Future 作为返回类型。使用 类似 arceos 中 crate_interface 中的方式，但是很 impl Future 在 extern “Rust” 中使用，所以在整体的使用中如何考虑阻塞的问题。

3. 可能存在 Endpoint 和 Notification 复用一个通道的情况，这时候该如何分发。

4. 有些代码会存在需要保存调用者的情况，比如 uart 的 getchar，然后再有数据之后再分发，这个时候这个函数模型不太对劲。
   可能可以用 Future 解决这个问题。但是 Impl 不能存在于 extern "Rust" 中。GG
   所以不能使用 IPC 共享函数

5. 利用 rust 的 trait object 来实现 IPC 的分发

6. 还有原有任务的资源怎么进行管理？动态管理是否可行？

   1. 原来是给多个程序分别分配了一些信息，包含了会用到的设备地址等信息，如果采用这种方式，程序编译的时候需要合并，需要的资源也需要合并。
   2. 也许可以在运行时进行资源的分配，但是在编译期间进行资源分配的目的就是确定性和安全性，如果动态进行分配，无法确定是否保证安全，也许可以在编译期间为每一个模块添加一个 token，在运行时用 token 换资源，但是安全性未知，实现起来的难度未知。

这部分可能需要手动填写，目前来看，是否真的有一套机制可以让 IPC 和函数调用更加自然的转换。

rust lib and main in same crate

一些介绍，如何让一个程序同时作为 Lib 和 main 存在。https://doc.rust-lang.org/book/ch12-03-improving-error-handling-and-modularity.html#splitting-code-into-a-library-crate

主要的修改就是需要在一个 crate 里同时创建一个 lib.rs 和 main.rs ，lib.rs 中只编写需要使用的代码不包含主要的执行逻辑。在 main.rs 中创建主要的执行逻辑。这样就不需要考虑 main.rs 和 lib.rs 互相转换的问题了，但是对于编程来说就会有一定的限制。不过好处就是代码更加容易得复用。

这种做法的目标是，让自己既可以作为程序去运行，也可以作为库向外部提供信息，和我们的想法不谋而合。

目前 rel4_kernel 中也采用了这种设计，但是使用的方式不是很一样，目的不一样。rCore-tutorial 中也使用了这个设计。

越来越觉得这些事情是一个系统工程的问题，而不是一个单独的插件可以完成的。