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: <CAD=FV=V+EJf--J29YM7XuHbNO0fFzLgOYBhBA5VsnnMTG-LArQ@mail.gmail.com>
Date: Fri, 1 Nov 2024 08:29:39 -0700
From: Doug Anderson <dianders@...omium.org>
To: Nir Lichtman <nir@...htman.org>
Cc: jason.wessel@...driver.com, daniel.thompson@...aro.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kdb: Fix incorrect naming of history arrow keys in code

Hi,

On Thu, Oct 31, 2024 at 5:26 PM Nir Lichtman <nir@...htman.org> wrote:
>
> On Thu, Oct 31, 2024 at 04:06:03PM -0700, Doug Anderson wrote:
> > >
> > > kdb doesn't react to ctrl p and n, and following the code flow with GDB
> > > reveals that these values map to the up and down arrows.
> >
> > Really? kdb reacts to "ctrl-P" and "ctrl-N" for me. It also reacts to
> > "ctrl-F" and "ctrl-B".
> >
>
> Interesting, how do you run kdb? I use the kgdboc=kbd kernel boot param.
> I haven't checked with serial as the console since I work with the keyboard,
> but if serial does go through this using ctrl+p/n then the code in the
> current state is misleading since the keys change depending on the I/O method.

Wow, I've never used the keyboard method since I've never run kdb on a
machine that supports it. :-P


> Evidence in the code for usage of arrow keys in the case of keyboard can
> be seen by examining kdb_read in kernel/debug/kdb/kdb_io.c, in the /* Down */
> and /* Up */ cases the values 14 and 16 can be seen.

Right. Essentially the logic is converting the Up and Down sequences
to the characters Ctrl-P and Ctrl-N. ...so by the time we get to
handle_ctrl_cmd() the characters really are Ctrl commands, not arrow
commands. Thus handle_ctrl_cmd() is correct as is.


> Do you suggest to keep as is or to work on a patch with a more generic name that
> would fit both?

IMO it's a bug that the keyboard code isn't properly reporting Ctrl-N
and Ctrl-P. Does it handle other Ctrl characters? Ctrl-A should go to
the start of the line and Ctrl-E the end. Maybe you can track down why
this isn't happening?

-Doug

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ