From: Mark Rutland <mark.rutland@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
kernel-hardening@lists.openwall.com,
Will Deacon <will.deacon@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Leif Lindholm <leif.lindholm@linaro.org>,
Kees Cook <keescook@chromium.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Stuart Yoder <stuart.yoder@freescale.com>,
Sharma Bhupesh <bhupesh.sharma@freescale.com>,
Arnd Bergmann <arnd@arndb.de>,
Marc Zyngier <marc.zyngier@arm.com>,
Christoffer Dall <christoffer.dall@linaro.org>
Subject: [kernel-hardening] Re: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere in physical memory
Date: Fri, 8 Jan 2016 11:43:25 +0000 [thread overview]
Message-ID: <20160108114324.GB3097@leverpostej> (raw)
In-Reply-To: <CAKv+Gu8uGyoxvR0zYyrXiGTg5F4kO9p3Jbr-EZAozHYQS68T8w@mail.gmail.com>
On Fri, Jan 08, 2016 at 12:34:18PM +0100, Ard Biesheuvel wrote:
> On 8 January 2016 at 12:26, Mark Rutland <mark.rutland@arm.com> wrote:
> > We might also want to consider if we need to determine whether or not
> > the bootloader actually provided entropy, (and if we need a more general
> > handshake between the bootlaoder and kernel to determine that kind of
> > thing).
>
> Yes, that is interesting. We should also think about how to handle
> 'nokaslr' if it appears on the command line, since in the !EFI case,
> we will be way too late to parse this, and a capable kernel will
> already be running from a randomized offset. That means it is the
> bootloader's responsibility to ensure that the presence of 'nokaslr'
> and the entropy in x1 are consistent with each other.
Argh, I hadn't considered that. :(
In the absence of a pre-kernel environment, the best thing we can do is
probably to print a giant warning if 'nokaslr' is present but there was
entropy (where that's determined based on some handshake/magic/flag).
> >> Any memory described to the kernel (even that below the start of the
> >> image) which is not marked as reserved from the kernel (e.g., with a
> >> diff --git a/arch/arm64/include/asm/boot.h b/arch/arm64/include/asm/boot.h
> >> index 81151b67b26b..984cb0fa61ce 100644
> >> --- a/arch/arm64/include/asm/boot.h
> >> +++ b/arch/arm64/include/asm/boot.h
> >> @@ -11,4 +11,9 @@
> >> #define MIN_FDT_ALIGN 8
> >> #define MAX_FDT_SIZE SZ_2M
> >>
> >> +/*
> >> + * arm64 requires the kernel image to be 2 MB aligned
> >
> > Nit: The image is TEXT_OFFSET from that 2M-aligned base.
> > s/image/mapping/?
> >
> > [...]
> >
>
> Yep. I hate TEXT_OFFSET, did I mention that?
I would also love to remove it, but I believe it's simply too late. :(
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere in physical memory
Date: Fri, 8 Jan 2016 11:43:25 +0000 [thread overview]
Message-ID: <20160108114324.GB3097@leverpostej> (raw)
In-Reply-To: <CAKv+Gu8uGyoxvR0zYyrXiGTg5F4kO9p3Jbr-EZAozHYQS68T8w@mail.gmail.com>
On Fri, Jan 08, 2016 at 12:34:18PM +0100, Ard Biesheuvel wrote:
> On 8 January 2016 at 12:26, Mark Rutland <mark.rutland@arm.com> wrote:
> > We might also want to consider if we need to determine whether or not
> > the bootloader actually provided entropy, (and if we need a more general
> > handshake between the bootlaoder and kernel to determine that kind of
> > thing).
>
> Yes, that is interesting. We should also think about how to handle
> 'nokaslr' if it appears on the command line, since in the !EFI case,
> we will be way too late to parse this, and a capable kernel will
> already be running from a randomized offset. That means it is the
> bootloader's responsibility to ensure that the presence of 'nokaslr'
> and the entropy in x1 are consistent with each other.
Argh, I hadn't considered that. :(
In the absence of a pre-kernel environment, the best thing we can do is
probably to print a giant warning if 'nokaslr' is present but there was
entropy (where that's determined based on some handshake/magic/flag).
> >> Any memory described to the kernel (even that below the start of the
> >> image) which is not marked as reserved from the kernel (e.g., with a
> >> diff --git a/arch/arm64/include/asm/boot.h b/arch/arm64/include/asm/boot.h
> >> index 81151b67b26b..984cb0fa61ce 100644
> >> --- a/arch/arm64/include/asm/boot.h
> >> +++ b/arch/arm64/include/asm/boot.h
> >> @@ -11,4 +11,9 @@
> >> #define MIN_FDT_ALIGN 8
> >> #define MAX_FDT_SIZE SZ_2M
> >>
> >> +/*
> >> + * arm64 requires the kernel image to be 2 MB aligned
> >
> > Nit: The image is TEXT_OFFSET from that 2M-aligned base.
> > s/image/mapping/?
> >
> > [...]
> >
>
> Yep. I hate TEXT_OFFSET, did I mention that?
I would also love to remove it, but I believe it's simply too late. :(
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
kernel-hardening@lists.openwall.com,
Will Deacon <will.deacon@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Leif Lindholm <leif.lindholm@linaro.org>,
Kees Cook <keescook@chromium.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Stuart Yoder <stuart.yoder@freescale.com>,
Sharma Bhupesh <bhupesh.sharma@freescale.com>,
Arnd Bergmann <arnd@arndb.de>,
Marc Zyngier <marc.zyngier@arm.com>,
Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere in physical memory
Date: Fri, 8 Jan 2016 11:43:25 +0000 [thread overview]
Message-ID: <20160108114324.GB3097@leverpostej> (raw)
In-Reply-To: <CAKv+Gu8uGyoxvR0zYyrXiGTg5F4kO9p3Jbr-EZAozHYQS68T8w@mail.gmail.com>
On Fri, Jan 08, 2016 at 12:34:18PM +0100, Ard Biesheuvel wrote:
> On 8 January 2016 at 12:26, Mark Rutland <mark.rutland@arm.com> wrote:
> > We might also want to consider if we need to determine whether or not
> > the bootloader actually provided entropy, (and if we need a more general
> > handshake between the bootlaoder and kernel to determine that kind of
> > thing).
>
> Yes, that is interesting. We should also think about how to handle
> 'nokaslr' if it appears on the command line, since in the !EFI case,
> we will be way too late to parse this, and a capable kernel will
> already be running from a randomized offset. That means it is the
> bootloader's responsibility to ensure that the presence of 'nokaslr'
> and the entropy in x1 are consistent with each other.
Argh, I hadn't considered that. :(
In the absence of a pre-kernel environment, the best thing we can do is
probably to print a giant warning if 'nokaslr' is present but there was
entropy (where that's determined based on some handshake/magic/flag).
> >> Any memory described to the kernel (even that below the start of the
> >> image) which is not marked as reserved from the kernel (e.g., with a
> >> diff --git a/arch/arm64/include/asm/boot.h b/arch/arm64/include/asm/boot.h
> >> index 81151b67b26b..984cb0fa61ce 100644
> >> --- a/arch/arm64/include/asm/boot.h
> >> +++ b/arch/arm64/include/asm/boot.h
> >> @@ -11,4 +11,9 @@
> >> #define MIN_FDT_ALIGN 8
> >> #define MAX_FDT_SIZE SZ_2M
> >>
> >> +/*
> >> + * arm64 requires the kernel image to be 2 MB aligned
> >
> > Nit: The image is TEXT_OFFSET from that 2M-aligned base.
> > s/image/mapping/?
> >
> > [...]
> >
>
> Yep. I hate TEXT_OFFSET, did I mention that?
I would also love to remove it, but I believe it's simply too late. :(
Thanks,
Mark.
next prev parent reply other threads:[~2016-01-08 11:43 UTC|newest]
Thread overview: 156+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-30 15:25 [kernel-hardening] [PATCH v2 00/13] arm64: implement support for KASLR Ard Biesheuvel
2015-12-30 15:25 ` Ard Biesheuvel
2015-12-30 15:25 ` Ard Biesheuvel
2015-12-30 15:26 ` [kernel-hardening] [PATCH v2 01/13] of/fdt: make memblock minimum physical address arch configurable Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` [kernel-hardening] [PATCH v2 02/13] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2016-01-05 14:36 ` [kernel-hardening] " Christoffer Dall
2016-01-05 14:36 ` Christoffer Dall
2016-01-05 14:36 ` Christoffer Dall
2016-01-05 14:46 ` [kernel-hardening] " Mark Rutland
2016-01-05 14:46 ` Mark Rutland
2016-01-05 14:46 ` Mark Rutland
2016-01-05 14:58 ` [kernel-hardening] " Christoffer Dall
2016-01-05 14:58 ` Christoffer Dall
2016-01-05 14:58 ` Christoffer Dall
2015-12-30 15:26 ` [kernel-hardening] [PATCH v2 03/13] arm64: use more granular reservations for static page table allocations Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2016-01-07 13:55 ` [kernel-hardening] " Mark Rutland
2016-01-07 13:55 ` Mark Rutland
2016-01-07 13:55 ` Mark Rutland
2016-01-07 14:02 ` [kernel-hardening] " Ard Biesheuvel
2016-01-07 14:02 ` Ard Biesheuvel
2016-01-07 14:02 ` Ard Biesheuvel
2016-01-07 14:25 ` [kernel-hardening] " Mark Rutland
2016-01-07 14:25 ` Mark Rutland
2016-01-07 14:25 ` Mark Rutland
2015-12-30 15:26 ` [kernel-hardening] [PATCH v2 04/13] arm64: decouple early fixmap init from linear mapping Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2016-01-06 16:35 ` [kernel-hardening] " James Morse
2016-01-06 16:35 ` James Morse
2016-01-06 16:35 ` James Morse
2016-01-06 16:42 ` [kernel-hardening] " Ard Biesheuvel
2016-01-06 16:42 ` Ard Biesheuvel
2016-01-06 16:42 ` Ard Biesheuvel
2016-01-08 12:00 ` [kernel-hardening] " Catalin Marinas
2016-01-08 12:00 ` Catalin Marinas
2016-01-08 12:00 ` Catalin Marinas
2016-01-08 12:05 ` [kernel-hardening] " Ard Biesheuvel
2016-01-08 12:05 ` Ard Biesheuvel
2016-01-08 12:05 ` Ard Biesheuvel
2015-12-30 15:26 ` [kernel-hardening] [PATCH v2 05/13] arm64: kvm: deal with kernel symbols outside of " Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2016-01-04 10:08 ` [kernel-hardening] " Marc Zyngier
2016-01-04 10:08 ` Marc Zyngier
2016-01-04 10:08 ` Marc Zyngier
2016-01-04 10:31 ` [kernel-hardening] " Ard Biesheuvel
2016-01-04 10:31 ` Ard Biesheuvel
2016-01-04 10:31 ` Ard Biesheuvel
2016-01-04 11:02 ` [kernel-hardening] " Marc Zyngier
2016-01-04 11:02 ` Marc Zyngier
2016-01-04 11:02 ` Marc Zyngier
2016-01-05 14:41 ` [kernel-hardening] " Christoffer Dall
2016-01-05 14:41 ` Christoffer Dall
2016-01-05 14:41 ` Christoffer Dall
2016-01-05 14:51 ` [kernel-hardening] " Ard Biesheuvel
2016-01-05 14:51 ` Ard Biesheuvel
2016-01-05 14:51 ` Ard Biesheuvel
2016-01-05 14:56 ` [kernel-hardening] " Christoffer Dall
2016-01-05 14:56 ` Christoffer Dall
2016-01-05 14:56 ` Christoffer Dall
2015-12-30 15:26 ` [kernel-hardening] [PATCH v2 06/13] arm64: move kernel image to base of vmalloc area Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` [kernel-hardening] [PATCH v2 07/13] arm64: add support for module PLTs Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` [kernel-hardening] [PATCH v2 08/13] arm64: use relative references in exception tables Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` [kernel-hardening] [PATCH v2 09/13] arm64: avoid R_AARCH64_ABS64 relocations for Image header fields Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` [kernel-hardening] [PATCH v2 10/13] arm64: avoid dynamic relocations in early boot code Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` [kernel-hardening] [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere in physical memory Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2016-01-08 11:26 ` [kernel-hardening] " Mark Rutland
2016-01-08 11:26 ` Mark Rutland
2016-01-08 11:26 ` Mark Rutland
2016-01-08 11:34 ` [kernel-hardening] " Ard Biesheuvel
2016-01-08 11:34 ` Ard Biesheuvel
2016-01-08 11:34 ` Ard Biesheuvel
2016-01-08 11:43 ` Mark Rutland [this message]
2016-01-08 11:43 ` Mark Rutland
2016-01-08 11:43 ` Mark Rutland
2016-01-08 15:27 ` [kernel-hardening] " Catalin Marinas
2016-01-08 15:27 ` Catalin Marinas
2016-01-08 15:27 ` Catalin Marinas
2016-01-08 15:30 ` [kernel-hardening] " Ard Biesheuvel
2016-01-08 15:30 ` Ard Biesheuvel
2016-01-08 15:30 ` Ard Biesheuvel
2016-01-08 15:36 ` [kernel-hardening] " Mark Rutland
2016-01-08 15:36 ` Mark Rutland
2016-01-08 15:36 ` Mark Rutland
2016-01-08 15:48 ` [kernel-hardening] " Catalin Marinas
2016-01-08 15:48 ` Catalin Marinas
2016-01-08 15:48 ` Catalin Marinas
2016-01-08 16:14 ` [kernel-hardening] " Mark Rutland
2016-01-08 16:14 ` Mark Rutland
2016-01-08 16:14 ` Mark Rutland
2015-12-30 15:26 ` [kernel-hardening] [PATCH v2 12/13] arm64: add support for relocatable kernel Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2016-01-05 19:51 ` [kernel-hardening] " Kees Cook
2016-01-05 19:51 ` Kees Cook
2016-01-05 19:51 ` Kees Cook
2016-01-06 7:51 ` [kernel-hardening] " Ard Biesheuvel
2016-01-06 7:51 ` Ard Biesheuvel
2016-01-06 7:51 ` Ard Biesheuvel
2016-01-08 10:17 ` [kernel-hardening] " James Morse
2016-01-08 10:17 ` James Morse
2016-01-08 10:17 ` James Morse
2016-01-08 10:25 ` [kernel-hardening] " Ard Biesheuvel
2016-01-08 10:25 ` Ard Biesheuvel
2016-01-08 10:25 ` Ard Biesheuvel
2016-01-08 12:36 ` [kernel-hardening] " Mark Rutland
2016-01-08 12:36 ` Mark Rutland
2016-01-08 12:36 ` Mark Rutland
2016-01-08 12:38 ` [kernel-hardening] " Ard Biesheuvel
2016-01-08 12:38 ` Ard Biesheuvel
2016-01-08 12:38 ` Ard Biesheuvel
2016-01-08 12:40 ` [kernel-hardening] " Mark Rutland
2016-01-08 12:40 ` Mark Rutland
2016-01-08 12:40 ` Mark Rutland
2016-01-08 12:41 ` [PATCH] arm64: split elf relocs into a separate header Mark Rutland
2016-01-08 15:59 ` Will Deacon
2016-01-12 11:55 ` Ard Biesheuvel
2015-12-30 15:26 ` [kernel-hardening] [PATCH v2 13/13] arm64: efi: invoke EFI_RNG_PROTOCOL to supply KASLR randomness Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2015-12-30 15:26 ` Ard Biesheuvel
2016-01-05 19:53 ` [kernel-hardening] " Kees Cook
2016-01-05 19:53 ` Kees Cook
2016-01-05 19:53 ` Kees Cook
2016-01-06 7:51 ` [kernel-hardening] " Ard Biesheuvel
2016-01-06 7:51 ` Ard Biesheuvel
2016-01-06 7:51 ` Ard Biesheuvel
2016-01-07 18:46 ` [kernel-hardening] " Mark Rutland
2016-01-07 18:46 ` Mark Rutland
2016-01-07 18:46 ` Mark Rutland
2016-01-07 19:07 ` [kernel-hardening] " Kees Cook
2016-01-07 19:07 ` Kees Cook
2016-01-07 19:07 ` Kees Cook
2016-01-05 20:08 ` [kernel-hardening] Re: [PATCH v2 00/13] arm64: implement support for KASLR Kees Cook
2016-01-05 20:08 ` Kees Cook
2016-01-05 20:08 ` Kees Cook
2016-01-05 21:24 ` [kernel-hardening] " Ard Biesheuvel
2016-01-05 21:24 ` Ard Biesheuvel
2016-01-05 21:24 ` 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=20160108114324.GB3097@leverpostej \
--to=mark.rutland@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=bhupesh.sharma@freescale.com \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=leif.lindholm@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=stuart.yoder@freescale.com \
--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.