All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Ard Biesheuvel <ardb@google.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Ard Biesheuvel <ardb@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v5 15/39] arm64: idreg-override: Prepare for place relative reloc patching
Date: Mon, 27 Nov 2023 12:53:46 +0000	[thread overview]
Message-ID: <86edgbcq79.wl-maz@kernel.org> (raw)
In-Reply-To: <20231124101840.944737-56-ardb@google.com>

On Fri, 24 Nov 2023 10:18:55 +0000,
Ard Biesheuvel <ardb@google.com> wrote:
> 
> From: Ard Biesheuvel <ardb@kernel.org>
> 
> The ID reg override handling code uses a rather elaborate data structure
> that relies on statically initialized absolute address values in pointer
> fields. This means that this code cannot run until relocation fixups
> have been applied, and this is unfortunate, because it means we cannot
> discover overrides for KASLR or LVA/LPA without creating the kernel
> mapping and performing the relocations first.
> 
> This can be solved by switching to place-relative relocations, which can
> be applied by the linker at build time. This means some additional
> arithmetic is required when dereferencing these pointers, as we can no
> longer dereference the pointer members directly.
> 
> So let's implement this for idreg-override.c in a preliminary way, i.e.,
> convert all the references in code to use a special accessor that
> produces the correct absolute value at runtime.
> 
> To preserve the strong type checking for the static initializers, use
> union types for representing the hybrid quantities.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  arch/arm64/kernel/idreg-override.c | 98 +++++++++++++-------
>  1 file changed, 65 insertions(+), 33 deletions(-)
> 
> diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
> index 536bc33859bc..4e32a44560bf 100644
> --- a/arch/arm64/kernel/idreg-override.c
> +++ b/arch/arm64/kernel/idreg-override.c
> @@ -21,14 +21,32 @@
>  
>  static u64 __boot_status __initdata;
>  
> +// temporary __prel64 related definitions
> +// to be removed when this code is moved under pi/
> +
> +#define __prel64_initconst	__initconst
> +
> +typedef void *prel64_t;
> +
> +static void *prel64_to_pointer(const prel64_t *p)
> +{
> +	return *p;
> +}
> +

Having played with this series a bit to see how the E2H0 override
support would fit in, I found that this cast to a void* could hide
stupid bugs that should normally be caught at compile time.

Having hacked on it a bit, I came up with this (partial patch on top
of the full series):

diff --git a/arch/arm64/kernel/pi/idreg-override.c b/arch/arm64/kernel/pi/idreg-override.c
index 84647ebb87ee..d60322477e44 100644
--- a/arch/arm64/kernel/pi/idreg-override.c
+++ b/arch/arm64/kernel/pi/idreg-override.c
@@ -246,12 +246,12 @@ static void __init match_options(const char *cmdline)
 	int i;
 
 	for (i = 0; i < ARRAY_SIZE(regs); i++) {
-		const struct ftr_set_desc *reg = prel64_to_pointer(&regs[i].reg_prel);
+		const struct ftr_set_desc *reg = prel64_pointer(regs[i].reg);
 		struct arm64_ftr_override *override;
 		int len = strlen(reg->name);
 		int f;
 
-		override = prel64_to_pointer(&reg->override_prel);
+		override = prel64_pointer(reg->override);
 
 		// set opt[] to '<name>.'
 		memcpy(opt, reg->name, len);
diff --git a/arch/arm64/kernel/pi/pi.h b/arch/arm64/kernel/pi/pi.h
index 04a1f576baee..9d922322999b 100644
--- a/arch/arm64/kernel/pi/pi.h
+++ b/arch/arm64/kernel/pi/pi.h
@@ -15,6 +15,8 @@ static inline void *prel64_to_pointer(const prel64_t *offset)
 	return (void *)offset + *offset;
 }
 
+#define prel64_pointer(__d)	(typeof(__d))prel64_to_pointer(&__d##_prel)
+
 extern bool dynamic_scs_is_enabled;
 
 extern pgd_t init_idmap_pg_dir[];


which preserves the type-checking, at the expense of the implicit
*_prel field access. Not sure if that's something you have considered,
but I thought I'd raise it here.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-11-27 12:54 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-24 10:18 [PATCH v5 00/39] arm64: Reorganize kernel VA space for LPA2 Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 01/39] arm64: kernel: Disable latent_entropy GCC plugin in early C runtime Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 02/39] arm64: mm: Take potential load offset into account when KASLR is off Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 03/39] arm64: mm: get rid of kimage_vaddr global variable Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 04/39] arm64: mm: Move PCI I/O emulation region above the vmemmap region Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 05/39] arm64: mm: Move fixmap region above " Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 06/39] arm64: ptdump: Allow all region boundaries to be defined at boot time Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 07/39] arm64: ptdump: Discover start of vmemmap region at runtime Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 08/39] arm64: vmemmap: Avoid base2 order of struct page size to dimension region Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 09/39] arm64: mm: Reclaim unused vmemmap region for vmalloc use Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 10/39] arm64: kaslr: Adjust randomization range dynamically Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 11/39] arm64: kernel: Manage absolute relocations in code built under pi/ Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 12/39] arm64: kernel: Don't rely on objcopy to make code under pi/ __init Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 13/39] arm64: head: move relocation handling to C code Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 14/39] arm64: idreg-override: Omit non-NULL checks for override pointer Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 15/39] arm64: idreg-override: Prepare for place relative reloc patching Ard Biesheuvel
2023-11-27 12:53   ` Marc Zyngier [this message]
2023-11-27 12:58     ` Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 16/39] arm64: idreg-override: Avoid parameq() and parameqn() Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 17/39] arm64: idreg-override: avoid strlen() to check for empty strings Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 18/39] arm64: idreg-override: Avoid sprintf() for simple string concatenation Ard Biesheuvel
2023-11-24 10:18 ` [PATCH v5 19/39] arm64: idreg-override: Avoid kstrtou64() to parse a single hex digit Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 20/39] arm64: idreg-override: Move to early mini C runtime Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 21/39] arm64: kernel: Remove early fdt remap code Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 22/39] arm64: head: Clear BSS and the kernel page tables in one go Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 23/39] arm64: Move feature overrides into the BSS section Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 24/39] arm64: head: Run feature override detection before mapping the kernel Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 25/39] arm64: head: move dynamic shadow call stack patching into early C runtime Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 26/39] arm64: kaslr: Use feature override instead of parsing the cmdline again Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 27/39] arm64/kernel: Move 'nokaslr' parsing out of early idreg code Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 28/39] arm64: idreg-override: Create a pseudo feature for rodata=off Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 29/39] arm64: Add helpers to probe local CPU for PAC and BTI support Ard Biesheuvel
2023-11-24 12:37   ` Marc Zyngier
2023-11-24 13:08     ` Ard Biesheuvel
2023-11-24 13:48       ` Marc Zyngier
2023-11-25  8:59         ` Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 30/39] arm64: head: allocate more pages for the kernel mapping Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 31/39] arm64: head: move memstart_offset_seed handling to C code Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 32/39] arm64: mm: Make kaslr_requires_kpti() a static inline Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 33/39] arm64: head: Move early kernel mapping routines into C code Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 34/39] arm64: mm: Use 48-bit virtual addressing for the permanent ID map Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 35/39] arm64: pgtable: Decouple PGDIR size macros from PGD/PUD/PMD levels Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 36/39] arm64: kernel: Create initial ID map from C code Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 37/39] arm64: mm: avoid fixmap for early swapper_pg_dir updates Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 38/39] arm64: mm: omit redundant remap of kernel image Ard Biesheuvel
2023-11-24 10:19 ` [PATCH v5 39/39] arm64: Revert "mm: provide idmap pointer to cpu_replace_ttbr1()" Ard Biesheuvel
2023-11-24 16:22 ` [PATCH v5 00/39] arm64: Reorganize kernel VA space for LPA2 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=86edgbcq79.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@google.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=ryan.roberts@arm.com \
    --cc=will@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 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.