From: Michal Hocko <mhocko@kernel.org>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Dave Hansen <dave.hansen@intel.com>,
Kai Huang <kai.huang@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCHv2 06/14] mm/page_alloc: Propagate encryption KeyID through page allocator
Date: Thu, 29 Mar 2018 15:37:00 +0200 [thread overview]
Message-ID: <20180329133700.GG31039@dhcp22.suse.cz> (raw)
In-Reply-To: <20180329131308.cq64n3dvnre2wcz5@node.shutemov.name>
On Thu 29-03-18 16:13:08, Kirill A. Shutemov wrote:
> On Thu, Mar 29, 2018 at 02:52:27PM +0200, Michal Hocko wrote:
> > On Thu 29-03-18 15:37:12, Kirill A. Shutemov wrote:
> > > On Thu, Mar 29, 2018 at 01:20:34PM +0200, Michal Hocko wrote:
> > > > On Wed 28-03-18 19:55:32, Kirill A. Shutemov wrote:
> > > > > Modify several page allocation routines to pass down encryption KeyID to
> > > > > be used for the allocated page.
> > > > >
> > > > > There are two basic use cases:
> > > > >
> > > > > - alloc_page_vma() use VMA's KeyID to allocate the page.
> > > > >
> > > > > - Page migration and NUMA balancing path use KeyID of original page as
> > > > > KeyID for newly allocated page.
> > > >
> > > > I am sorry but I am out of time to look closer but this just raised my
> > > > eyebrows. This looks like a no-go. The basic allocator has no business
> > > > in fancy stuff like a encryption key. If you need something like that
> > > > then just build a special allocator API on top. This looks like a no-go
> > > > to me.
> > >
> > > The goal is to make memory encryption first class citizen in memory
> > > management and not to invent parallel subsysustem (as we did with hugetlb).
> >
> > How do you get a page_keyid for random kernel allocation?
>
> Initial feature enabling only targets userspace anonymous memory, but we
> can definately use the same technology in the future for kernel hardening
> if we would choose so.
So what kind of key are you going to use for those allocations. Moreover
why cannot you simply wrap those few places which are actually using the
encryption now?
> For anonymous memory, we can get KeyID from VMA or from other page
> (migration case).
>
> > > Making memory encryption integral part of Linux VM would involve handing
> > > encrypted page everywhere we expect anonymous page to appear.
> >
> > How many architectures will implement this feature?
>
> I can't read the future.
Fair enough, only few of us can, but you are proposing a generic code
changes based on a single architecture design so we should better make
sure other architectures can work with that approach without a major
refactoring.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-03-29 13:37 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-28 16:55 [PATCHv2 00/14] Partial MKTME enabling Kirill A. Shutemov
2018-03-28 16:55 ` [PATCHv2 01/14] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME Kirill A. Shutemov
2018-04-02 21:12 ` Tom Lendacky
2018-03-28 16:55 ` [PATCHv2 02/14] x86/mm: Mask out KeyID bits from page table entry pfn Kirill A. Shutemov
2018-03-28 16:55 ` [PATCHv2 03/14] mm/shmem: Zero out unused vma fields in shmem_pseudo_vma_init() Kirill A. Shutemov
2018-03-28 16:55 ` [PATCHv2 04/14] mm: Do no merge vma with different encryption KeyIDs Kirill A. Shutemov
2018-03-28 16:55 ` [PATCHv2 05/14] mm/khugepaged: Do not collapse pages in encrypted VMAs Kirill A. Shutemov
2018-03-28 16:55 ` [PATCHv2 06/14] mm/page_alloc: Propagate encryption KeyID through page allocator Kirill A. Shutemov
2018-03-28 17:15 ` Dave Hansen
2018-03-29 12:38 ` Kirill A. Shutemov
2018-03-29 11:20 ` Michal Hocko
2018-03-29 12:37 ` Kirill A. Shutemov
2018-03-29 12:52 ` Michal Hocko
2018-03-29 13:13 ` Kirill A. Shutemov
2018-03-29 13:37 ` Michal Hocko [this message]
2018-03-29 14:33 ` Kirill A. Shutemov
2018-03-30 8:07 ` Kirill A. Shutemov
2018-03-28 16:55 ` [PATCHv2 07/14] mm/page_alloc: Add hook in page allocation path for encrypted pages Kirill A. Shutemov
2018-03-28 16:55 ` [PATCHv2 08/14] mm/page_ext: Drop definition of unused PAGE_EXT_DEBUG_POISON Kirill A. Shutemov
2018-03-29 5:32 ` Vinayak Menon
2018-03-28 16:55 ` [PATCHv2 09/14] x86/mm: Introduce variables to store number, shift and mask of KeyIDs Kirill A. Shutemov
2018-03-28 16:55 ` [PATCHv2 10/14] x86/mm: Preserve KeyID on pte_modify() and pgprot_modify() Kirill A. Shutemov
2018-03-28 16:55 ` [PATCHv2 11/14] x86/mm: Implement vma_is_encrypted() and vma_keyid() Kirill A. Shutemov
2018-03-28 16:55 ` [PATCHv2 12/14] x86/mm: Implement page_keyid() using page_ext Kirill A. Shutemov
2018-03-28 16:59 ` Dave Hansen
2018-03-29 12:43 ` Kirill A. Shutemov
2018-03-28 16:55 ` [PATCHv2 13/14] x86/mm: Implement prep_encrypted_page() Kirill A. Shutemov
2018-03-28 16:55 ` [PATCHv2 14/14] x86: Introduce CONFIG_X86_INTEL_MKTME Kirill A. Shutemov
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=20180329133700.GG31039@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=kai.huang@linux.intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--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