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]
Date:	Wed, 30 Apr 2014 16:40:24 +0100
From:	Daniel Thompson <daniel.thompson@...aro.org>
To:	kgdb-bugreport@...ts.sourceforge.net,
	Jason Wessel <jason.wessel@...driver.com>
Cc:	patches@...aro.org, linaro-kernel@...ts.linaro.org,
	Daniel Thompson <daniel.thompson@...aro.org>,
	linux-kernel@...r.kernel.org,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mike Travis <travis@....com>,
	Dimitri Sivanich <sivanich@....com>,
	Hedi Berriche <hedi@....com>,
	John Stultz <john.stultz@...aro.org>,
	Anton Vorontsov <anton.vorontsov@...aro.org>,
	Colin Cross <ccross@...roid.com>, kernel-team@...roid.com
Subject: [PATCH 0/3] kdb: Infrastructure to display sequence files

This patchset started out as a simple patch to introduce the irqs
command from Android's FIQ debugger to kdb. However it has since grown
more powerful because allowing kdb to reuse existing kernel
infrastructure gives us extra opportunities.

Based on the comments at the top of irqdesc.h (plotting to take the
irq_desc structure private to kernel/irq) and the relative similarity
between FIQ debugger's irqs command and the contents /proc/interrupts
we start by adding a kdb feature to print seq_files. This forms the 
foundation for a new command, interrupts.

I have also been able to implement a much more generic command,
seq_file, that can display a good number of files from pseudo
filesystems. This command is very powerful although that power does mean
care must be taken to deploy it safely. It is deliberately and by
default aimed at your foot!

Note that the risk associated with the seq_file command is why I
implemented the interrupts command in C (in principle it could have been
a kdb macro). Doing it in C codifies the need for show_interrupts() to
continue using spin locks as its locking strategy.

To give an idea of what can be done with this command. The following
seq_operations structures worked correctly and report no errors:

    cpuinfo_op
    extfrag_op
    fragmentation_op
    gpiolib_seq_ops
    int_seq_ops (a.k.a. /proc/interrupts)
    pagetypeinfo_op
    unusable_op
    vmalloc_op
    zoneinfo_op

The following display the information correctly but triggered errors
(sleeping function called from invalid context) with lock debugging
enabled:

    consoles_op
    crypto_seq_ops
    diskstats_op
    partitions_op
    slabinfo_op
    vmstat_op

All tests are run on an ARM multi_v7_defconfig kernel (plus lots of
debug features) and halted using magic SysRq so that kdb has interrupt
context. Note also that some of the seq_operations structures hook into
driver supplied code that will only be called if that driver is enabled
so the test above are useful but cannot be exhaustive.

Changes since v1:
 * Added nop inline version of kdb_print_seq_file() and used it to fix
   build error when CONFIG_KGDB_KDB is not set (oops).
 * Better comment explaining why seq_file's lock member can be left
   uninitialized (its will not detect errors because we know it is
   already not allowed for seq_file ops to use it).

Daniel Thompson (3):
  kdb: Add framework to display sequence files
  proc: Provide access to /proc/interrupts from kdb
  kdb: Implement seq_file command

 fs/proc/interrupts.c        |  8 +++++++
 include/linux/kdb.h         |  5 +++++
 kernel/debug/kdb/kdb_io.c   | 53 +++++++++++++++++++++++++++++++++++++++++++++
 kernel/debug/kdb/kdb_main.c | 28 ++++++++++++++++++++++++
 4 files changed, 94 insertions(+)

-- 
1.9.0

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ