linux-kernel - Re: [PATCH] KDB: Fix usability issues relating to the 'enter' key.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F4A3A8D.7030700@windriver.com>
Date:	Sun, 26 Feb 2012 07:58:37 -0600
From:	Jason Wessel <jason.wessel@...driver.com>
To:	Andrei Warkentin <andreiw@...are.com>
CC:	<kgdb-bugreport@...ts.sourceforge.net>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KDB: Fix usability issues relating to the 'enter' key.

On 02/26/2012 07:10 AM, Jason Wessel wrote:
> On 02/17/2012 05:52 PM, Andrei Warkentin wrote:
>> This fixes the following problems:
>> 1) Typematic-repeat of 'enter' gives warning message.
>> 2) Use of 'keypad enter' gives warning message.
>> 3) Lag on the order of seconds between "break" and "make" when
>>    expecting the enter "break" code. Seen under virtualized
>>    environments such as VMware ESX.
>>
>> Explanations:
>> 1) Holding down 'enter' will not set a repeating sequence
>>    of 0x1c(make)-0x9c(make), but a repeating sequence
>>    of make codes, followed by one break code when the key
>>    is released. Thus, it's wrong to expect the break code
>>    after seeing the 'enter' make code.
>> 2) Keypad enter generates different make/break, namely
>>    0xe0 0x1c and 0xe0 0x9c. The 'generic' logic handles
>>    the 0xe0 escape already, but the special 'enter' logic
>>    always expects '0x9c' and not '0xe0 0x9c', so you get
>>    a warning message, again.
>> 3) When expecting the 'enter' break code, the code polls
>>    the status register in a tight loop, like so -
>>    >  while ((inb(KBD_STATUS_REG) & KBD_STAT_OBF) == 0);
>>
>>    However, it really should do something like -
>>    >  while ((inb(KBD_STATUS_REG) & KBD_STAT_OBF) == 0)
>>    >     cpu_relax(); /* pause */
>>
>>    Basically, it's a common optimization to have a fast
>>    path for accessing often accessed and slow changing I/O
>>    in a virtualized environment. The tight spinning in KDB
>>    seems to run against the logic by ESX keyboard virtualization
>>    code to detect when the fast path or the slow path should
>>    be used to satisfy the keyboard status read, leading to
>>    multi-second timeouts before the 'real' status comes through.
>>    Without knowing ESX internals, it's hard to say if this is
>>    an ESX bug or not, but letting the VM be explicitely descheduled
>>    seems to resolve the problem. I've seen something similar with
>>    shared MMIO buffers with VMs on Hyper-V.
>>
>>    Anyway, given (3), (2) and (1), we might as well blow away the
>>    entire special casing for 'enter'. The break codes will already
>>    be handled correctly, and we get rid of the bugs with repeat
>>    enters and keypad enter key. And of course, there is no
>>    need to AND with 0x7f when checking for 'enter', because we'll
>>    never ever get to this code with a break code (checked for much
>>    earlier).
>>
>>    I tried to figure out the history behind the 'enter' key special
>>    casing code, and it seems to have come from whatever the original
>>    KDB patch was. Perhaps someone can chime in.
>>
> 


Andrei, if you agree with the attached patch, I'll put it in the merge queue.  If you find problems we can go another iteration. :-)

Cheers,
Jason.

View attachment "0001-From-Andrei-Warkentin-andreiw-vmware.com.patch" of type "text/x-diff" (3278 bytes)