linux-kernel - Re: [RFC PATCH 0/4 V2] introduce: livedump

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: <4FBF6918.9010702@hitachi.com>
Date:	Fri, 25 May 2012 20:12:24 +0900
From:	YOSHIDA Masanori <masanori.yoshida.tv@...achi.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Vivek Goyal <vgoyal@...hat.com>, linux-kernel@...r.kernel.org,
	Andy Lutomirski <luto@....edu>, Ingo Molnar <mingo@...e.hu>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Kees Cook <keescook@...omium.org>,
	Kevin Hilman <khilman@...com>,
	Prarit Bhargava <prarit@...hat.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Tejun Heo <tj@...nel.org>,
	yrl.pp-manager.tt@...achi.com
Subject: Re: [RFC PATCH 0/4 V2] introduce: livedump

Hi, Peter

Thank you for quick reply.

Yes, I know that PF in NMI handling is dangerous, and so livedump doesn't
protect such pages that can be updated during NMI handling.
Such pages are listed in [3/4] as "sensitive pages".

Currently, I regard the following pages as sensitive pages in [3/4].
- Kernel/Exception/Interrupt stacks
- Page table structure
- All task_struct
- ".data" section of kernel
- All per_cpu areas

However, I can't assure these pages are enough to avoid PF in NMI handling.
Do you have any idea to enumerate sensitive pages correctly?

Thank you.


On 2012/05/25 18:25, Peter Zijlstra wrote:
> On Fri, 2012-05-25 at 18:12 +0900, YOSHIDA Masanori wrote:
>> Live Dump is based on Copy-on-write technique. Basically processing is
>> performed in the following order.
>> (1) Suspends processing of all CPUs.
>> (2) Makes pages (which you want to dump) read-only.
>> (3) Resumes all CPUs
>> (4) On page fault, dumps a page including a fault address.
>
> Suppose a PF is in progress when all this happens, you mark all RO, then
> an NMI happens, from the NMI context we'll generate another PF to update
> a vmap area, this will again PF because you mucked about and marked
> things RO.
>
> You're now at 3 PFs, which is instant reboot.
>
> I don't think this is going to work.
>

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