linux-nvdimm.lists.01.org archive mirror
 help / color / mirror / Atom feed
From: Nick Kossifidis <mick@ics.forth.gr>
To: jejb@linux.ibm.com
Cc: David Hildenbrand <david@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Rapoport <rppt@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Borislav Petkov <bp@alien8.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christopher Lameter <cl@linux.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Elena Reshetova <elena.reshetova@intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Matthew Wilcox <willy@infradead.org>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Michal Hocko <mhocko@suse.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Rafael J. Wysocki  <rjw@rjwysocki.net>,
	Rick Edgecombe" <rick.p.edgecombe@intel.com>,
	Roman Gushchin <guro@fb.com>, Sha keel Butt <shakeelb@google.com>,
	Shuah Khan <shuah@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tycho Andersen <tycho@tycho.ws>, Will Deacon <will@kernel.org>,
	linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org,
	x86@kernel.org
Subject: Re: [PATCH v18 0/9] mm: introduce memfd_secret system call to create "secret" memory areas
Date: Fri, 07 May 2021 02:16:03 +0300	[thread overview]
Message-ID: <77fe28bd940b2c1afd69d65b6d349352@mailhost.ics.forth.gr> (raw)
In-Reply-To: <8eb933f921c9dfe4c9b1b304e8f8fa4fbc249d84.camel@linux.ibm.com>

Στις 2021-05-06 20:05, James Bottomley έγραψε:
> On Thu, 2021-05-06 at 18:45 +0200, David Hildenbrand wrote:
>> 
>> Also, there is a way to still read that memory when root by
>> 
>> 1. Having kdump active (which would often be the case, but maybe not
>> to dump user pages )
>> 2. Triggering a kernel crash (easy via proc as root)
>> 3. Waiting for the reboot after kump() created the dump and then
>> reading the content from disk.
> 
> Anything that can leave physical memory intact but boot to a kernel
> where the missing direct map entry is restored could theoretically
> extract the secret.  However, it's not exactly going to be a stealthy
> extraction ...
> 
>> Or, as an attacker, load a custom kexec() kernel and read memory
>> from the new environment. Of course, the latter two are advanced
>> mechanisms, but they are possible when root. We might be able to
>> mitigate, for example, by zeroing out secretmem pages before booting
>> into the kexec kernel, if we care :)
> 
> I think we could handle it by marking the region, yes, and a zero on
> shutdown might be useful ... it would prevent all warm reboot type
> attacks.
> 

I had similar concerns about recovering secrets with kdump, and 
considered cleaning up keyrings before jumping to the new kernel. The 
problem is we can't provide guarantees in that case, once the kernel has 
crashed and we are on our way to run crashkernel, we can't be sure we 
can reliably zero-out anything, the more code we add to that path the 
more risky it gets. However during reboot/normal kexec() we should do 
some cleanup, it makes sense and secretmem can indeed be useful in that 
case. Regarding loading custom kexec() kernels, we mitigate this with 
the kexec file-based API where we can verify the signature of the loaded 
kimage (assuming the system runs a kernel provided by a trusted 3rd 
party and we 've maintained a chain of trust since booting).
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

  parent reply	other threads:[~2021-05-06 23:16 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-03 16:22 [PATCH v18 0/9] mm: introduce memfd_secret system call to create "secret" memory areas Mike Rapoport
2021-03-03 16:22 ` [PATCH v18 1/9] mm: add definition of PMD_PAGE_ORDER Mike Rapoport
2021-03-03 16:22 ` [PATCH v18 2/9] mmap: make mlock_future_check() global Mike Rapoport
2021-03-03 16:22 ` [PATCH v18 3/9] riscv/Kconfig: make direct map manipulation options depend on MMU Mike Rapoport
2021-03-03 16:22 ` [PATCH v18 4/9] set_memory: allow set_direct_map_*_noflush() for multiple pages Mike Rapoport
2021-03-03 16:22 ` [PATCH v18 5/9] set_memory: allow querying whether set_direct_map_*() is actually enabled Mike Rapoport
2021-03-03 16:22 ` [PATCH v18 6/9] mm: introduce memfd_secret system call to create "secret" memory areas Mike Rapoport
2021-03-03 16:22 ` [PATCH v18 7/9] PM: hibernate: disable when there are active secretmem users Mike Rapoport
2021-03-03 16:22 ` [PATCH v18 8/9] arch, mm: wire up memfd_secret system call where relevant Mike Rapoport
2021-03-03 16:22 ` [PATCH v18 9/9] secretmem: test: add basic selftest for memfd_secret(2) Mike Rapoport
2021-05-05 19:08 ` [PATCH v18 0/9] mm: introduce memfd_secret system call to create "secret" memory areas Andrew Morton
2021-05-06 15:26   ` James Bottomley
2021-05-06 16:45     ` David Hildenbrand
2021-05-06 17:05       ` James Bottomley
2021-05-06 17:24         ` David Hildenbrand
2021-05-06 23:16         ` Nick Kossifidis [this message]
2021-05-07  7:35           ` David Hildenbrand
2021-05-06 17:33     ` Kees Cook
2021-05-06 18:47       ` James Bottomley
2021-05-07 23:57         ` Kees Cook
2021-05-10 18:02         ` Mike Rapoport

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=77fe28bd940b2c1afd69d65b6d349352@mailhost.ics.forth.gr \
    --to=mick@ics.forth.gr \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=cl@linux.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=elena.reshetova@intel.com \
    --cc=guro@fb.com \
    --cc=hpa@zytor.com \
    --cc=jejb@linux.ibm.com \
    --cc=kirill@shutemov.name \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=mtk.manpages@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=rppt@kernel.org \
    --cc=rppt@linux.ibm.com \
    --cc=shakeelb@google.com \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tycho@tycho.ws \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --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;
as well as URLs for NNTP newsgroup(s).