linux-kernel - Re: [PATCH] kdump: force page alignment for per-CPU crash notes.

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:	Thu, 1 Mar 2012 09:04:32 -0800
From:	Eugene Surovegin <surovegin@...gle.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	linux-kernel@...r.kernel.org,
	Eric Biederman <ebiederm@...ssion.com>,
	kexec-list <kexec@...ts.infradead.org>
Subject: Re: [PATCH] kdump: force page alignment for per-CPU crash notes.

On Thu, Mar 1, 2012 at 7:09 AM, Vivek Goyal <vgoyal@...hat.com> wrote:
> On Wed, Feb 29, 2012 at 09:21:23AM -0800, Eugene Surovegin wrote:
>> Per-CPU allocations are not guaranteed to be physically contiguous.
>> However, kdump kernel and user-space code assumes that per-CPU
>> memory, used for saving CPU registers on crash, is.
>> This can cause corrupted /proc/vmcore in some cases - the main
>> symptom being huge ELF note section.
>>
>> Force page alignment for note_buf_t to ensure that this assumption holds.
>>
>
> Hi Eugene,
>
> Where do we make assumption that crash_notes address is page aligned?

I never said that. I said that assumption was that note chunks were
physically contiguous.

[snip]

> Are you referring to the fact that note could be stored on two different
> physical pages and then kexec-tools does not know about the physical
> address of second page, hence second kernel does not know about it
> and we never read that data. That sounds like a problem.

Yes. This is exactly what happens in some cases.

> So it make sense to force the page size alignment and if notes ever
> grow beyond 1 page, we need to come up with more complex ways of
> communicating more than 1 physical address to second kernel.

Yes. Thankfully notes so far are smaller than a page.
And if they do grow larger, than kexec-tools have to be modified
anyways - currently maximum note size (1K) is hardcoded there.
If this happens, I think instead of coming up with a way to
communicate phys to virt mapping, it'd be easier just to change th way
notes are allocated in the kernel so they are phys contiguous.

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