From: "H. Peter Anvin" <hpa@zytor.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "hawk@comx.dk" <hawk@comx.dk>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"drosenberg@vsecurity.com" <drosenberg@vsecurity.com>,
"dle-develop@lists.sourceforge.net"
<dle-develop@lists.sourceforge.net>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"rdunlap@xenotime.net" <rdunlap@xenotime.net>,
Andi Kleen <andi@firstfloor.org>,
Seiji Aguchi <seiji.aguchi@hds.com>,
"akpm@linuxfoundation.org" <akpm@linuxfoundation.org>,
"ext-andriy.shevchenko@nokia.com"
<ext-andriy.shevchenko@nokia.com>,
"eric.dumazet@gmail.com" <eric.dumazet@gmail.com>,
"x86@kernel.org" <x86@kernel.org>,
"opurdila@ixiacom.com" <opurdila@ixiacom.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"ying.huang@intel.com" <ying.huang@intel.com>,
"kees.cook@canonical.com" <kees.cook@canonical.com>,
"paulmck@linux.vnet.ibm.com" <paulmck@linux.vnet.ibm.com>,
"dzickus@redhat.com" <dzickus@redhat.com>,
"len.brown@intel.com" <len.brown@intel.com>,
"seto.hidetoshi@jp.fujitsu.com" <seto.hidetoshi@jp.fujitsu.com>,
"hadi@cyberus.ca" <hadi@cyberus.ca>,
Borislav Petkov <bp@alien8.de>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"hidave.darkstar@gmail.com" <hidave.darkstar@gmail.com>,
"eugeneteo@kernel.org" <eugeneteo@kernel.org>,
"gregkh@suse.de" <gregkh@suse.de>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Satoru Moriya <satoru.moriya@hds.com>,
"tj@kernel.org" <tj@kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [RFC][PATCH] Add a sysctl option controlling kexec when MCE occurred
Date: Sat, 25 Dec 2010 10:33:02 -0800 [thread overview]
Message-ID: <4D1638DE.1080005@zytor.com> (raw)
In-Reply-To: <m1oc89ixc5.fsf@fess.ebiederm.org>
On 12/25/2010 09:19 AM, Eric W. Biederman wrote:
>>
>> So, kdump may receive wrong identifier when it starts after MCE
>> occurred, because MCE is reported by memory, cache, and TLB errors
>>
>> In the worst case, kdump will overwrite user data if it recognizes a
>> disk saving user data as a dump disk.
>
> Absurdly unlikely there is a sha256 checksum verified over the
> kdump kernel before it starts booting. If you have very broken
> memory it is possible, but absurdly unlikely that the machine will
> even boot if you are having enough uncorrectable memory errors
> an hour to get past the sha256 checksum and then be corruppt.
>
That wouldn't be the likely scenario (passing a sha256 checksum with the
wrong data due to a random event will never happen for all the computers
on Earth before the Sun destroys the planet). However, in a
failing-memory scenario, the much more likely scenario is that kdump
starts up, verifies the signature, and *then* has corruption causing it
to write to the wrong disk or whatnot. This is inherent in any scheme
that allows writing to hard media after a failure (as opposed to, say,
dumping to the network.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>,
Borislav Petkov <bp@alien8.de>, Andi Kleen <andi@firstfloor.org>,
"rdunlap@xenotime.net" <rdunlap@xenotime.net>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"x86@kernel.org" <x86@kernel.org>,
"akpm@linuxfoundation.org" <akpm@linuxfoundation.org>,
"eugeneteo@kernel.org" <eugeneteo@kernel.org>,
"kees.cook@canonical.com" <kees.cook@canonical.com>,
"drosenberg@vsecurity.com" <drosenberg@vsecurity.com>,
"ying.huang@intel.com" <ying.huang@intel.com>,
"len.brown@intel.com" <len.brown@intel.com>,
"seto.hidetoshi@jp.fujitsu.com" <seto.hidetoshi@jp.fujitsu.com>,
"paulmck@linux.vnet.ibm.com" <paulmck@linux.vnet.ibm.com>,
"gregkh@suse.de" <gregkh@suse.de>,
"davem@davemloft.net" <davem@davemloft.net>,
"hadi@cyberus.ca" <hadi@cyberus.ca>,
"hawk@comx.dk" <hawk@comx.dk>,
"opurdila@ixiacom.com" <opurdila@ixiacom.com>,
"hidave.darkstar@gmail.com" <hidave.darkstar@gmail.com>,
"dzickus@redhat.com" <dzickus@redhat.com>,
"eric.dumazet@gmail.com" <eric.dumazet@gmail.com>,
"ext-andriy.shevchenko@nokia.com"
<ext-andriy.shevchenko@nokia.com>,
"tj@kernel.org" <tj@kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"dle-develop@lists.sourceforge.net"
<dle-develop@lists.sourceforge.net>,
Satoru Moriya <satoru.moriya@hds.com>
Subject: Re: [RFC][PATCH] Add a sysctl option controlling kexec when MCE occurred
Date: Sat, 25 Dec 2010 10:33:02 -0800 [thread overview]
Message-ID: <4D1638DE.1080005@zytor.com> (raw)
In-Reply-To: <m1oc89ixc5.fsf@fess.ebiederm.org>
On 12/25/2010 09:19 AM, Eric W. Biederman wrote:
>>
>> So, kdump may receive wrong identifier when it starts after MCE
>> occurred, because MCE is reported by memory, cache, and TLB errors
>>
>> In the worst case, kdump will overwrite user data if it recognizes a
>> disk saving user data as a dump disk.
>
> Absurdly unlikely there is a sha256 checksum verified over the
> kdump kernel before it starts booting. If you have very broken
> memory it is possible, but absurdly unlikely that the machine will
> even boot if you are having enough uncorrectable memory errors
> an hour to get past the sha256 checksum and then be corruppt.
>
That wouldn't be the likely scenario (passing a sha256 checksum with the
wrong data due to a random event will never happen for all the computers
on Earth before the Sun destroys the planet). However, in a
failing-memory scenario, the much more likely scenario is that kdump
starts up, verifies the signature, and *then* has corruption causing it
to write to the wrong disk or whatnot. This is inherent in any scheme
that allows writing to hard media after a failure (as opposed to, say,
dumping to the network.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-12-25 18:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-22 23:35 [RFC][PATCH] Add a sysctl option controlling kexec when MCE occurred Seiji Aguchi
2010-12-23 0:29 ` Greg KH
2010-12-23 0:29 ` Greg KH
2010-12-23 7:43 ` Andi Kleen
2010-12-23 7:43 ` Andi Kleen
2010-12-23 9:18 ` Borislav Petkov
2010-12-23 9:18 ` Borislav Petkov
2010-12-23 17:31 ` Seiji Aguchi
2010-12-23 17:31 ` Seiji Aguchi
2010-12-23 19:56 ` Eric W. Biederman
2010-12-23 19:56 ` Eric W. Biederman
2010-12-25 14:56 ` Seiji Aguchi
2010-12-25 17:19 ` Eric W. Biederman
2010-12-25 17:19 ` Eric W. Biederman
2010-12-25 18:33 ` H. Peter Anvin [this message]
2010-12-25 18:33 ` H. Peter Anvin
2010-12-25 21:40 ` Eric W. Biederman
2010-12-25 21:40 ` Eric W. Biederman
2010-12-27 1:56 ` Hidetoshi Seto
2010-12-27 1:56 ` Hidetoshi Seto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D1638DE.1080005@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linuxfoundation.org \
--cc=andi@firstfloor.org \
--cc=bp@alien8.de \
--cc=davem@davemloft.net \
--cc=dle-develop@lists.sourceforge.net \
--cc=drosenberg@vsecurity.com \
--cc=dzickus@redhat.com \
--cc=ebiederm@xmission.com \
--cc=eric.dumazet@gmail.com \
--cc=eugeneteo@kernel.org \
--cc=ext-andriy.shevchenko@nokia.com \
--cc=gregkh@suse.de \
--cc=hadi@cyberus.ca \
--cc=hawk@comx.dk \
--cc=hidave.darkstar@gmail.com \
--cc=kees.cook@canonical.com \
--cc=kexec@lists.infradead.org \
--cc=len.brown@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=opurdila@ixiacom.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rdunlap@xenotime.net \
--cc=satoru.moriya@hds.com \
--cc=seiji.aguchi@hds.com \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=x86@kernel.org \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.