public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Petr Tesarik <ptesarik@suse.cz>, lijiang <lijiang@redhat.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	kexec@lists.infradead.org, mingo@redhat.com, tglx@linutronix.de,
	dyoung@redhat.com
Subject: Re: [PATCH] kdump, vmcoreinfo: Export sme_me_mask value to vmcoreinfo
Date: Sat, 27 Oct 2018 17:39:17 +0800	[thread overview]
Message-ID: <20181027093917.GA14493@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20181027091007.GB1046@nazgul.tnic>

On 10/27/18 at 11:10am, Borislav Petkov wrote:
> On Sat, Oct 27, 2018 at 04:13:43PM +0800, Baoquan He wrote:
> > Yes, agree. So sme_me_mask itself or the encryption bit number, both is
> > fine.
> 
> You need the encryption bit position and it better be properly formatted
> and extracted into a vmcoreinfo-specific variable because we don't
> expose arch-specific details like sme_me_mask to the outside.

Not very sure about this, we have arch_crash_save_vmcoreinfo() in
arch/x86/kernel/machine_kexec_64.c to export arch-specific stuffs
outside. Is there any special reason about a mask in one architecture
when expose it out? In fact it's only that bit position set mask, no
other information. Surely it's also fine if we export encryption bit
position, then convert it to mask in makedumpfile.

> 
> >  we may use cp to copy /proc/vmcore to a file directly, then analyze
> > it in another compupter. This often happen when there's something
> > wrong with makedumpfile, we need debug makedumpfile with the complete
> > copied file.
> 
> So for the analyze-on-another-computer scenario you absolutely must copy
> anything from the first kernel decrypted because you can't decrypt it on
> the other machine.
> 
> Which means, in a sensitive environment, you probably should copy and
> *encrypt* the dump again with gpg or so.

Hmm, no matter it's makedumpfile or cp directly, when we read
/proc/vmcore in kdump kernel, it will call __read_vmcore() or related
functions in fs/proc/vmcore.c. With regarding to SME memory reading,
Lianbo should have handle it in previous SME support in kdump patches.
Just those page tables in crashed kernel are also memory content, they
are decrypted and copied out, while with SME bit position enabled to
indicate encryption, that bit position is added by kernel, now the 1st
kernel is dead, we need wipe it out in makedumpfile when parsing. So
this 'cp', it's still need be done in kdump kernel by 'cp' /proc/vmcore.

Thanks
Baoquan

  reply	other threads:[~2018-10-27  9:39 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-26  9:36 [PATCH] kdump, vmcoreinfo: Export sme_me_mask value to vmcoreinfo Lianbo Jiang
2018-10-26  9:43 ` Boris Petkov
2018-10-26 12:32   ` lijiang
2018-10-26 16:24     ` Petr Tesarik
2018-10-26 22:25       ` Borislav Petkov
2018-10-27  2:57         ` lijiang
2018-10-27  8:13         ` Baoquan He
2018-10-27  9:10           ` Borislav Petkov
2018-10-27  9:39             ` Baoquan He [this message]
2018-10-27 10:12               ` Borislav Petkov
2018-10-27 11:08                 ` Baoquan He
2018-10-27 13:17                   ` Boris Petkov
2018-10-27 14:41                     ` lijiang
2018-10-27 14:51                       ` Borislav Petkov
2018-10-29  7:59                         ` lijiang
2018-10-29  8:31                           ` Baoquan He
2018-10-29  9:29                             ` lijiang
2018-10-29  9:57                               ` Borislav Petkov
2018-10-29 10:12                                 ` lijiang
2018-10-29 11:44                                   ` Baoquan He
2018-10-29 13:41                                     ` lijiang
2018-10-29 13:49                                       ` Borislav Petkov
2018-10-30  4:46                                         ` lijiang
2018-10-30  5:09                                           ` Dave Young
2018-10-30  9:15                                             ` Borislav Petkov
2018-10-30  9:23                                               ` Baoquan He
2018-10-31  2:26                                                 ` lijiang
2018-10-31  2:47                                                   ` Dave Young
2018-10-31  7:43                                                     ` lijiang
2018-10-31 10:10                                                     ` Borislav Petkov
2018-11-01 15:01                                                       ` Kazuhito Hagio
2018-10-26 16:35     ` Borislav Petkov
2018-10-27  2:19       ` lijiang

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=20181027093917.GA14493@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=dyoung@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=lijiang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=ptesarik@suse.cz \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox