[PATCH] x86, kaslr: export offset in VMCOREINFO ELF notes
by Kees Cook
Include kASLR offset in VMCOREINFO ELF notes to assist in debugging.
Signed-off-by: Eugene Surovegin <surovegin(a)google.com>
Signed-off-by: Kees Cook <keescook(a)chromium.org>
---
arch/x86/kernel/machine_kexec_64.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 4eabc160696f..679cef0791cd 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -279,5 +279,7 @@ void arch_crash_save_vmcoreinfo(void)
VMCOREINFO_SYMBOL(node_data);
VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
#endif
+ vmcoreinfo_append_str("KERNELOFFSET=%lx\n",
+ (unsigned long)&_text - __START_KERNEL);
}
--
1.7.9.5
--
Kees Cook
Chrome OS Security
12 years, 1 month
Retrieve pointer value for scripting
by Patrick Agrain
Hello,
We wish to call 'crash' with a script file to automate some basic
command and output the result on a text file.
This works perfectly for basic commands such as bt, log, mod and so on,
especially when no input data is required.
We try now to dump the kernel stack through a 'rd <@> <size>'.
My problem is to "extract" this <@> and to "input" it in this 'rd' command.
For the moment, I'm able to get the task_struct * with following command :
ps | grep '>' | awk '{ print $5 };'
From that, the pointer of the thread_info would be available through
(task_struct *)->stack.
But how to get all these together to finally ouptut a valid 'rd' command ?
Meaby another way to get this kernel stack dump would exist ?
Any help would be appreciate.
Regards,
Patrick Agrain
12 years, 1 month
[PATCH 1/1 V4] crash: initial note of excluded page structures
by cpw
Version 4
- Makes the warning:
WARNING: The vmemmap page structures that are associated with the
memory pages excluded by the "makedumpfile -d <level>"
option have been excluded from this dump.
The administrator has used "makedumpfile -e".
This will cause failures in any command that accesses a page
structure of a page that is not included in the dump. This
is particularly likely when using several options of the
kmem command.
Version 3
- Changes the warning to be more complete:
WARNING: All unused vmemmap page structures are excluded from this dump.
This will cause failures of the kmem command if it attempts to
walk any list of free pages (with options such as -f -F -i -s
and -S) or interpret an address with kmem <address>, and
incorrect output from kmem -p.
Version 2
- Moves the warning to this point:
...
This GDB was configured as "x86_64-unknown-linux-gnu"...
WARNING: All unused vmemmap page structures are excluded from this dump.
This will cause failures of the kmem command if it attempts to
walk any list of free pages (with options -f -F -i -s and -S).
SYSTEM MAP: /boot/System.map-2.6.32-cpw
...
- Drop patch 2, which added warnings to individual kmem options.
- Feel free to change the wording of the warning.
And this patch is contingent upon the acceptance of a change to the
makedumpfile command.
http://marc.info/?l=kexec&m=138853299130125&w=2
If makedumpfile excludes unused page structures it will flag that
fact in the dump header.
(There are about 3.67 million pages full of page structures for
every tera byte of system memory. The great bulk of those
page structures are not needed.)
Their exclusion is a makedumpfile option.
Crash will display a note during initialization if such structures
have been excluded. Crash commands that walk page freelists, for
example, will fail. So the note will help the user understand why.
Signed-off-by: Cliff Wickman <cpw(a)sgi.com>
---
defs.h | 1 +
diskdump.c | 3 +++
diskdump.h | 1 +
main.c | 11 +++++++++++
4 files changed, 16 insertions(+)
Index: crash-7.0.4/diskdump.c
===================================================================
--- crash-7.0.4.orig/diskdump.c
+++ crash-7.0.4/diskdump.c
@@ -749,6 +749,9 @@ restart:
dd->valid_pages[i]++;
}
+ if (header->status & DUMP_DH_EXCLUDED_VMEMMAP)
+ pc->flags2 |= VMEXCLUDED;
+
return TRUE;
err:
Index: crash-7.0.4/diskdump.h
===================================================================
--- crash-7.0.4.orig/diskdump.h
+++ crash-7.0.4/diskdump.h
@@ -84,6 +84,7 @@ struct kdump_sub_header {
#define DUMP_DH_COMPRESSED_ZLIB 0x1 /* page is compressed with zlib */
#define DUMP_DH_COMPRESSED_LZO 0x2 /* page is compressed with lzo */
#define DUMP_DH_COMPRESSED_SNAPPY 0x4 /* page is compressed with snappy */
+#define DUMP_DH_EXCLUDED_VMEMMAP 0x8 /* unused vmemmap pages are excluded */
/* descriptor of each page for vmcore */
typedef struct page_desc {
Index: crash-7.0.4/defs.h
===================================================================
--- crash-7.0.4.orig/defs.h
+++ crash-7.0.4/defs.h
@@ -505,6 +505,7 @@ struct program_context {
#define VMCOREINFO (0x400ULL)
#define ALLOW_FP (0x800ULL)
#define REM_PAUSED_F (0x1000ULL)
+#define VMEXCLUDED (0x2000ULL)
#define REMOTE_PAUSED() (pc->flags2 & REM_PAUSED_F)
char *cleanup;
char *namelist_orig;
Index: crash-7.0.4/main.c
===================================================================
--- crash-7.0.4.orig/main.c
+++ crash-7.0.4/main.c
@@ -662,6 +662,17 @@ main_loop(void)
} else
SIGACTION(SIGINT, restart, &pc->sigaction, NULL);
+ if (pc->flags2 & VMEXCLUDED)
+ fprintf(fp,
+ "WARNING: The vmemmap page structures that are associated with the\n"
+ " memory pages excluded by the \"makedumpfile -d <level>\"\n"
+ " option have been excluded from this dump.\n"
+ " The administrator has used \"makedumpfile -e\".\n"
+ " This will cause failures in any command that accesses a page\n"
+ " structure of a page that is not included in the dump. This\n"
+ " is particularly likely when using several options of the\n"
+ " kmem command.\n\n");
+
/*
* Display system statistics and current context.
*/
12 years, 2 months
[PATCH 0/2] crash: warnings of excluded page structures
by cpw
I have proposed a patch to makedumpfile to (optionally) exclude from
a dump the page structures representing excluded pages.
The idea being that a system with terabytes of system memory has
millions of pages of page structures. And most of them are unneeded.
That patch thread begins here:
http://marc.info/?l=kexec&m=138853299130125&w=2
Dave [Anderson] raised these crash-related issues;
Although I'm sure you tested this, I find it amazing that
only the "kmem -[fF]" option is the only command option
that is affected?
If I'm not mistaken, this would be the first time that legitimate
kernel data would be excluded from the dump, and the user would
have no obvious way of knowing that it had been done, correct?
If it were encoded in the in the header somewhere, at least a
warning message could be printed during crash initialization.
...
Right, but look at all of the other page struct offsets in addition to
page.lru that are used. The page.flags usage comes to mind, and for
example, what would "kmem -p" display for the missing pages?
Or "kmem <address>"? And would "kmem -i" display invalid data?
I'm just speculating off the top of my head, but the page structure is
such a fundamental data structure with several of its fields being used,
just enter "help -o page_" to see all of its potential member usages.
So I am submitting two patches for your consideration, should the patch
to exclude unused vmemmap pages be taken into makedumpfile.
- [PATCH 1/2] crash: initial note of excluded page structures
This one makes crash startup look like this:
This program has absolutely no warranty. Enter "help warranty" for details.
NOTE: Unused vmemmap page structures are excluded from this dump.
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
- [PATCH 1/2] crash: kmem warnings for excluded page structures
This patch modifies kmem options -f, -F, -s addr, -S addr, and -i.
Those are the only options that I could detect looking for excluded pages.
This patch applies on top of the first, and adds some warnings to the
output of these kmem options. For example:
crash> kmem -f
Note: kmem -f may fail because unused page structures are excluded from this dump.
NODE
0
ZONE NAME SIZE FREE MEM_MAP START_PADDR START_MAPNR
0 DMA 4095 3934 ffffea0000000038 1000 0
AREA SIZE FREE_AREA_STRUCT BLOCKS PAGES
0 4k ffff880000013068 2 2
...
crash> kmem -i
PAGES TOTAL PERCENTAGE
TOTAL MEM 128008147 488.3 GB ----
FREE 127599276 486.8 GB 99% of TOTAL MEM
USED 408871 1.6 GB 0% of TOTAL MEM
SHARED 11049 43.2 MB 0% of TOTAL MEM
BUFFERS 5722 22.4 MB 0% of TOTAL MEM
CACHED 44638 174.4 MB 0% of TOTAL MEM
SLAB 62139 242.7 MB 0% of TOTAL MEM
TOTAL SWAP 4893032 18.7 GB ----
SWAP USED 0 0 0% of TOTAL SWAP
SWAP FREE 4893032 18.7 GB 100% of TOTAL SWAP
Note: 1970727 free pages not found (excluded); results are incomplete.
Unused page structures are excluded from this dump.
-Cliff Wickman
cpw(a)sgi.com
12 years, 2 months
[PATCH 0/4] Enable use of crash on xen 4.4.0 vmcore
by Don Slutz
With the addition on PVH code to xen 4.4, domain.is_hvm no longer
exists. This prevents crash from using a xen 4.4.0 vmcore.
Patch 1 "fixes" this.
Patch 2 is a minor fix in that outputing the offset in hex for
domain_domain_flags is different.
Patch 3 is a bug fix to get all "domain_flags" set, not just the 1st
one found.
Patch 4 is a quick way to add domain.guest_type support.
Don Slutz (4):
Make domian.is_hvm optional
xen: Fix offset output to be decimal.
xen: set all domain_flags, not just the 1st.
Add basic domain.guest_type support.
xen_hyper.c | 32 ++++++++++++++++++++++++--------
xen_hyper_defs.h | 1 +
xen_hyper_dump_tables.c | 4 +++-
3 files changed, 28 insertions(+), 9 deletions(-)
--
1.8.4
12 years, 2 months
issue: runq -g
by vinayak menon
Hi Dave,
I was getting the following error upon executing "runq -g".
runq: invalid structure member offset: cfs_rq_throttled
FILE: task.c LINE: 7615 FUNCTION: print_group_header_fair()
[./crash] error trace: 80e98b0 => 80e9815 => 80e577f => 8143bde
TASK_GROUP: dac06c80 CFS_RQ: dac06080 <apps>runq: input string
too large: "000000000808ec50" (16 vs 8)
"cfs_bandwidth" is available in task_group irrespective of whether
CONFIG_CFS_BANDWIDTH is enabled or not (but empty). But "throttled" is
available in cfs_rq only if config is enabled. The following patch
fixes this.
diff --git a/task.c b/task.c
index dc0310a..a119c60 100755
--- a/task.c
+++ b/task.c
@@ -7611,7 +7611,7 @@ print_group_header_fair(int depth, ulong cfs_rq, void *t)
if (tgi->name)
fprintf(fp, " <%s>", tgi->name);
- if (VALID_MEMBER(task_group_cfs_bandwidth)) {
+ if (VALID_MEMBER(cfs_rq_throttled)) {
readmem(cfs_rq + OFFSET(cfs_rq_throttled), KVADDR,
&throttled, sizeof(int), "cfs_rq throttled",
FAULT_ON_ERROR);
Thanks,
Vinayak
12 years, 2 months
