This problem come from the order in which 2 important operations are scheduled to read a sensitive piece of information which is a password:
- lock exclusive access to the keyboard
- read characters typed at the keyboard
Apparently these 2 operations are scheduled the wrong way round:
- read characters typed at the keyboard
- lock exclusive access to the keyboard
The part of the kernel in charge of reading the keyboard is waken up before locking the keyboard. This is fully understandable when you want to be able to wake the system on any keyboard entry. But in such a case,
a mechanism should clearly indicate to the user when the keyboard
is safe to type a serious password and not wake up noise.
This wrong scheduling was apparently a small problem and not noticed by many users since the 2 operations are anyway scheduled in a small window of events (it's a question of one or 2 seconds here).
This small window of time to schedule these 2 operations is larger if
you are just waking up your disk, or if your disk isn't fast enough
for your fingers, or if you have too fast fingers.
This is the reason why some people thought that this problem was created by hard disk drive (HDD) and suppressed by solid state drive (SSD). In fact the problem isn't suppressed by an SSD, it is just more difficult to exhibit. You should consider this as a fundamental bug
in password reading which is hidden when using a fast enough disk or slow motion fingers.