The map_to function should be unsafe

[phil-opp]

The Mapper::map_to method used to be unsafe because it is possible to break memory safety by pointing to unrelated pages to the same physical frame. In #89, we made the function safe by introducing a new UnusedPhysFrame wrapper type that is unsafe to construct.

In retrospect, I think this was a mistake because it is now possible to break memory safety using only the safe methods the Mapper trait. For example:

• Call unmap for some page and then map the page to a different UnusedPhysFrame. Now we invalidated all values that are stored in this page.
• Call map with the GLOBAL and MUTABLE flags. This crates a mapping that is not flushed from the TLB on address space switches, so that other processes can manipulate the data of the page.
  • (Technically, such a mapping alone cannot lead to undefined behavior since unsafe code is required in order to use the new mapping (e.g. for converting the page address to a reference type). However, I still think that we should treat this operation as unsafe given that it is a clear footgun.)

Given the complexity of page table mappings, I think the best solution to this problem is to treat the map_to method as a fundamentally unsafe operation. This means that we should not try to make it "less unsafe" by introducing wrapper types like UnusedPhysFrame because there will probably always be a way to still do something unsafe.

So I propose to revert #89, thereby making map_to unsafe again. Instead of completely removing the UnusedPhysFrame type, we could deprecate it to reduce breakage and make its new function return a PhysFrame, so that it can still be used with map_to. This way, we would also resolve #133 and #123.

[phil-opp]

cc @gnzlbg (originally opened #88)

[phil-opp]

WIP implementation in #135.

[phil-opp]

I think the update_flags method should be unsafe too, given that it can make existing mappings e.g. mutable or global.