Source info
Issue type
Environment
Description
From commit ddab9e5, VM::TIMER is reported to deadlock on a Lenovo ideapad miix 510-12isk. The function doesn't return, and the CPU core count seems to be enough.
After researching all CPUs that normally ship with this manufacturer, Intel Pentium 4405U, Core i3-6006U / i3-6100U, Core i5-6200U, and Core i7-6500U were detected for that Lenovo model. Heuristically determined that the CPU must be an i3. Even if those CPUs do not have multiple cores, the random entropy algorithm may be choosing unexpected core indexes when pinning the counter and trigger threads of the timing anomalies check.
Specifically, the get_trigger_mask lambda that attempts to randomize where the routine will run to make impossible for the hypervisor to predict where the counter is, even after intercepting instructions like RDRAND/RDSEED (reason why VMAware doesn't use random_device standard library calls) is pending to be reviewed in June 15, after I'm free.
Some arm64 machines are freezing from ddab9e5 and up too when calling VMAware routines on a single thread. However, VM::TIMER doesn't run in ARM machines, and we've confirmed that the runtime safe-guard that detects whether the x86 assembly code is being translated to ARM on Windows is working and not letting the detection run in such environments. This suggests that the issue:
- Might be happening in a completely different, unknown point of the code.
- Might be happening on multiple points of the code, including (or not) VM::TIMER.
The issue ends in an unrecoverable freeze, without possibility of analyzing debug logs.
In June 15 after I get some time, VMAware will be re-ran in such CPUs to determine the cause of the deadlock via stack-tracing, and re-analyze all the relevant code.
CLI output (if possible)
Source info
Issue type
Environment
Description
From commit
ddab9e5,VM::TIMERis reported to deadlock on a Lenovo ideapad miix 510-12isk. The function doesn't return, and the CPU core count seems to be enough.After researching all CPUs that normally ship with this manufacturer, Intel Pentium 4405U, Core i3-6006U / i3-6100U, Core i5-6200U, and Core i7-6500U were detected for that Lenovo model. Heuristically determined that the CPU must be an i3. Even if those CPUs do not have multiple cores, the random entropy algorithm may be choosing unexpected core indexes when pinning the counter and trigger threads of the timing anomalies check.
Specifically, the
get_trigger_masklambda that attempts to randomize where the routine will run to make impossible for the hypervisor to predict where the counter is, even after intercepting instructions likeRDRAND/RDSEED(reason why VMAware doesn't use random_device standard library calls) is pending to be reviewed in June 15, after I'm free.Some arm64 machines are freezing from
ddab9e5and up too when calling VMAware routines on a single thread. However,VM::TIMERdoesn't run in ARM machines, and we've confirmed that the runtime safe-guard that detects whether the x86 assembly code is being translated to ARM on Windows is working and not letting the detection run in such environments. This suggests that the issue:The issue ends in an unrecoverable freeze, without possibility of analyzing debug logs.
In June 15 after I get some time, VMAware will be re-ran in such CPUs to determine the cause of the deadlock via stack-tracing, and re-analyze all the relevant code.
CLI output (if possible)