3 ms·
>(5) Top-level event handlers are passed the time of the event. This is easy to fuzz. Therein lies the rub -- if your program does not have access to precise t
by drbawb 9y ago
>(5) Top-level event handlers are passed the time of the event. This is easy to fuzz.
Therein lies the rub -- if your program does not have access to precise timing information, it is by definition not operating at the full capability of the hardware which runs it. That's a hard sell to many domains.
Consider gaming. At 144Hz w/ 4K resolution you have 6ms to render a frame: that's about 1.3ns per pixel. If for a moment we imagine that it takes approximately 1 machine cycle per pixel to render a scene: that means you need to be operating at 1.3GHz just to meet the deadline for drawing to the frame buffer. -- That's before you consider memory & cache latency, or the fact that your multitasking OS is stealing resources for itself & other competing processes.
So no, one cannot just fuzz performance counters in the name of security. Any soft-realtime or hard-realtime domain is going to expect the machine to actually perform as advertised.
- tartis 9y agoYou are right: by definition real-time tasks will always be vulnerable. With regard to Urbit, it is a non-issue because there are no use cases which would warrant access to soft or hard-realtime for a networked OS. Such tasks will always happen on client-side, by virtue of network latency.