linux-kernel - Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

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:	Tue, 03 Feb 2009 12:45:18 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Simon Horman <horms@...ge.net.au>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Neil Horman <nhorman@...driver.com>,
	Eric Biederman <ebiederm@...sion.com>,
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	hbabu@...ibm.com, Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

Simon Horman <horms@...ge.net.au> writes:

>> I also did all the below.  Please check it.  (Is anyone else reading all
>> this stuff??)
>
> These look fine to me. Unfortunately they don't apply to the version
> of Linus' tree that I have checked out and I'm away from net access
> at this moment (though obviously not by the time this message reaches you).
> I'll update my tree and check once I'm back online.
>
> Eric Biederman usually watches kexec stuff. I'm pretty sure he
> is on the kexec mailing list, but I've CCed him anyway.

Thanks.

The question at head seems to be does it make sense to always
export log_buf and log_end in the VMCOREINFO section of the
core file we generate.

The premise of VMCOREINFO is that it gives crash or other
analysis tools enough information to pair a core dump with
a vmlinux and decipher the page table layout.  In general
things that are tricky to infer from just the core dump,
and the vmlinux.

Do log_buf and log_end fall in that category?

They are certainly important enough and they are symbols that
are tricky to find. That said I think we should also have 
this information exported so that we can get at
it with kgdb, jtag debuggers, and other weird debugging tools.
Do we have that already?  It doesn't look like it.  That
may be an argument for a different interface.

That aside we aren't currently exporting log_buf_len, so I don't
think this code works actually works.

Neil can you add a comment in kernel/printk.c of the algorithm
necessary for external tools to decode the ring buffer?

We need the comment because people working on kernel/printk.c
need to know what is happening and without having to review lots
of user space code, and we need the comment to verify that we
are exporting the right things.

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