From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 08/10] arm64/mmu: add contiguous bit to sanity bug check
Date: Thu, 9 Mar 2017 18:04:06 +0000 [thread overview]
Message-ID: <20170309180406.GE11966@leverpostej> (raw)
In-Reply-To: <1489047912-642-9-git-send-email-ard.biesheuvel@linaro.org>
On Thu, Mar 09, 2017 at 09:25:10AM +0100, Ard Biesheuvel wrote:
> A mapping with the contiguous bit cannot be safely manipulated while
> live, regardless of whether the bit changes between the old and new
> mapping. So take this into account when deciding whether the change
> is safe.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Strictly speaking, I think this is marginally more stringent than what
the ARM ARM describes. My reading is that the "Misprogramming of the
Contiguous bit" rules only apply when there are multiple valid entries,
and hence if you had a contiguous span with only a single valid entry
(and TLBs up-to-date), you could modify that in-place so long as you
followed the usual BBM rules.
However, I don't see us ever (deliberately) doing that, given it would
require more work, and there's no guarantee that the CPU would consider
the whole span as being mapped. It's also possible my reading of the ARM
ARM is flawed.
Thanks,
Mark.
> ---
> arch/arm64/mm/mmu.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index d3fecd20a136..a6d7a86dd2b8 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -103,7 +103,15 @@ static bool pgattr_change_is_safe(u64 old, u64 new)
> */
> static const pteval_t mask = PTE_PXN | PTE_RDONLY | PTE_WRITE;
>
> - return old == 0 || new == 0 || ((old ^ new) & ~mask) == 0;
> + /* creating or taking down mappings is always safe */
> + if (old == 0 || new == 0)
> + return true;
> +
> + /* live contiguous mappings may not be manipulated at all */
> + if ((old | new) & PTE_CONT)
> + return false;
> +
> + return ((old ^ new) & ~mask) == 0;
> }
>
> static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
> --
> 2.7.4
>
next prev parent reply other threads:[~2017-03-09 18:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-09 8:25 [PATCH v5 00/10] arm64: mmu: avoid W+X mappings and re-enable PTE_CONT for kernel Ard Biesheuvel
2017-03-09 8:25 ` [PATCH v5 01/10] arm: kvm: move kvm_vgic_global_state out of .text section Ard Biesheuvel
2017-03-09 8:25 ` [PATCH v5 02/10] arm64: mmu: move TLB maintenance from callers to create_mapping_late() Ard Biesheuvel
2017-03-09 8:25 ` [PATCH v5 03/10] arm64: alternatives: apply boot time fixups via the linear mapping Ard Biesheuvel
2017-03-09 8:25 ` [PATCH v5 04/10] arm64: mmu: map .text as read-only from the outset Ard Biesheuvel
2017-03-09 8:25 ` [PATCH v5 05/10] arm64: mmu: apply strict permissions to .init.text and .init.data Ard Biesheuvel
2017-03-09 8:25 ` [PATCH v5 06/10] arm64/mmu: align alloc_init_pte prototype with pmd/pud versions Ard Biesheuvel
2017-03-09 15:53 ` Mark Rutland
2017-03-09 8:25 ` [PATCH v5 07/10] arm64/mmu: ignore debug_pagealloc for kernel segments Ard Biesheuvel
2017-03-09 17:51 ` Mark Rutland
2017-03-09 8:25 ` [PATCH v5 08/10] arm64/mmu: add contiguous bit to sanity bug check Ard Biesheuvel
2017-03-09 18:04 ` Mark Rutland [this message]
2017-03-09 8:25 ` [PATCH v5 09/10] arm64/mmu: replace 'page_mappings_only' parameter with flags argument Ard Biesheuvel
2017-03-09 18:19 ` Mark Rutland
2017-03-09 8:25 ` [PATCH v5 10/10] arm64: mm: set the contiguous bit for kernel mappings where appropriate Ard Biesheuvel
2017-03-09 19:33 ` Mark Rutland
2017-03-09 19:40 ` Ard Biesheuvel
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=20170309180406.GE11966@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.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