By: nksingh (None.delete@this.none.non), September 17, 2021 12:23 pm
Room: Moderated Discussions
Doug S (foo.delete@this.bar.bar) on September 17, 2021 11:35 am wrote:
> 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.
From the exclamation points in the mnemonic description, I assume the state needed for resume is stored by updating the src, dst, and cnt registers. So it just looks like a normal instruction to the os with state in the existing registers.
> 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.
From the exclamation points in the mnemonic description, I assume the state needed for resume is stored by updating the src, dst, and cnt registers. So it just looks like a normal instruction to the os with state in the existing registers.