> You might want to go lookup the meltdown/spectre SharedArrayBuffer proof of concept attack.
That still requires a piece shared state, like I said. That vulnerability results from running untrusted code in the same process as trusted code. The whole point of a process is to establish a protection boundary around potentially unsafe code, hence why I keep mentioning processes, and this is the whole point of microkernels and IPC. Within a process, all bets are off.
My earlier point was that a shared clock between processes amplifies this problem so that timing attacks cross even the process protection boundary. So when you started talking about job scheduling, I assumed the following:
1. we're in a microkernel context, where we partition trusted and untrusted code using processes.
2. the job scheduling system you mentioned either
a) is a process running its own code that it trusts and so in-process timing attacks don't matter, but timing attacks with another process might matter and so you don't want to grant a clock capability if it isn't needed, or
b) is a process scheduling system ala cron, where the job scheduler is trusted but the jobs being run are untrusted, and so they run in separate processes.
In case (a), the ticket system seems sufficient if you don't want/need to grant access to the clock consistent with least privilege, and for (b) the job scheduler may or may not have the clock installed or not, doesn't really matter, since job scheduling happens via IPC so there's no shared read, ie. delay(100 ticks, self) sends the relative delay which the cron-like scheduler adds to its own clock.
Hopefully that clarifies my context, and you can then describe what assumptions your scenario violates.
> My earlier point was that a shared clock between processes amplifies this problem so that timing attacks cross even the process protection boundary. So when you started talking about job scheduling, I assumed the following
It doesn't, though. Your point fundamentally misunderstands the nature of a timing attack for ex-filtration. It doesn't cross process boundaries. It doesn't use any process crossing state of any kind for timing. It simply times how long it takes to access cache lines, which is perfectly local & isolated. It does not involve time correletation or association across processes of any kind. It doesn't care about real time at all. All it needs is a stopwatch that can measure the difference between 0.5-2ns & 80-120ns.
The meltdown attack via SharedArrayBuffer did not use any untrusted code in the same process. It read kernel memory at will using 2 threads and an atomic int.
That still requires a piece shared state, like I said. That vulnerability results from running untrusted code in the same process as trusted code. The whole point of a process is to establish a protection boundary around potentially unsafe code, hence why I keep mentioning processes, and this is the whole point of microkernels and IPC. Within a process, all bets are off.
My earlier point was that a shared clock between processes amplifies this problem so that timing attacks cross even the process protection boundary. So when you started talking about job scheduling, I assumed the following:
1. we're in a microkernel context, where we partition trusted and untrusted code using processes.
2. the job scheduling system you mentioned either
a) is a process running its own code that it trusts and so in-process timing attacks don't matter, but timing attacks with another process might matter and so you don't want to grant a clock capability if it isn't needed, or
b) is a process scheduling system ala cron, where the job scheduler is trusted but the jobs being run are untrusted, and so they run in separate processes.
In case (a), the ticket system seems sufficient if you don't want/need to grant access to the clock consistent with least privilege, and for (b) the job scheduler may or may not have the clock installed or not, doesn't really matter, since job scheduling happens via IPC so there's no shared read, ie. delay(100 ticks, self) sends the relative delay which the cron-like scheduler adds to its own clock.
Hopefully that clarifies my context, and you can then describe what assumptions your scenario violates.