linux-kernel - Re: net/kgdb: Taking another crack at implementing kgdboe

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 for Android: free password hash cracker in your pocket

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

Message-ID: <f44ef944-d1c6-376d-cfef-920f780bea7d@windriver.com>
Date:   Fri, 21 Feb 2020 21:16:43 -0600
From:   Jason Wessel <jason.wessel@...driver.com>
To:     Jordan Hand <jorhand@...ux.microsoft.com>,
        <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
CC:     <daniel.thompson@...aro.org>, <dianders@...omium.org>
Subject: Re: net/kgdb: Taking another crack at implementing kgdboe

On 2/21/20 6:33 PM, Jordan Hand wrote:
> Hey folks,
> 
> I have been scouring patches from around 2005-2008 related to kgdboe
> (kgdb over ethernet) and I am interested in taking a shot at getting it
> into the mainline kernel.
> 
> I found an implementation from Tom Rini in 2005[1] and an out of tree
> implementation[2].
> 
> So I have a couple questions before I dive in:
> 
> 1. Is anyone actively working on this? From lkml archives it appears no
> but I thought I'd ask.

I don't believe there is anyone working on this. 

> 2. Does anyone have an objection to this feature? From my reading it
> seems that the reason it was never merged was due to reliability issues
> but I just want to double check that people don't see some larger issue.

I think some of the biggest problems here are what it takes to stop
the ethernet hardware, use it for a bit, and then put it back
together.  The changes to the network stack and the ethernet drivers
were fairly invasive to get it work with any degree of reliability.

Long ago, in 2008 I had proposed perhaps using a second dedicated
ethernet queue, vs trying to put the driver back into a good state
after you have stopped the core kernel execution.  I still view this
to be the best approach to getting a reliable debugger if you are
facing some kind of situation that you must use something that is "in
kernel".  You really need a way that you can process inputs and
outputs safely without using any other function in the kernel except
for what is provided in the debug core.  This would also give us a
more reliable way to have a "netconsole" for dumping ftrace data and
oops logs. 

> 
> I don't have 100% of my time to devote to this so it will likely take me
> a while but this is something I would like to see in the upstream kernel
> so I thought I'd give it a try.
> 
> [1] https://lkml.org/lkml/2005/7/29/321

I definitely have a version from 2014 that is newer than what was
posted there, which relies on the netpoll controller part of which has
been removed from the mainline kernel.  I also have a pile of USB
patches which enable the use of KDB with a USB keyboard.  Quite a few
years have passed by since I tried to submit them to the USB
maintainers. It is a similar kind of situation as the ethernet.  It is
hard to talk to the drivers in a polling state and put them back to a
working state when you resume.  Stopping is the easy part.

> [2] https://github.com/sysprogs/kgdboe
> 

This is a much newer project than the implementation from Tom or myself.   

Cheers,
Jason.