By: Doug S (foo.delete@this.bar.bar), September 17, 2021 11:35 am
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 17, 2021 8:59 am wrote:
> The most complicated case I see does come from the "three instructions" thing: making
> sure it's doing everything properly if they done individually. And "done individually"
> happens for the "restart for exceptions or interrupts" case, even if the instructions
> are right next to each other in the right order in the instruction stream.
I'm curious to see the full information on these instructions when available, in particular what the limit of num_bytes is and whether/how overlapping ranges are supported.
There is clearly going to be a need to handle multiple in progress mem* instructions, as the scheduler could task switch a process in the middle of a instruction, the next process starts another that gets interrupted and so forth. And that's even beyond having one of these instructions executing in the kernel and an interrupt is raised and the interrupt handler starts another. That means the state information for in flight instructions will have to be saved on the stack - opening another line for potential stack based attacks.
I'm also curious if the ISA will address mem* instructions on multiple cores with overlapping range. I know, that's a "doctor it hurts when I do that" scenario which can also happen if you use ordinary library mem* functions, so who cares right? Imposing some sort of ISA limit on that by e.g. range checking against currently in flight mem* instructions might free up some longer term future implementations to get clever with external blocks or logic built into cache that might otherwise be impossible. A cleaner ISA that prevents more than one mem* instruction operating on the same range of memory at the same time might not be a bad idea IMHO, even if it required some extra housekeeping to enforce. The "three instructions" thing would seem to complicate that, though.
> The most complicated case I see does come from the "three instructions" thing: making
> sure it's doing everything properly if they done individually. And "done individually"
> happens for the "restart for exceptions or interrupts" case, even if the instructions
> are right next to each other in the right order in the instruction stream.
I'm curious to see the full information on these instructions when available, in particular what the limit of num_bytes is and whether/how overlapping ranges are supported.
There is clearly going to be a need to handle multiple in progress mem* instructions, as the scheduler could task switch a process in the middle of a instruction, the next process starts another that gets interrupted and so forth. And that's even beyond having one of these instructions executing in the kernel and an interrupt is raised and the interrupt handler starts another. That means the state information for in flight instructions will have to be saved on the stack - opening another line for potential stack based attacks.
I'm also curious if the ISA will address mem* instructions on multiple cores with overlapping range. I know, that's a "doctor it hurts when I do that" scenario which can also happen if you use ordinary library mem* functions, so who cares right? Imposing some sort of ISA limit on that by e.g. range checking against currently in flight mem* instructions might free up some longer term future implementations to get clever with external blocks or logic built into cache that might otherwise be impossible. A cleaner ISA that prevents more than one mem* instruction operating on the same range of memory at the same time might not be a bad idea IMHO, even if it required some extra housekeeping to enforce. The "three instructions" thing would seem to complicate that, though.