Handle parent table flags in Mapper methods #114

haraldh · 2020-01-08T13:20:23Z

Adds a new map_to_with_table_flags method with an additional parent_table_flags argument to the flags of the parent table entries.

The map_to method is kept without API changes as a convenience method. It automatically infers the parent table flags from the flags of the mapping and then calls into map_to_with_table_flags. To ensure that flags like NO_CACHE are not automatically set, which have a different meaning on higher level tables, a hardcoded mask of "safe" flags (PRESENT | WRITABLE | USER_ACCESSIBLE) is used.

To keep the recursive page table working, PRESENT and WRITABLE flags for parent entries are also added.

This also adds methods to set the flags of the level 4/3/2 page tables.

Fixes #113

This is a breaking change.

(Description updated by @phil-opp)

haraldh · 2020-01-08T13:20:41Z

This is my take on #112

haraldh · 2020-01-08T13:33:07Z

ah, doh.. should have named it p321_insert_flag_mask

haraldh · 2020-01-08T13:35:24Z

ah, doh.. should have named it p321_insert_flag_mask

done

phil-opp · 2020-01-08T14:13:04Z

Thanks for the pull request! I like your approach more than the approach in #112 because it is more predictable. However, I'm still not sure if this is the best design. Mainly, I have the following design questions:

Do we really need the additional p321_insert_flag_mask parameter? We could alternatively derive it from the flags parameter, assuming that all given flags should apply to the mapping. Or is there a use case for adding e.g. USER_ACCESSIBLE to the entry of the level 1 table but not to higher level tables?
We currently add the PRESENT and WRITABLE flags unconditionally. AFAIK they behave exactly like USER_ACCESSIBLE, so it might make sense to incorporate them into the flag_mask or derive them from the flag set.

haraldh · 2020-01-08T14:17:08Z

* Do we really need the additional `p321_insert_flag_mask` parameter? We could alternatively derive it from the `flags` parameter, assuming that all given flags should apply to the mapping. Or is there a use case for adding e.g. `USER_ACCESSIBLE` to the entry of the level 1 table but not to higher level tables?

There might be.. there are other flags, too.

* We currently add the `PRESENT` and `WRITABLE` flags unconditionally. AFAIK they behave exactly like `USER_ACCESSIBLE`, so it might make sense to incorporate them into the `flag_mask` or derive them from the `flag` set.

I don't know, we need them to build the entries, so it probably would lead to failures, if someone forgets them.

haraldh · 2020-01-08T14:19:09Z

* Do we really need the additional `p321_insert_flag_mask` parameter? We could alternatively derive it from the `flags` parameter, assuming that all given flags should apply to the mapping. Or is there a use case for adding e.g. `USER_ACCESSIBLE` to the entry of the level 1 table but not to higher level tables?

There might be.. there are other flags, too.

like NO_CACHE and WRITE_THROUGH

phil-opp · 2020-01-08T14:20:48Z

I don't know, we need them to build the entries, so it probably would lead to failures, if someone forgets them.

Good point! Note that this is only true for the recursive page table. For the mapped page table we use the separate physical mapping for modifying the page tables.

phil-opp · 2020-01-08T15:10:03Z

There might be.. there are other flags, too.

like NO_CACHE and WRITE_THROUGH

Good examples… However, I still think we can set some flags automatically, such as USER_ACCESSIBLE or WRITABLE. One might even argue that we could even always set these flags since they only have an effect if they are set on the level 1 entry too.

I think my preferred solution is currently this:

Add a new map_to_with_table_flags (placeholder name) method with an additional parent_table_flags argument to the flags of the parent table entries. This is similar to your p321_insert_flag_mask argument with the difference that it isn't a mask. This way, it's also possible to set flags on parent tables without setting them on the level 1 table entry (which might make sense for flags that have a different effect on those tables such as NO_CACHE).
Keep map_to without API changes as a convenience method. Instead of hardcoding PRESENT and WRITABLE, it automatically infers the parent table flags from the flags of the mapping and then calls into map_to_with_table_flags.
- To ensure that we don't automatically set flags like NO_CACHE, which have a different meaning on higher level tables, we use a hardcoded mask of "safe" flags (e.g. PRESENT | WRITABLE | USER_ACCESSIBLE).
- Automatically infering these parent flags makes sense to me because otherwise the entry flags have no effect. For example, it does not make sense to set USER_ACCESSIBLE only for the level 1 entry.
- To keep the recursive page table working, we need to always set the PRESENT and WRITABLE flags for parent entries (as we do today).
Add methods to get/set/update the flags of the level 4/3/2 tables.

This gives a high amount of control to the user but still keeps the API for common operations simple. What do you think?

haraldh · 2020-01-08T15:28:32Z

Sounds good to me

haraldh · 2020-01-22T08:36:49Z

I might work on this in a week.

mark-i-m · 2020-01-24T18:42:57Z

Or is there a use case for adding e.g. USER_ACCESSIBLE to the entry of the level 1 table but not to higher level tables?

Ah, I just saw this thread. I think there is a use-case for mapping a page as user-accessible but not making it user-accessible yet. For example, if I was implementing a kernel-side elf-loader, I might want to set up mappings to a bunch of user pages but not allow user-mode to access the page yet. One could then flip the bit at the higher level to allow access to all of the pages.

phil-opp · 2020-01-27T13:11:06Z

@mark-i-m

For example, if I was implementing a kernel-side elf-loader, I might want to set up mappings to a bunch of user pages but not allow user-mode to access the page yet. One could then flip the bit at the higher level to allow access to all of the pages.

Why would the user-mode program be running before it's ELF file is loaded? The table hierarchy is not used before you load it into the CR3 register, so I don't think that you need an additional "global" switch in this case.

phil-opp · 2020-01-27T13:27:27Z

In general, I think there are two approaches that are both valid:

Give the user full control of all page table bits of all levels.
Pretend to the user that higher level table "off-switchs" does not exist. Automatically set such flags (PRESENT, WRITABLE, USER_ACCESSIBLE, …) for parent tables if they're set on a level 1 table.

For me, variant 2 makes most sense as a default because that's you want most of the case. For example, if you call map_to with the WRITABLE flag, you normally want to create a writable mapping. Requiring the user to also set the flag on all higher level tables could be unexpected given that map_to already handles the creation of non-existent higher level tables.

Variant 1 also has valid use cases, e.g. setting flags that behave differently on higher level tables such as the mentioned cache flags. So I think it makes sense to support this variant too, e.g. in form of a visitor API (proposed in #121).

I think we can ergonomically cover most use-cases by defaulting to variant 2, but additionally providing advanced methods that give the user full control (variant 1).

mark-i-m · 2020-01-27T21:58:50Z

Why would the user-mode program be running before it's ELF file is loaded? The table hierarchy is not used before you load it into the CR3 register, so I don't think that you need an additional "global" switch in this case.

Imagine for example, that the kernel loads another binary/library into the same address space as another thread.

Another example would be some sort of ipc mechanism for atomically bulk-transferring data.

I agree though that variant 1 makes sense to support via something like visitors, rather than the default.

phil-opp · 2020-01-28T08:47:33Z

Thanks for the examples! I don't think that such a setup would be common, but I agree that we should still support it somehow.

mark-i-m · 2020-01-29T03:49:37Z

Yep, admittedly I tend to have weird use cases because I like to play around with non-conventional OS designs...

haraldh · 2020-02-11T10:15:21Z

Updated PR with changes mentioned in #114 (comment)

Additional methods for p[432] entries can be added later in a separate PR.

phil-opp · 2020-02-12T09:08:35Z

src/structures/paging/mapper/mapped_page_table.rs

@@ -462,13 +608,16 @@ impl<P: PhysToVirt> PageTableWalker<P> {
            if let Some(frame) = allocator.allocate_frame() {
                entry.set_frame(
                    frame.frame(),
-                    PageTableFlags::PRESENT | PageTableFlags::WRITABLE,
+                    PageTableFlags::PRESENT | PageTableFlags::WRITABLE | insert_flags,


I think we can just pass insert_flags here. Since we access the page table frame through a separate mapping, the PRESENT and WRITABLE flags should be only needed if the page is mapped with these flags (or if the user explicitly specified them in parent_table_flags).

phil-opp · 2020-02-12T09:14:11Z

Thanks a lot for the update! I only took a quick glance, but what I saw looks very good. I try to do a full review soon.

src/structures/paging/mapper/mod.rs

phil-opp · 2020-02-19T11:18:10Z

src/structures/paging/mapper/mod.rs

+    /// Create USER_ACCESSIBLE mapping and update the top hierarchy to be USER_ACCESSIBLE, too:
+    ///
+    /// ```
+    /// # use x86_64::structures::paging::{
+    /// #    Mapper, UnusedPhysFrame, Page, FrameAllocator,
+    /// #    Size4KiB, OffsetPageTable, page_table::PageTableFlags
+    /// # };
+    /// # fn test(mapper: &mut OffsetPageTable, frame_allocator: &mut impl FrameAllocator<Size4KiB>,
+    /// #         page: Page<Size4KiB>, frame: UnusedPhysFrame) {
+    ///         mapper
+    ///           .map_to_with_table_flags(
+    ///               page,
+    ///               frame,
+    ///              PageTableFlags::PRESENT
+    ///                   | PageTableFlags::WRITABLE
+    ///                   | PageTableFlags::USER_ACCESSIBLE,
+    ///              PageTableFlags::PRESENT
+    ///                   | PageTableFlags::WRITABLE
+    ///                   | PageTableFlags::USER_ACCESSIBLE,
+    ///               frame_allocator,
+    ///           )
+    ///           .unwrap()
+    ///           .flush();
+    /// # }


Maybe make this example use different flags for the entry and the parent tables to show a potential use case for this method.

phil-opp · 2020-02-19T11:21:46Z

src/structures/paging/mapper/mod.rs

+    /// Updates the flags of an existing mapping.
+    fn update_flags_p4_entry(
+        &mut self,
+        page: Page<S>,
+        flags: PageTableFlags,
+    ) -> Result<MapperFlush<S>, FlagUpdateError>;
+
+    /// Updates the flags of an existing mapping.
+    fn update_flags_p3_entry(
+        &mut self,
+        page: Page<S>,
+        flags: PageTableFlags,
+    ) -> Result<MapperFlush<S>, FlagUpdateError>;
+
+    /// Updates the flags of an existing mapping.
+    fn update_flags_p2_entry(
+        &mut self,
+        page: Page<S>,
+        flags: PageTableFlags,
+    ) -> Result<MapperFlush<S>, FlagUpdateError>;
+


I think we should name these methods "set" instead of "update" to make it more clear that they overwrite the entry flags (in contrast to ORing the flags). Also, I think I'm in favor of naming the methods set_pX_entry_flags instead of set_flags_pX_entry, but this is only personal preference.

phil-opp · 2020-02-19T11:23:40Z

src/structures/paging/mapper/offset_page_table.rs

@@ -39,6 +41,7 @@ struct PhysOffset {
 }

 impl PhysToVirt for PhysOffset {
+    #[inline]


These #[inline] attributes are fine with me, but perhaps mention their addition in the pull request/commit description.

phil-opp · 2020-02-19T11:28:15Z

src/structures/paging/mapper/recursive_page_table.rs

-                    entry.set_frame(frame.frame(), Flags::PRESENT | Flags::WRITABLE);
+                    entry.set_frame(
+                        frame.frame(),
+                        Flags::PRESENT | Flags::WRITABLE | insert_flags,


We should document that the PRESENT and WRITABLE flags are always set for higher level page table entries because the recursive page table approach requires it. Preferably we both add a code comment here and also add it to the documentation of the RecursivePageTable type so that users see it too.

phil-opp · 2020-03-02T09:11:22Z

@haraldh Friendly ping :).

haraldh · 2020-03-02T09:29:44Z

@haraldh Friendly ping :).

yeah, sorry, got distracted by other projects 😄

phil-opp · 2020-03-02T09:40:37Z

No worries! I just wanted to ensure that you saw my comments.

haraldh · 2020-04-21T18:59:09Z

error: use of deprecated item 'asm': the syntax of asm! will change soon, use llvm_asm! to avoid breakage

not part of this patch

haraldh · 2020-04-21T19:10:13Z

error: use of deprecated item 'asm': the syntax of asm! will change soon, use llvm_asm! to avoid breakage

not part of this patch

Addressed in #151

Add a new map_to_with_table_flags method with an additional parent_table_flags argument to the flags of the parent table entries. map_to is kept without API changes as a convenience method. It automatically infers the parent table flags from the flags of the mapping and then calls into map_to_with_table_flags. To ensure that flags like NO_CACHE are not automatically set, which have a different meaning on higher level tables, a hardcoded mask of "safe" flags (PRESENT | WRITABLE | USER_ACCESSIBLE) is used. To keep the recursive page table working, PRESENT and WRITABLE flags for parent entries are also added.

haraldh · 2020-04-22T17:16:42Z

rebased to latest master

haraldh · 2020-04-29T16:38:11Z

@phil-opp Friendly ping :).

phil-opp · 2020-04-30T10:38:00Z

Sorry for the delay. Unfortunately I'm a bit busy right now, but I try to review this as soon as possible.

imtsuki · 2020-05-12T16:57:33Z

Any updates on this? Sorry for bothering you guys, but I’ve encountered the same problem lately, and I desperately want this feature:)

phil-opp · 2020-05-13T11:19:23Z

Sorry for the delay! I'm taking a look at it right now.

phil-opp

Thanks a lot for the update @haraldh, it looks very good now! I only spotted one remaining issue (see the inline comment), afterwards this should be ready to merge.

src/structures/paging/mapper/mapped_page_table.rs

phil-opp

Thanks for the quick update!

phil-opp · 2020-05-14T08:30:16Z

I classified this as a breaking change because it changes the behavior of the map_to function. I also updated the PR title and the description to match the latest implementation.

phil-opp · 2020-05-14T08:31:20Z

Published as version 0.11.0.

haraldh · 2020-05-14T12:56:52Z

Thanks!

phil-opp · 2020-05-14T14:55:02Z

Thank you!

This was referenced Jan 24, 2020

Make new tables take new flags #112

Closed

Page Table Visitors #121

Open

phil-opp reviewed Feb 12, 2020

View reviewed changes

phil-opp reviewed Feb 19, 2020

View reviewed changes

phil-opp reviewed May 13, 2020

View reviewed changes

src/structures/paging/mapper/mapped_page_table.rs Outdated Show resolved Hide resolved

Mapper: Add methods to set the flags of the level 4/3/2 page tables

4a72bc6

haraldh requested a review from phil-opp May 13, 2020 17:08

phil-opp approved these changes May 14, 2020

View reviewed changes

phil-opp merged commit eaf91c2 into rust-osdev:master May 14, 2020

phil-opp changed the title ~~Add p23_insert_flag_mask argument to mapper.map_to()~~ Handle parent table flags in Mapper methods May 14, 2020

phil-opp added a commit that referenced this pull request May 14, 2020

Update changelog for #114

6d8164e

haraldh deleted the p23_insert_flags branch May 14, 2020 14:58

Handle parent table flags in Mapper methods #114

Handle parent table flags in Mapper methods #114

Conversation

haraldh commented Jan 8, 2020 • edited by phil-opp Loading

haraldh commented Jan 8, 2020

haraldh commented Jan 8, 2020

haraldh commented Jan 8, 2020

phil-opp commented Jan 8, 2020

haraldh commented Jan 8, 2020

haraldh commented Jan 8, 2020

phil-opp commented Jan 8, 2020

phil-opp commented Jan 8, 2020

haraldh commented Jan 8, 2020

haraldh commented Jan 22, 2020

mark-i-m commented Jan 24, 2020

phil-opp commented Jan 27, 2020

phil-opp commented Jan 27, 2020

mark-i-m commented Jan 27, 2020

phil-opp commented Jan 28, 2020

mark-i-m commented Jan 29, 2020

haraldh commented Feb 11, 2020

phil-opp Feb 12, 2020

Choose a reason for hiding this comment

phil-opp commented Feb 12, 2020

phil-opp Feb 19, 2020

Choose a reason for hiding this comment

phil-opp Feb 19, 2020

Choose a reason for hiding this comment

phil-opp Feb 19, 2020

Choose a reason for hiding this comment

phil-opp Feb 19, 2020

Choose a reason for hiding this comment

phil-opp commented Mar 2, 2020

haraldh commented Mar 2, 2020

phil-opp commented Mar 2, 2020

haraldh commented Apr 21, 2020

haraldh commented Apr 21, 2020

haraldh commented Apr 22, 2020

haraldh commented Apr 29, 2020

phil-opp commented Apr 30, 2020

imtsuki commented May 12, 2020

phil-opp commented May 13, 2020

phil-opp left a comment

Choose a reason for hiding this comment

phil-opp left a comment

Choose a reason for hiding this comment

phil-opp commented May 14, 2020

phil-opp commented May 14, 2020

haraldh commented May 14, 2020

phil-opp commented May 14, 2020

haraldh commented Jan 8, 2020 •

edited by phil-opp

Loading