exception/interrupt handlers shouldn't access this_cpu()

[Freax13]

Exception/interrupt handlers (or more commonly signal handlers in non-kernel code) are considered separate threads within the abstract machine. One consequence of this is that they shouldn't access this_cpu() because this_cpu() is not Sync. There's currently nothing to prevent this from happening.

Code accessing !Sync data can usually assume that its accesses are never interrupted, but that's not the case if an exception handler preempts the code and accesses the data as well. The soundness of the Cell and RefCell types hinges on being able to do uninterrupted accesses. Consider the following example: Some code wants to write an enum with data into a Cell in its PerCpu structure. Rust enums have a tag that decides which variant is active. If the code trying to write the enum is interrupted halfway through (e.g. by the hypervisor injecting #HV), it may have only written the tag, but not all the other data contained in the enum. Unlike with lock structures, there's nothing that prevents the exception handler from accessing the data as well. When the exception handler reads the Cell it may see the new enum tag but with some of the old enum data. If the tag doesn't match the data, that's obviously very bad.

[p4zuu]

It seems to me that we can hardly remove all Cell, RefCell and OnceCell from PerCpu to have it Sync (I'm not even sure if doing this is sufficient to have this_cpu() Sync).
It also seems to me that we can hardly handle #PF without accessing the page tables, so I guess here we either need to move the page tables into a Sync version (eg. moving the page tables without using RefCell into PerCpuShared, right?), or to add a lock around the page tables ref, but it seems this is a bad idea

[Freax13]

Sorry, I think the title is a bit misleading: What I was trying to say was the "with the current PerCpu implementation, exception/interrupt handlers must not access this_cpu()". I don't know of a good solution to this, but it might involve making PerCpu safe to access from multiple threads so that exception/interrupt handles may access this_cpu().
I don't know of a good way to solve this, we might have to get rid of the *Cell types, we might have to introduce locks, maybe we should split up PerCpu into several levels of access from different contexts, I don't know.

[00xc]

For RefCells we could perhaps introduce a wrapper type that disables interrupts while the data is borrowed.

There would still be the possibility of restoring interrupts manually while the borrow is alive but it would at least be better than what we have now.

[Freax13]

For RefCells we could perhaps introduce a wrapper type that disables interrupts while the data is borrowed.

This won't work for exception handlers though. The host can pretty much always trigger a #VC (e.g. by unmapping memory) even with restricted injection.

There would still be the possibility of restoring interrupts manually while the borrow is alive but it would at least be better than what we have now.

We already support nested disabling/enabling of interrupts.