linux-kernel - Re: KGDB/KDB running over internet as serial connection isn't possible

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] [day] [month] [year] [list]

Message-ID: <87msfutz6b.fsf@oracle.com>
Date: Mon, 13 Jan 2025 09:13:16 -0800
From: Stephen Brennan <stephen.s.brennan@...cle.com>
To: Muhammad Usama Anjum <Usama.Anjum@...labora.com>,
        linux-debuggers@...r.kernel.org, linux-serial@...r.kernel.org,
        kgdb-bugreport@...ts.sourceforge.net,
        LKML <linux-kernel@...r.kernel.org>
Cc: Usama.Anjum@...labora.com
Subject: Re: KGDB/KDB running over internet as serial connection isn't possible

Hi Muhammad,

Muhammad Usama Anjum <Usama.Anjum@...labora.com> writes:
> Hi,
>
> I'm new to trying KGDB/KDB. My test machine doesn't have serial port.
> I've been trying to run it over internet. I get following dmesg log:
> KGDB: Registered I/O driver kgdboc
>
> On test machine command line:
> kgdboc=kbd
> sudo sh -c "echo g > /proc/sysrq-trigger" # Launch KGDB
>
> System freezes at this point meaning the debugger got activated
> correctly. But I'm unable to connect from host side:
> gdb vmlinux
> set debug remote 1
> target remote <test_machine_ip>:2012
>
> I may be missing something trivial. Please can someone point/correct
> me how to connect correctly?

Unfortunately you are not. You've configured kgdb to run with keyboard
input (though I'm not certain where the output would go without "kms"
included in the argument). As far as I know there is no in-tree
mechanism for connecting to kgdb over the network.

To my understanding, the reason is that the kdb/kgdb internals rely on
low-level polling drivers to read and write input. Serial ports & 
PS/2 keyboards can be used in this mode (I'm not sure about USB
keyboards). This means that a single CPU can use these devices without
relying on services--like scheduling, or locks--provided & used by the
rest of the kernel, since the kernel is halted. Using a network device
for I/O would be a difficult situation, because these devices & drivers
are far more complex.

Your options are serial or keyboard. There are, however, plenty of
interesting ways where hardware can help out here. For desktop machines,
most motherboards do have a header for the serial port; you just need to
get an inexpensive face plate to expose the port. Then an external
machine could connect to that serial port, and even proxy it to the
network. For servers, most manufacturers provide some sort of management
system (they go by different names, e.g. ILOM) that allows you to
remotely manage (power on/off, view console, etc). Most of these are
accessible over IP with some authentication, and many would allow you to
connect to a serial stream over the network, and even attach something
like gdb. Laptops are a bit of a sad state, since they don't normally
have a serial port. Some have poorly-documented management hardware
which can be enabled in your BIOS settings. For instance, my Thinkpad
has "Realtek DASH", which some adventurous souls on the internet have
succeeded in getting a serial connection going[1]. However, it seems that
overall the experience is buggy and not supported.

Finally, for VMs you're in a great place, because most hypervisors
provide virtualized serial ports which you can attach to from the host.
Of course, QEMU also provides a GDB server which is frequently a more
direct route to debugging, compared to configuring serial & kgdb.  But
I'm assuming that if you're asking this question, you're not in a VM.

I'd encourage you to go through your boot logs and see which "ttyS"
devices get registered and which PCI devices (if any) they are
associated with. Then you can cross reference with "lspci" output and
identify any interesting hardware that may contain a previously-unknown
serial port. Unfortunately it's all hardware-specific, and if you don't
have anything, then you're truly out of luck.

Good luck!
Stephen

[1]: https://www.reddit.com/r/Amd/comments/ism4wg/trying_out_dash_remote_access_on_a_thinkpad_t14s/

> PS: kgdboe [2] seems like a out of tree module for help. But it doesn't
> seem to be supported anymore.
>
> Is it possible to connect from another machine over internet and debug
> the target?
>
> [1] https://docs.kernel.org/dev-tools/kgdb.html
> [2] https://github.com/sysprogs/kgdboe
> -- 
> BR,
> Muhammad Usama Anjum