This work is a result of inspiration from Fansmitter attack (ref: https://arxiv.org/ftp/arxiv/papers/1606/1606.05915.pdf), where researchers were able to leak data over noise of software-controlled cooling fan, by controlling its speed from software. Tempsmitter aims to control fans even when the fan is not software-controlled. It is powered by two similar stressing loops (written using MMX instructions) to iterate over a matrix of moderate size, specifically laid out to ensure cache misses at almost every subsequent access (L1-L3), which results in load-cache miss-flush cycle at each access, forcing the CPU to do much more work, resulting in noticeable increase in dice temperature.
Box: HP Pavilion DV6 3043TX, which probably has a software-readable fan sensor, which Linux does not seem to talk to.
1. Fan speeds up when CPU heats up.
2. CPU heats up when load increases
3. Different components of CPU have different thermal emission properties.
1. heavy load for long time will increase CPU temp, but will degrade over-all system responsiveness, which will be a dead give-away signal.
2. CPU is smart enough to optimize for lowest thermal emission while maintaining the performance, and that too agressively (and folks, thats why your CPU has a stable thermal pattern despite of load fluctuation)
Plan: Maximize the heat emission while minimizing the stress time.
How: Hunted for instructions which have much higher thermal emission relative to other instructions. Hunted for internal CPU events which lead to higher thermal emission (these internal events are minimized by CPU). Laid out an evil plan to outsmart this internal optimization (it happens at microcode level). Mixed them with high thermal emission instructions, and KABOOM!
I have used two similar stressing loops to iterate over a matrix of moderate size, specifically laid out to ensure cache misses at almost every subsequent access (not only L1, but L2 and L3 as well ), which results in load-cache miss-flush cycle at each access, forcing the CPU to do much more work (RAM access is costlier than cache access). Plus all those weird instructions are really good in producing heat if you know how to use them
Hours wasted: 6 (yesterday) + 4 (today)
Test results: temperature increases by 4-6C (slight variation at each run)
Duration of test run: ~2s (again, slight variation at each run. Generally falls in 1.9-2,1s range, possibly due to RAM access scheduling)
Extra info: All other CPU hogging and non-essential processes were killed.