Turn CONFIG_STRICT_DEVMEM in sysctl dev.mem.restricted
by Bernhard Walle
This patch series turns CONFIG_STRICT_DEVMEM in a sysctl
dev.mem.restricted.
While the restricted /dev/mem is useful in most scenarios, it is not
when doing live debugging. The crash utility
(http://people.redhat.com/~anderson) needs access to /dev/mem.
As distributor (at least for "enterprise" distributions) you need both:
The protection in the general case and the ability to do live debugging.
The patch doesn't make the kernel more insecure: Without SELinux or
AppArmor, it has always been possible to circumvent that /dev/mem
restriction. With it, you can also prevent the (super) user from doing
"sysctl dev.mem.restricted=1".
This patch series differs in two ways from the original submission:
- The patch that removes CONFIG_STRICT_DEVMEM has been added.
- The binary sysctl is removed, now it's only a /proc/sys sysctl.
While the original submission of CONFIG_STRICT_DEVMEM mentions that the
option has been in RHEL and Fedora for 4 years without problems, that's
only a half of the story. The truth is that at least RHEL has /dev/crash
exactly to circumvent that /dev/mem restriction. Don't tell me that this
is better than having that sysctl entry. ;-)
The patch has been tested on i386. There should be no difference to
x86_64.
Signed-off-by: Bernhard Walle <bwalle(a)suse.de>
16 years
Crash Setup
by ADITYA KRISHNAN
Hi,
I am new to crash utility. I want to run crash ( crash 4.0-2.18.1) on dual-core
AMD Opteron (x86_64) cluster. The cluster nodes are running xen 3.0 the
proc/version gives the following output : 2.6.16.13-xen
i am running xen 3.0 which has been installed on fc5.
I guess the kernel was not built with debugging info on
Running crash gives the following output:
crash 4.0-2.18.1
Copyright (C) 2002, 2003, 2004, 2005, 2006 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005 Fujitsu Limited
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
WARNING: cannot read linux_banner string
crash: /boot/vmlinux-syms-2.6.16.13-xen and /dev/mem do not match!
I read up on the previous threads that this is because /dev/mem returns all
zereos.
I think I need something like a patch for installing the /dev/crash module.
I am new to this so can anyone help me out with a detailed procedure of what
needs to be done.
Thank You.
Aditya Krishnan
16 years
Re: [Crash-utility] crash: cannot determine vcpu_guest_context.ctrlreg offset
by Dave Anderson
----- "Bob Clark" <bclark(a)marathontechnologies.com> wrote:
> I'm trying to analyze a xen linux guest crashdump and I'm receiving
> the
> following error:
>
> crash: cannot determine vcpu_guest_context.ctrlreg offset
>
> The crashdump was produced from Xen 5.0.0 by setting the
> actions-after-crash parameter to coredump_and_restart, and then
> crashing
> the guest VM. I'm using crash version 4.0-7.4.
>
> Thanks in advance for any help.
> Bob
My experience is with Red Hat's Xen 3.1.x-era xendumps only, but
the crash utility needs the cr3 register value from the guest's
vcpu_guest_context structure, which contains the starting mfn
value (the page directory value) required for translating
pseudo-physical memory to machine memory (p2m), and from that
value, the location in the dumpfile.
In any case, the cr3 has always been found in the vcpu_guest_context
structure's ctrlreg[] array. Take the vmlinux file that you are
using, and do this:
# gdb vmlinux
GNU gdb Red Hat Linux (6.5-37.el5rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/i686/nosegneg/libthread_db.so.1".
(gdb) ptype struct vcpu_guest_context
type = struct vcpu_guest_context {
struct {
char x[512];
} fpu_ctxt;
long unsigned int flags;
struct cpu_user_regs user_regs;
struct trap_info trap_ctxt[256];
long unsigned int ldt_base;
long unsigned int ldt_ents;
long unsigned int gdt_frames[16];
long unsigned int gdt_ents;
long unsigned int kernel_ss;
long unsigned int kernel_sp;
long unsigned int ctrlreg[8]; <--- this is what's required by crash
long unsigned int debugreg[8];
long unsigned int event_callback_cs;
long unsigned int event_callback_eip;
long unsigned int failsafe_callback_cs;
long unsigned int failsafe_callback_eip;
long unsigned int vm_assist;
}
(gdb)
Has xen 5.0.0 changed the structure's declaration?
Dave
16 years
crash: cannot determine vcpu_guest_context.ctrlreg offset
by Bob Clark
I'm trying to analyze a xen linux guest crashdump and I'm receiving the
following error:
crash: cannot determine vcpu_guest_context.ctrlreg offset
The crashdump was produced from Xen 5.0.0 by setting the
actions-after-crash parameter to coredump_and_restart, and then crashing
the guest VM. I'm using crash version 4.0-7.4.
Thanks in advance for any help.
Bob
16 years
CONFIG_STRICT_DEVMEM
by Cliff Wickman
Running on an x86_64 box, with a 2.6.28 kernel, lcrash fails
on a failed read of /dev/mem.
It is a read to initialize virtop. It fails with EPERM.
The problem is
CONFIG_STRICT_DEVMEM=y
(could this be a problem to crash as well?)
-Cliff
16 years
Re: [Crash-utility] [PATCH] Fix module size and num_symtab for 2.6.27
by Dave Anderson
----- "Bernhard Walle" <bwalle(a)suse.de> wrote:
> This patch implements the kernel change
>
> commit 2f0f2a334bc38b61a9afca951185cd3844ee709d
> Author: Denys Vlasenko <vda.linux(a)googlemail.com>
> Date: Tue Jul 22 19:24:27 2008 -0500
>
> module: turn longs into ints for module sizes
>
> This shrinks module.o and each *.ko file.
>
> And finally, structure members which hold length of module
> code (four such members there) and count of symbols
> are converted from longs to ints.
>
> We cannot possibly have a module where 32 bits won't
> be enough to hold such counts.
>
> For one, module loading checks module size for sanity
> before loading, so such insanely big module will fail
> that test first.
>
> Signed-off-by: Denys Vlasenko <vda.linux(a)googlemail.com>
> Signed-off-by: Rusty Russell <rusty(a)rustcorp.com.au>
>
> in crash. Without the patch I was not able to open a core dump created
> with
> 2.6.27 on POWER. I think it's mostly a problem on big endian
> architectures,
> because on little endian you can have luck and read zeros which don't
> change
> the value of a number while on big endian you cannot have luck. ;-)
>
>
> Signed-off-by: Bernhard Walle <bwalle(a)suse.de>
I first thought these might be better served using MEMBER_SIZE(),
but I see that it's most definitely a 2.6.27 (and later) change,
and it's highly unlikely they'll ever go back to the larger sizes.
Queued for the next release.
Thanks,
Dave
16 years
[PATCH] Fix module size and num_symtab for 2.6.27
by Bernhard Walle
This patch implements the kernel change
commit 2f0f2a334bc38b61a9afca951185cd3844ee709d
Author: Denys Vlasenko <vda.linux(a)googlemail.com>
Date: Tue Jul 22 19:24:27 2008 -0500
module: turn longs into ints for module sizes
This shrinks module.o and each *.ko file.
And finally, structure members which hold length of module
code (four such members there) and count of symbols
are converted from longs to ints.
We cannot possibly have a module where 32 bits won't
be enough to hold such counts.
For one, module loading checks module size for sanity
before loading, so such insanely big module will fail
that test first.
Signed-off-by: Denys Vlasenko <vda.linux(a)googlemail.com>
Signed-off-by: Rusty Russell <rusty(a)rustcorp.com.au>
in crash. Without the patch I was not able to open a core dump created with
2.6.27 on POWER. I think it's mostly a problem on big endian architectures,
because on little endian you can have luck and read zeros which don't change
the value of a number while on big endian you cannot have luck. ;-)
Signed-off-by: Bernhard Walle <bwalle(a)suse.de>
16 years
