All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Yao <yaojun8558363@gmail.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: james.morse@arm.com, linux-arm-kernel@lists.infradead.org,
	catalin.marinas@arm.com, will.deacon@arm.com,
	linux-kernel@vger.kernel.org,
	kernel-hardening@lists.openwall.com
Subject: Re: [PATCH 1/1] arm64/mm: move {idmap_pg_dir,tramp_pg_dir,swapper_pg_dir} to .rodata section
Date: Thu, 21 Jun 2018 20:24:36 +0800	[thread overview]
Message-ID: <20180621122436.GA19014@toy> (raw)
In-Reply-To: <CAKv+Gu-t5ErL89J=sxeVRYzDNrB1Ejdj+XOggAMWk-gY7ewsOg@mail.gmail.com>

On Thu, Jun 21, 2018 at 11:29:52AM +0200, Ard Biesheuvel wrote:
> On 21 June 2018 at 10:59, James Morse <james.morse@arm.com> wrote:
> > On 21/06/18 07:39, Ard Biesheuvel wrote:
> >> On 21 June 2018 at 04:51, Jun Yao <yaojun8558363@gmail.com> wrote:
> >>> On Wed, Jun 20, 2018 at 12:09:49PM +0200, Ard Biesheuvel wrote:
> >>>> On 20 June 2018 at 10:57, Jun Yao <yaojun8558363@gmail.com> wrote:
> >>>> As for swapper_pg_dir, it would indeed be nice if we could keep those
> >>>> mappings read-only most of the time, but I'm not sure how useful this
> >>>> is if we apply it to the root level only.
> >>>
> >>> The purpose of it is to make 'KSMA' harder, where an single arbitrary
> >>> write is used to add a block mapping to the page-tables, giving the
> >>> attacker full access to kernel memory. That's why we just apply it to
> >>> the root level only. If the attacker can arbitrary write multiple times,
> >>> I think it's hard to defend.
> >>>
> >>
> >> So the assumption is that the root level is more easy to find?
> >> Otherwise, I'm not sure I understand why being able to write a level 0
> >> entry is so harmful, given that we don't have block mappings at that
> >> level.
> >
> > I think this thing assumes 3-level page tables with 39bit VA.
> >
> 
> The attack, you mean? Because this code is unlikely to build with that
> configuration, given that __pgd_populate() BUILD_BUG()s in that case.

I think this configuration may be ok. I find that the kernel on Google
pixel 2 XL is built with 3-level page tables with 39-bit VA.

WARNING: multiple messages have this Message-ID (diff)
From: yaojun8558363@gmail.com (Jun Yao)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] arm64/mm: move {idmap_pg_dir,tramp_pg_dir,swapper_pg_dir} to .rodata section
Date: Thu, 21 Jun 2018 20:24:36 +0800	[thread overview]
Message-ID: <20180621122436.GA19014@toy> (raw)
In-Reply-To: <CAKv+Gu-t5ErL89J=sxeVRYzDNrB1Ejdj+XOggAMWk-gY7ewsOg@mail.gmail.com>

On Thu, Jun 21, 2018 at 11:29:52AM +0200, Ard Biesheuvel wrote:
> On 21 June 2018 at 10:59, James Morse <james.morse@arm.com> wrote:
> > On 21/06/18 07:39, Ard Biesheuvel wrote:
> >> On 21 June 2018 at 04:51, Jun Yao <yaojun8558363@gmail.com> wrote:
> >>> On Wed, Jun 20, 2018 at 12:09:49PM +0200, Ard Biesheuvel wrote:
> >>>> On 20 June 2018 at 10:57, Jun Yao <yaojun8558363@gmail.com> wrote:
> >>>> As for swapper_pg_dir, it would indeed be nice if we could keep those
> >>>> mappings read-only most of the time, but I'm not sure how useful this
> >>>> is if we apply it to the root level only.
> >>>
> >>> The purpose of it is to make 'KSMA' harder, where an single arbitrary
> >>> write is used to add a block mapping to the page-tables, giving the
> >>> attacker full access to kernel memory. That's why we just apply it to
> >>> the root level only. If the attacker can arbitrary write multiple times,
> >>> I think it's hard to defend.
> >>>
> >>
> >> So the assumption is that the root level is more easy to find?
> >> Otherwise, I'm not sure I understand why being able to write a level 0
> >> entry is so harmful, given that we don't have block mappings at that
> >> level.
> >
> > I think this thing assumes 3-level page tables with 39bit VA.
> >
> 
> The attack, you mean? Because this code is unlikely to build with that
> configuration, given that __pgd_populate() BUILD_BUG()s in that case.

I think this configuration may be ok. I find that the kernel on Google
pixel 2 XL is built with 3-level page tables with 39-bit VA.

  reply	other threads:[~2018-06-21 12:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-20  8:57 [PATCH 0/1] Move {idmap_pg_dir,tramp_pg_dir,swapper_pg_dir} Jun Yao
2018-06-20  8:57 ` Jun Yao
2018-06-20  8:57 ` [PATCH 1/1] arm64/mm: move {idmap_pg_dir,tramp_pg_dir,swapper_pg_dir} to .rodata section Jun Yao
2018-06-20  8:57   ` [PATCH 1/1] arm64/mm: move {idmap_pg_dir, tramp_pg_dir, swapper_pg_dir} " Jun Yao
2018-06-20 10:09   ` [PATCH 1/1] arm64/mm: move {idmap_pg_dir,tramp_pg_dir,swapper_pg_dir} " Ard Biesheuvel
2018-06-20 10:09     ` [PATCH 1/1] arm64/mm: move {idmap_pg_dir, tramp_pg_dir, swapper_pg_dir} " Ard Biesheuvel
2018-06-21  2:51     ` [PATCH 1/1] arm64/mm: move {idmap_pg_dir,tramp_pg_dir,swapper_pg_dir} " Jun Yao
2018-06-21  2:51       ` Jun Yao
2018-06-21  6:39       ` Ard Biesheuvel
2018-06-21  6:39         ` [PATCH 1/1] arm64/mm: move {idmap_pg_dir, tramp_pg_dir, swapper_pg_dir} " Ard Biesheuvel
2018-06-21  8:59         ` [PATCH 1/1] arm64/mm: move {idmap_pg_dir,tramp_pg_dir,swapper_pg_dir} " James Morse
2018-06-21  8:59           ` James Morse
2018-06-21  9:29           ` Ard Biesheuvel
2018-06-21  9:29             ` [PATCH 1/1] arm64/mm: move {idmap_pg_dir, tramp_pg_dir, swapper_pg_dir} " Ard Biesheuvel
2018-06-21 12:24             ` Jun Yao [this message]
2018-06-21 12:24               ` [PATCH 1/1] arm64/mm: move {idmap_pg_dir,tramp_pg_dir,swapper_pg_dir} " Jun Yao
2018-06-21 17:04             ` James Morse
2018-06-21 17:04               ` James Morse
2018-06-21 17:27               ` Ard Biesheuvel
2018-06-21 17:27                 ` [PATCH 1/1] arm64/mm: move {idmap_pg_dir, tramp_pg_dir, swapper_pg_dir} " Ard Biesheuvel
2018-06-22  8:15                 ` [PATCH 1/1] arm64/mm: move {idmap_pg_dir,tramp_pg_dir,swapper_pg_dir} " Jun Yao
2018-06-22  8:15                   ` Jun Yao

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=20180621122436.GA19014@toy \
    --to=yaojun8558363@gmail.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.