Hacker News new | past | comments | ask | show | jobs | submit login

A concurrent GC running on a single processor machine is still going to pause. There are still other ways to get into situations where an attacker can cause the gc to kick in in ways where you can get information -- find a few CPU-heavy functions that nudge the GC to kick in when and where you want it. Harder, but even a background GC can wiggle into the foreground.



Even a statically compiled program run on a single core machine will pause because of the OS scheduler. Assuming we have a multicore cpu then one core can be dedicated to the GC.


Good you're thinking out the box. That pause might not be a problem, though. The pauses that are a problem when the malicious app can control the timing with an external observer seeing those manipulations. The OS scheduler is usually independent of secret processing. It's just doing it's own thing causing pauses that don't tell you about the secret itself. Theoretically, there could be an esoteric attack in some situation where an OS scheduler would accidentally leak somethinh or be activated to leak something. Not popping into mind righg now, though.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: