From: Juerg Haefliger <juerg.haefliger@hpe.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kernel-hardening@lists.openwall.com,
linux-x86_64@vger.kernel.org, vpk@cs.columbia.edu
Subject: Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)
Date: Mon, 28 Nov 2016 12:15:10 +0100 [thread overview]
Message-ID: <795a34a6-ed04-dea3-73f5-d23e48f69de6@hpe.com> (raw)
In-Reply-To: <20161124105629.GA23034@linaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 2003 bytes --]
On 11/24/2016 11:56 AM, AKASHI Takahiro wrote:
> Hi,
>
> I'm trying to give it a spin on arm64, but ...
Thanks for trying this.
>> +/*
>> + * Update a single kernel page table entry
>> + */
>> +static inline void set_kpte(struct page *page, unsigned long kaddr,
>> + pgprot_t prot) {
>> + unsigned int level;
>> + pte_t *kpte = lookup_address(kaddr, &level);
>> +
>> + /* We only support 4k pages for now */
>> + BUG_ON(!kpte || level != PG_LEVEL_4K);
>> +
>> + set_pte_atomic(kpte, pfn_pte(page_to_pfn(page), canon_pgprot(prot)));
>> +}
>
> As lookup_address() and set_pte_atomic() (and PG_LEVEL_4K), are arch-specific,
> would it be better to put the whole definition into arch-specific part?
Well yes but I haven't really looked into splitting up the arch specific stuff.
>> + /*
>> + * Map the page back into the kernel if it was previously
>> + * allocated to user space.
>> + */
>> + if (test_and_clear_bit(PAGE_EXT_XPFO_UNMAPPED,
>> + &page_ext->flags)) {
>> + kaddr = (unsigned long)page_address(page + i);
>> + set_kpte(page + i, kaddr, __pgprot(__PAGE_KERNEL));
>
> Why not PAGE_KERNEL?
Good catch, thanks!
>> + /*
>> + * The page is to be allocated back to user space, so unmap it from the
>> + * kernel, flush the TLB and tag it as a user page.
>> + */
>> + if (atomic_dec_return(&page_ext->mapcount) == 0) {
>> + BUG_ON(test_bit(PAGE_EXT_XPFO_UNMAPPED, &page_ext->flags));
>> + set_bit(PAGE_EXT_XPFO_UNMAPPED, &page_ext->flags);
>> + set_kpte(page, (unsigned long)kaddr, __pgprot(0));
>> + __flush_tlb_one((unsigned long)kaddr);
>
> Again __flush_tlb_one() is x86-specific.
> flush_tlb_kernel_range() instead?
I'll take a look. If you can tell me what the relevant arm64 equivalents are for the arch-specific
functions, that would help tremendously.
Thanks for the comments!
...Juerg
> Thanks,
> -Takahiro AKASHI
--
Juerg Haefliger
Hewlett Packard Enterprise
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2016-11-28 11:15 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 14:21 [RFC PATCH] Add support for eXclusive Page Frame Ownership (XPFO) Juerg Haefliger
2016-03-01 1:31 ` Laura Abbott
2016-03-21 8:37 ` Juerg Haefliger
2016-03-28 19:29 ` Laura Abbott
2016-03-01 2:10 ` Balbir Singh
2016-03-21 8:44 ` Juerg Haefliger
2016-04-01 0:21 ` Balbir Singh
2016-09-02 11:39 ` [RFC PATCH v2 0/3] " Juerg Haefliger
2016-09-02 11:39 ` [RFC PATCH v2 1/3] " Juerg Haefliger
2016-09-02 11:39 ` [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache Juerg Haefliger
2016-09-02 20:39 ` Dave Hansen
2016-09-05 11:54 ` Juerg Haefliger
2016-09-02 11:39 ` [RFC PATCH v2 3/3] block: Always use a bounce buffer when XPFO is enabled Juerg Haefliger
2016-09-14 7:18 ` [RFC PATCH v2 0/3] Add support for eXclusive Page Frame Ownership (XPFO) Juerg Haefliger
2016-09-14 7:18 ` [RFC PATCH v2 1/3] " Juerg Haefliger
2016-09-14 7:19 ` [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache Juerg Haefliger
2016-09-14 14:33 ` [kernel-hardening] " Dave Hansen
2016-09-14 14:40 ` Juerg Haefliger
2016-09-14 14:48 ` Dave Hansen
2016-09-21 5:32 ` Juerg Haefliger
2016-09-14 7:19 ` [RFC PATCH v2 3/3] block: Always use a bounce buffer when XPFO is enabled Juerg Haefliger
2016-09-14 7:33 ` Christoph Hellwig
2016-09-14 7:23 ` [RFC PATCH v2 0/3] Add support for eXclusive Page Frame Ownership (XPFO) Juerg Haefliger
2016-09-14 9:36 ` [kernel-hardening] " Mark Rutland
2016-09-14 9:49 ` Mark Rutland
2016-11-04 14:45 ` [RFC PATCH v3 0/2] " Juerg Haefliger
2016-11-04 14:45 ` [RFC PATCH v3 1/2] " Juerg Haefliger
2016-11-04 14:50 ` Christoph Hellwig
2016-11-10 5:53 ` [kernel-hardening] " ZhaoJunmin Zhao(Junmin)
2016-11-10 19:11 ` Kees Cook
2016-11-15 11:15 ` Juerg Haefliger
2016-11-10 19:24 ` Kees Cook
2016-11-15 11:18 ` Juerg Haefliger
2016-11-24 10:56 ` AKASHI Takahiro
2016-11-28 11:15 ` Juerg Haefliger [this message]
2016-12-09 9:02 ` AKASHI Takahiro
2016-11-04 14:45 ` [RFC PATCH v3 2/2] xpfo: Only put previous userspace pages into the hot cache Juerg Haefliger
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=795a34a6-ed04-dea3-73f5-d23e48f69de6@hpe.com \
--to=juerg.haefliger@hpe.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-x86_64@vger.kernel.org \
--cc=takahiro.akashi@linaro.org \
--cc=vpk@cs.columbia.edu \
/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).