From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Alison Schofield <alison.schofield@intel.com>,
dhowells@redhat.com, tglx@linutronix.de
Cc: Kai Huang <kai.huang@intel.com>,
Jun Nakajima <jun.nakajima@intel.com>,
Kirill Shutemov <kirill.shutemov@intel.com>,
Dave Hansen <dave.hansen@intel.com>,
jmorris@namei.org, keyrings@vger.kernel.org,
linux-security-module@vger.kernel.org, mingo@redhat.com,
hpa@zytor.com, x86@kernel.org, linux-mm@kvack.org
Subject: Re: [RFC 08/12] mm: Track VMA's in use for each memory encryption keyid
Date: Mon, 10 Sep 2018 21:20:45 +0300 [thread overview]
Message-ID: <781e142c17199a6ab44bf0b5fbf07190093fe5dc.camel@linux.intel.com> (raw)
In-Reply-To: <3c891d076a376c8cff04403e90d04cf98b203960.1536356108.git.alison.schofield@intel.com>
On Fri, 2018-09-07 at 15:37 -0700, Alison Schofield wrote:
> Keep track of the VMA's oustanding for each memory encryption keyid.
> The count is used by the MKTME (Multi-Key Total Memory Encryption)
> Key Service to determine when it is safe to reprogram a hardware
> encryption key.
Maybe a stupid question but why they are tracked and what do you
mean by tracking?
/Jarkko
> Approach here is to do gets and puts on the encryption reference
> wherever kmem_cache_alloc/free's of vma_area_cachep's are executed.
> A couple of these locations will not be hit until cgroup support is
> added. One of these locations should never hit, so use a VM_WARN_ON.
>
> Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> ---
> arch/x86/mm/mktme.c | 2 ++
> kernel/fork.c | 2 ++
> mm/mmap.c | 12 ++++++++++++
> mm/nommu.c | 4 ++++
> 4 files changed, 20 insertions(+)
>
> diff --git a/arch/x86/mm/mktme.c b/arch/x86/mm/mktme.c
> index 5690ef51a79a..8a7c326d4546 100644
> --- a/arch/x86/mm/mktme.c
> +++ b/arch/x86/mm/mktme.c
> @@ -72,10 +72,12 @@ void mprotect_set_encrypt(struct vm_area_struct *vma, int
> newkeyid)
> if (newkeyid == oldkeyid)
> return;
>
> + vma_put_encrypt_ref(vma);
> newprot = pgprot_val(vma->vm_page_prot);
> newprot &= ~mktme_keyid_mask;
> newprot |= (unsigned long)newkeyid << mktme_keyid_shift;
> vma->vm_page_prot = __pgprot(newprot);
> + vma_get_encrypt_ref(vma);
> }
>
> /*
> diff --git a/kernel/fork.c b/kernel/fork.c
> index e5e7a220a124..2d0e507bde7c 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -459,6 +459,7 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> if (!tmp)
> goto fail_nomem;
> *tmp = *mpnt;
> + vma_get_encrypt_ref(tmp); /* Track encrypted vma's */
> INIT_LIST_HEAD(&tmp->anon_vma_chain);
> retval = vma_dup_policy(mpnt, tmp);
> if (retval)
> @@ -539,6 +540,7 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> fail_nomem_anon_vma_fork:
> mpol_put(vma_policy(tmp));
> fail_nomem_policy:
> + vma_put_encrypt_ref(tmp); /* Track encrypted vma's */
> kmem_cache_free(vm_area_cachep, tmp);
> fail_nomem:
> retval = -ENOMEM;
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 4c604eb644b4..7390b8b69fd6 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -182,6 +182,7 @@ static struct vm_area_struct *remove_vma(struct
> vm_area_struct *vma)
> if (vma->vm_file)
> fput(vma->vm_file);
> mpol_put(vma_policy(vma));
> + vma_put_encrypt_ref(vma);
> kmem_cache_free(vm_area_cachep, vma);
> return next;
> }
> @@ -913,6 +914,7 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long
> start,
> anon_vma_merge(vma, next);
> mm->map_count--;
> mpol_put(vma_policy(next));
> + vma_put_encrypt_ref(next);
> kmem_cache_free(vm_area_cachep, next);
> /*
> * In mprotect's case 6 (see comments on vma_merge),
> @@ -1744,6 +1746,7 @@ unsigned long mmap_region(struct file *file, unsigned
> long addr,
> goto unacct_error;
> }
>
> + vma_get_encrypt_ref(vma);
> vma->vm_mm = mm;
> vma->vm_start = addr;
> vma->vm_end = addr + len;
> @@ -1839,6 +1842,7 @@ unsigned long mmap_region(struct file *file, unsigned
> long addr,
> unmap_and_free_vma:
> vma->vm_file = NULL;
> fput(file);
> + vma_put_encrypt_ref(vma);
>
> /* Undo any partial mapping done by a device driver. */
> unmap_region(mm, vma, prev, vma->vm_start, vma->vm_end);
> @@ -2653,6 +2657,7 @@ int __split_vma(struct mm_struct *mm, struct
> vm_area_struct *vma,
> new->vm_pgoff += ((addr - vma->vm_start) >> PAGE_SHIFT);
> }
>
> + vma_get_encrypt_ref(new);
> err = vma_dup_policy(vma, new);
> if (err)
> goto out_free_vma;
> @@ -2686,6 +2691,7 @@ int __split_vma(struct mm_struct *mm, struct
> vm_area_struct *vma,
> out_free_mpol:
> mpol_put(vma_policy(new));
> out_free_vma:
> + vma_put_encrypt_ref(new);
> kmem_cache_free(vm_area_cachep, new);
> return err;
> }
> @@ -3007,6 +3013,7 @@ static int do_brk_flags(unsigned long addr, unsigned
> long len, unsigned long fla
> return -ENOMEM;
> }
>
> + vma_get_encrypt_ref(vma);
> INIT_LIST_HEAD(&vma->anon_vma_chain);
> vma->vm_mm = mm;
> vma->vm_ops = &anon_vm_ops;
> @@ -3229,6 +3236,7 @@ struct vm_area_struct *copy_vma(struct vm_area_struct
> **vmap,
> new_vma->vm_pgoff = pgoff;
> if (vma_dup_policy(vma, new_vma))
> goto out_free_vma;
> + vma_get_encrypt_ref(new_vma);
> INIT_LIST_HEAD(&new_vma->anon_vma_chain);
> if (anon_vma_clone(new_vma, vma))
> goto out_free_mempol;
> @@ -3243,6 +3251,7 @@ struct vm_area_struct *copy_vma(struct vm_area_struct
> **vmap,
>
> out_free_mempol:
> mpol_put(vma_policy(new_vma));
> + vma_put_encrypt_ref(new_vma);
> out_free_vma:
> kmem_cache_free(vm_area_cachep, new_vma);
> out:
> @@ -3372,6 +3381,9 @@ static struct vm_area_struct *__install_special_mapping(
> if (unlikely(vma == NULL))
> return ERR_PTR(-ENOMEM);
>
> + /* Do not expect a memory encrypted vma here */
> + VM_WARN_ON(vma_keyid(vma));
> +
> INIT_LIST_HEAD(&vma->anon_vma_chain);
> vma->vm_mm = mm;
> vma->vm_start = addr;
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 73f66e81cfb0..85f04c174638 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -769,6 +769,7 @@ static void delete_vma(struct mm_struct *mm, struct
> vm_area_struct *vma)
> if (vma->vm_file)
> fput(vma->vm_file);
> put_nommu_region(vma->vm_region);
> + vma_put_encrypt_ref(vma);
> kmem_cache_free(vm_area_cachep, vma);
> }
>
> @@ -1215,6 +1216,7 @@ unsigned long do_mmap(struct file *file,
> if (!vma)
> goto error_getting_vma;
>
> + vma_get_encrypt_ref(vma);
> region->vm_usage = 1;
> region->vm_flags = vm_flags;
> region->vm_pgoff = pgoff;
> @@ -1375,6 +1377,7 @@ unsigned long do_mmap(struct file *file,
> kmem_cache_free(vm_region_jar, region);
> if (vma->vm_file)
> fput(vma->vm_file);
> + vma_put_encrypt_ref(vma);
> kmem_cache_free(vm_area_cachep, vma);
> return ret;
>
> @@ -1486,6 +1489,7 @@ int split_vma(struct mm_struct *mm, struct
> vm_area_struct *vma,
> *new = *vma;
> *region = *vma->vm_region;
> new->vm_region = region;
> + vma_get_encrypt_ref(new);
>
> npages = (addr - vma->vm_start) >> PAGE_SHIFT;
>
next prev parent reply other threads:[~2018-09-10 18:20 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-07 22:23 [RFC 00/12] Multi-Key Total Memory Encryption API (MKTME) Alison Schofield
2018-09-07 22:34 ` [RFC 01/12] docs/x86: Document the Multi-Key Total Memory Encryption API Alison Schofield
2018-09-08 18:44 ` Randy Dunlap
2018-09-10 1:28 ` Huang, Kai
2018-09-11 0:13 ` Alison Schofield
2018-09-11 0:33 ` Huang, Kai
2018-09-11 0:45 ` Alison Schofield
2018-09-11 1:14 ` Huang, Kai
2018-09-11 0:14 ` Huang, Kai
2018-09-10 17:32 ` Sakkinen, Jarkko
2018-09-11 0:19 ` Alison Schofield
2018-09-07 22:34 ` [RFC 02/12] mm: Generalize the mprotect implementation to support extensions Alison Schofield
2018-09-10 10:12 ` Jarkko Sakkinen
2018-09-11 0:34 ` Alison Schofield
2018-09-07 22:34 ` [RFC 03/12] syscall/x86: Wire up a new system call for memory encryption keys Alison Schofield
2018-09-07 22:36 ` [RFC 04/12] x86/mm: Add helper functions to manage " Alison Schofield
2018-09-10 2:56 ` Huang, Kai
2018-09-10 23:37 ` Huang, Kai
2018-09-10 23:41 ` Alison Schofield
2018-09-10 17:37 ` Sakkinen, Jarkko
2018-09-07 22:36 ` [RFC 05/12] x86/mm: Add a helper function to set keyid bits in encrypted VMA's Alison Schofield
2018-09-10 17:57 ` Sakkinen, Jarkko
2018-09-07 22:36 ` [RFC 06/12] mm: Add the encrypt_mprotect() system call Alison Schofield
2018-09-10 18:02 ` Jarkko Sakkinen
2018-09-11 2:15 ` Alison Schofield
2018-09-07 22:37 ` [RFC 07/12] x86/mm: Add helper functions to track encrypted VMA's Alison Schofield
2018-09-10 3:17 ` Huang, Kai
2018-09-07 22:37 ` [RFC 08/12] mm: Track VMA's in use for each memory encryption keyid Alison Schofield
2018-09-10 18:20 ` Jarkko Sakkinen [this message]
2018-09-11 2:39 ` Alison Schofield
2018-09-07 22:37 ` [RFC 09/12] mm: Restrict memory encryption to anonymous VMA's Alison Schofield
2018-09-10 18:21 ` Sakkinen, Jarkko
2018-09-10 18:57 ` Dave Hansen
2018-09-10 21:07 ` Jarkko Sakkinen
2018-09-10 21:09 ` Dave Hansen
2018-09-07 22:38 ` [RFC 10/12] x86/pconfig: Program memory encryption keys on a system-wide basis Alison Schofield
2018-09-10 1:46 ` Huang, Kai
2018-09-10 18:24 ` Sakkinen, Jarkko
2018-09-11 2:46 ` Alison Schofield
2018-09-11 14:31 ` Jarkko Sakkinen
2018-09-07 22:38 ` [RFC 11/12] keys/mktme: Add a new key service type for memory encryption keys Alison Schofield
2018-09-10 3:29 ` Huang, Kai
2018-09-10 21:47 ` Alison Schofield
2018-09-15 0:06 ` Alison Schofield
2018-09-17 10:48 ` Huang, Kai
2018-09-17 22:34 ` Huang, Kai
2018-09-07 22:39 ` [RFC 12/12] keys/mktme: Do not revoke in use " Alison Schofield
2018-09-10 1:10 ` [RFC 00/12] Multi-Key Total Memory Encryption API (MKTME) Huang, Kai
2018-09-10 19:10 ` Alison Schofield
2018-09-11 3:15 ` Huang, Kai
2018-09-10 17:29 ` Sakkinen, Jarkko
2018-09-11 22:03 ` [RFC 11/12] keys/mktme: Add a new key service type for memory encryption keys David Howells
2018-09-11 22:39 ` Alison Schofield
2018-09-11 23:01 ` David Howells
2018-09-11 22:56 ` [RFC 04/12] x86/mm: Add helper functions to manage " David Howells
2018-09-12 11:12 ` [RFC 12/12] keys/mktme: Do not revoke in use " David Howells
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=781e142c17199a6ab44bf0b5fbf07190093fe5dc.camel@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=alison.schofield@intel.com \
--cc=dave.hansen@intel.com \
--cc=dhowells@redhat.com \
--cc=hpa@zytor.com \
--cc=jmorris@namei.org \
--cc=jun.nakajima@intel.com \
--cc=kai.huang@intel.com \
--cc=keyrings@vger.kernel.org \
--cc=kirill.shutemov@intel.com \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mingo@redhat.com \
--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;
as well as URLs for NNTP newsgroup(s).