linux-kernel - Re: [PATCH 0/3] kgdb: fixes and ARCH=arm support

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]

Date:	Thu, 21 Feb 2008 08:36:08 -0600
From:	Jason Wessel <jason.wessel@...driver.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] kgdb: fixes and ARCH=arm support

Ingo Molnar wrote:
> 
> I think we should also try to do some self-tests, so that when one boots 
> a bzImage with the self-tests activated it can be said that all the 
> basic functionality works. Simulated via some loopback method, from 
> within the kernel - not via a real serial line - but it should have the 
> capability to do real single-stepping and inject real hw breakpoints and 
> test that they work. What do you think?
> 
> 	Ingo

I am in agreement that the kgdb core and arch level support can be
unit tested via a kgdb I/O module designed specifically for exercising
kgdb as if it were the debugger talking to the kernel.  It is more a
matter of taking the time to write the test cases as well as some code
to simulate the debugger.  All the API pieces needed to create a 
testing kgdb I/O module are already in the kgdb core.

There are several classes of tests that could be run with the possibility
to construct a kgdb test I/O module that performs them all:
- Early init tests
   * Pass in a kernel start argument to invoke the test
   * test kgdbwait
   * test SW/HW breakpoints
   * test single step
   * test several known bad memory read locations
   * test SMP concurrency

- Late init test
   * Same as the first test, but done at the late init point
     with a different kernel start argument
   * test NMI watch dog + recover

- Run time dynamic configuration
   * Connect the I/O module at run time by using an echo > /sys/...
   * Test the same pieces as the late init test

- Perhaps even allow the kgdb I/O test module to be built as 
  a kernel module. The only problem with this is that there will be some
  more exports required. It is marginally more challenging in that
  you have to look up the symbol address info dynamically as well vs
  allowing the linker to resolve the references when it is built as a
  built-in.  Also as a built-in you can call all the kgdb en-code
  de-code gdb serial packet logic directly with no exports.

Of course it is always best to start small and not all of the tests
are needed in a 1st pass.  It is something that is already on the KGDB
todo list, and if there is someone out there that would like to start
writing this code right now, please contact me.  Or, eventually the
this task will bubble to the top of the stack. :-)

Ultimately this type of I/O testing module will be important for
helping to validate future archs that have kgdb support added, as well
as a place to add other edge test cases if there are future defects
fixed in kgdb for which you can create a test case.

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/