linux-kernel - Re: [PATCH 0/3] Early use of boot service memory

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]

Message-ID: <52867309.4040406@zytor.com>
Date:	Fri, 15 Nov 2013 11:16:25 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...nel.org>,
	jerry.hoemann@...com, Pekka Enberg <penberg@...nel.org>,
	Rob Landley <rob@...dley.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	x86 maintainers <x86@...nel.org>,
	Matt Fleming <matt.fleming@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"list@...ederm.org:DOCUMENTATION" <linux-doc@...r.kernel.org>,
	"list@...ederm.org:MEMORY MANAGEMENT" <linux-mm@...ck.org>,
	linux-efi@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] Early use of boot service memory

On 11/15/2013 10:46 AM, H. Peter Anvin wrote:
> On 11/15/2013 10:30 AM, Vivek Goyal wrote:
>>
>> I agree taking assistance of hypervisor should be useful.
>>
>> One reason we use kdump for VM too because it makes life simple. There
>> is no difference in how we configure, start and manage crash dumps
>> in baremetal or inside VM. And in practice have not heard of lot of
>> failures of kdump in VM environment.
>>
>> So while reliability remains a theoritical concern, in practice it
>> has not been a real concern and that's one reason I think we have
>> not seen a major push for alternative method in VM environment.
>>
> 
> Another reason, again, is that it doesn't sit on all that memory.
> 

This led me to a potentially interesting idea.  If we can tell the
hypervisor about which memory blocks belong to kdump, we can still use
kdump in its current form with only a few hypervisor calls thrown in.

One set of calls would mark memory ranges as belonging to kdump.  This
would (a) make them protected, and (b) tell the hypervisor that these
memory ranges will not be accessed and don't need to occupy physical RAM.

On a crash, we would them execute another hypercall to reanimate the
kdump areas.  Since this is a once-in-a-lifetime (literally) event, this
can be arbitrarily slow.

This would only require a small number of hypercalls inserted into
already existing code paths, and provide most of the benefit of
hypervisor-assisted crash dumping.

	-hpa

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