Reply To: Security

The Novel (= “dirty”) bit means you have a write-back protection cache, nifty!

I presume clean (non-Novel) revoked PLB entries are marked invalid but kept in the PLB until there is need to access the memory protection structure, at which point one OS trap can do a batch of work.

There was a question asked at the end of the talk (video@1:22:10) that Ivan apparently didn’t understand and thus gave a non-answer to.

A pass operation grants permission “to whoever I’m next calling” (video@1:01:29). However, if an interrupt (involuntary function call) occurs between the pass and the call, does the pass apply to it? If not, how does the Mill keep the grant pending across that function call, and all the nested (voluntary) function calls, to have it take effect on return? Even if it creates a PLB entry immediately (with turf=* thread=myself), there are still the mechanics of cleaning it up again.

Is this more spiller magic?

Another question is whether a region can have both execute and portal permission. Presumably the All has both so both can be granted, but how does the Mill handle a call to such a region?

Also, if portal calls almost always require special permission-passing code, why not make it a distinct opcode? As you say, effectively all applications will jump through a library wrapper anyway.

One thing that people might have missed in the Q&A is that a callback must be a portal, but it can either be globally visible or may be granted/passwd for the duration of one function call so that unexpected callbacks are impossible.

(This case of callbacks might be the answer to the earlier question. A callback usually refers only to the original caller’s buffers, so does not need to grant additional permissions, so perhaps C compatibility wins here.)