Undefined behavior by creating reference to level 4 page table?

[SamZhang3]

First: Thank you for the excellent blog!

I just have some slight doubts about a part of the Paging Implementation post.

Specifically, kernel_main creates, using the active_level_4_table function, a mutable reference to the current level 4 table, by reading the physical address from the CR3 register and translating it to a virtual address, and keeps the reference around for the rest of kernel_main. The issue is that the CPU may modify the "accessed" and "dirty" flags in the page table's entries anytime, including concurrently with accesses to the page table. As a result, the data pointed to by a mutable reference is modified by something not derived from that reference, while that reference exists. As far as I understand, this is undefined behavior (I'm not an expert on this kind of things though, so I may be wrong).

I am pretty sure that I am just needlessly worrying/being excessively pedantic here, especially given that the accessed and dirty flags are never used for anything, at least in Blog OS. Also, as far as I can see, I don't think there is any easy way to avoid this issue. Is this a real problem?

[phil-opp]

Thanks a lot for reporting this! I agree with you that this use of &'static mut references could be problematic.

Unfortunately, the exact rules around unsafe code are not defined yet (there is the opsem-team for that), so I'm not sure about the details. The safe approach would probably be to use raw pointers instead of &mut references and we should probably use volatile operations too (because the hardware might change the flags at any time). I'll look into this when I have time.

In the meantime, I also opened an issue for the x86_64 crate, which currently encourages the creation of &mut PageTable references to the active page tables: rust-osdev/x86_64#416