[PATCH] arm64: kvm: Modernize annotation for __bp_harden_hyp_vecs

[PATCH] arm64: kvm: Modernize annotation for __bp_harden_hyp_vecs

[Mark Brown]

We have recently introduced new macros for annotating assembly symbols
for things that aren't C functions, SYM_CODE_START() and SYM_CODE_END(),
in an effort to clarify and simplify our annotations of assembly files.

Using these for __bp_harden_hyp_vecs is more involved than for most symbols
as this symbol is annotated quite unusually as rather than just have the
explicit symbol we define _start and _end symbols which we then use to
compute the length. This does not play at all nicely with the new style
macros. Since the size of the vectors is a known constant which won't vary
the simplest thing to do is simply to drop the separate _start and _end
symbols and just use a #define for the size.

Ideally we would have a build time assert to make sure we got this right
but we don't have such a thing for assembly code and given how unlikely
the size is to change it seems disproportionately difficult to write one
just for this.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/kvm_mmu.h | 9 ++++-----
 arch/arm64/include/asm/mmu.h     | 5 ++++-
 arch/arm64/kernel/cpu_errata.c   | 2 +-
 arch/arm64/kvm/hyp/hyp-entry.S   | 4 ++--
 4 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 53d846f1bfe7..b5f723cf9599 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -480,7 +480,7 @@ static inline void *kvm_get_hyp_vector(void)
 	int slot = -1;
 
 	if (cpus_have_const_cap(ARM64_HARDEN_BRANCH_PREDICTOR) && data->fn) {
-		vect = kern_hyp_va(kvm_ksym_ref(__bp_harden_hyp_vecs_start));
+		vect = kern_hyp_va(kvm_ksym_ref(__bp_harden_hyp_vecs));
 		slot = data->hyp_vectors_slot;
 	}
 
@@ -509,14 +509,13 @@ static inline int kvm_map_vectors(void)
 	 *  HBP +  HEL2 -> use hardened vertors and use exec mapping
 	 */
 	if (cpus_have_const_cap(ARM64_HARDEN_BRANCH_PREDICTOR)) {
-		__kvm_bp_vect_base = kvm_ksym_ref(__bp_harden_hyp_vecs_start);
+		__kvm_bp_vect_base = kvm_ksym_ref(__bp_harden_hyp_vecs);
 		__kvm_bp_vect_base = kern_hyp_va(__kvm_bp_vect_base);
 	}
 
 	if (cpus_have_const_cap(ARM64_HARDEN_EL2_VECTORS)) {
-		phys_addr_t vect_pa = __pa_symbol(__bp_harden_hyp_vecs_start);
-		unsigned long size = (__bp_harden_hyp_vecs_end -
-				      __bp_harden_hyp_vecs_start);
+		phys_addr_t vect_pa = __pa_symbol(__bp_harden_hyp_vecs);
+		unsigned long size = __BP_HARDEN_HYP_VECS_SZ;
 
 		/*
 		 * Always allocate a spare vector slot, as we don't
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index e4d862420bb4..c6e811767a12 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -45,7 +45,10 @@ struct bp_hardening_data {
 
 #if (defined(CONFIG_HARDEN_BRANCH_PREDICTOR) ||	\
      defined(CONFIG_HARDEN_EL2_VECTORS))
-extern char __bp_harden_hyp_vecs_start[], __bp_harden_hyp_vecs_end[];
+
+#define __BP_HARDEN_HYP_VECS_SZ (BP_HARDEN_EL2_SLOTS * SZ_2K)
+
+extern char __bp_harden_hyp_vecs[];
 extern atomic_t arm64_el2_vector_last_slot;
 #endif  /* CONFIG_HARDEN_BRANCH_PREDICTOR || CONFIG_HARDEN_EL2_VECTORS */
 
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 703ad0a84f99..0af2201cefda 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -119,7 +119,7 @@ extern char __smccc_workaround_1_smc_end[];
 static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start,
 				const char *hyp_vecs_end)
 {
-	void *dst = lm_alias(__bp_harden_hyp_vecs_start + slot * SZ_2K);
+	void *dst = lm_alias(__bp_harden_hyp_vecs + slot * SZ_2K);
 	int i;
 
 	for (i = 0; i < SZ_2K; i += 0x80)
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index 0aea8f9ab23d..8976276685a1 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -312,11 +312,11 @@ alternative_cb_end
 .endm
 
 	.align	11
-ENTRY(__bp_harden_hyp_vecs_start)
+SYM_CODE_START(__bp_harden_hyp_vecs)
 	.rept BP_HARDEN_EL2_SLOTS
 	generate_vectors
 	.endr
-ENTRY(__bp_harden_hyp_vecs_end)
+SYM_CODE_END(__bp_harden_hyp_vecs)
 
 	.popsection
 
-- 
2.20.1


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

Re: [PATCH] arm64: kvm: Modernize annotation for __bp_harden_hyp_vecs

[Marc Zyngier]

Mark,

I'd really appreciate it if you could send these as a series, instead of
an isolated patch every other day.

On 2020-02-18 12:44, Mark Brown wrote:
> We have recently introduced new macros for annotating assembly symbols
> for things that aren't C functions, SYM_CODE_START() and 
> SYM_CODE_END(),
> in an effort to clarify and simplify our annotations of assembly files.
> 
> Using these for __bp_harden_hyp_vecs is more involved than for most 
> symbols
> as this symbol is annotated quite unusually as rather than just have 
> the
> explicit symbol we define _start and _end symbols which we then use to
> compute the length. This does not play at all nicely with the new style
> macros. Since the size of the vectors is a known constant which won't 
> vary
> the simplest thing to do is simply to drop the separate _start and _end
> symbols and just use a #define for the size.
> 
> Ideally we would have a build time assert to make sure we got this 
> right
> but we don't have such a thing for assembly code and given how unlikely
> the size is to change it seems disproportionately difficult to write 
> one
> just for this.

Actually, we do have a pretty easy way to ensure this, see below.

[...]

> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S 
> b/arch/arm64/kvm/hyp/hyp-entry.S
> index 0aea8f9ab23d..8976276685a1 100644
> --- a/arch/arm64/kvm/hyp/hyp-entry.S
> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
> @@ -312,11 +312,11 @@ alternative_cb_end
>  .endm
> 
>  	.align	11
> -ENTRY(__bp_harden_hyp_vecs_start)
> +SYM_CODE_START(__bp_harden_hyp_vecs)
>  	.rept BP_HARDEN_EL2_SLOTS
>  	generate_vectors
>  	.endr

1:      .org __bp_harden_hyp_vecs + __BP_HARDEN_HYP_VECS_SZ
         .org 1b

If you got it wrong one way or another, the assembler will scream
about the origin going backward. See eb7c11ee3c5 for details.

         M.
-- 
Jazz is not dead. It just smells funny...

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

Re: [PATCH] arm64: kvm: Modernize annotation for __bp_harden_hyp_vecs

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 570 bytes --]

On Tue, Feb 18, 2020 at 12:56:52PM +0000, Marc Zyngier wrote:

> I'd really appreciate it if you could send these as a series, instead of
> an isolated patch every other day.

OK, I can do that for the KVM stuff - I've been actively trying to keep
the patches separate where there's no dependencies between them as it
avoids things getting caught up in review for more complicated stuff or
cases where someone decides they want extra cleanup while we're at it
which is especially useful when only some of the series is needed for
building on top of as is the case here.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

Re: [PATCH] arm64: kvm: Modernize annotation for __bp_harden_hyp_vecs

[Will Deacon]

On Tue, Feb 18, 2020 at 12:56:52PM +0000, Marc Zyngier wrote:
> I'd really appreciate it if you could send these as a series, instead of
> an isolated patch every other day.

Same for the non-KVM parts, please :)

I *think* the current ones to track are:

[PATCH v2] arm64: sdei: Annotate SDEI entry points using new style annotat
[PATCH 1/2] arm64: crypto: Modernize some extra assembly annotations
[PATCH 2/2] arm64: crypto: Modernize names for AES function macros
[PATCH] arm64: entry: Annotate ret_from_fork as code
[PATCH] arm64: head: Annotate stext and preserve_boot_args as code
[PATCH 1/3] arm64: entry-ftrace.S: Convert to modern annotations for assem
[PATCH 2/3] arm64: ftrace: Correct annotation of ftrace_caller assembly
[PATCH 3/3] arm64: ftrace: Modernise annotation of return_to_handler
[PATCH] arm64: vdso: Convert to modern assembler annotations
[PATCH] arm64: vdso32: Convert to modern assembler annotations
[PATCH] arm64: entry: Annotate vector table and handlers as code
[PATCH] arm64: head.S: Convert to modern annotations for assembly function
[PATCH] arm64: kernel: Convert to modern annotations for assembly data
[PATCH] arm64: kernel: Convert to modern annotations for assembly function
[PATCH] arm64: entry: Additional annotation conversions for entry.S
[PATCH v2] arm64: kvm: Annotate assembly using modern annoations
[PATCH v6 00/11] arm64: Branch Target Identification support
[PATCH] arm64: kvm: Modernize annotation for __bp_harden_hyp_vecs

but it's a bit much to follow, especially as there are three trees
involved in the above!

Will

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

Re: [PATCH] arm64: kvm: Modernize annotation for __bp_harden_hyp_vecs

[Will Deacon]

On Tue, Feb 18, 2020 at 01:06:19PM +0000, Mark Brown wrote:
> On Tue, Feb 18, 2020 at 12:56:52PM +0000, Marc Zyngier wrote:
> 
> > I'd really appreciate it if you could send these as a series, instead of
> > an isolated patch every other day.
> 
> OK, I can do that for the KVM stuff - I've been actively trying to keep
> the patches separate where there's no dependencies between them as it
> avoids things getting caught up in review for more complicated stuff or
> cases where someone decides they want extra cleanup while we're at it
> which is especially useful when only some of the series is needed for
> building on top of as is the case here.

I get what you're saying, but I still it find it much easier to get a
series of independent but functionally-related patches with a cover letter.
I usually end up cherry-picking the ones that are ready to go, so then
there's no need to respin those.

Obviously, individual patches are still fine, I'm just worried I'll end
up missing something because they're harder to keep track of.

Will

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

Re: [PATCH] arm64: kvm: Modernize annotation for __bp_harden_hyp_vecs

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 975 bytes --]

On Tue, Feb 18, 2020 at 01:09:53PM +0000, Will Deacon wrote:
> On Tue, Feb 18, 2020 at 12:56:52PM +0000, Marc Zyngier wrote:
> > I'd really appreciate it if you could send these as a series, instead of
> > an isolated patch every other day.

> Same for the non-KVM parts, please :)

Ugh, right.  As one series or as different serieses for the different
trees that apply things (eg, KVM and crypto)?  The multi tree stuff
worries me.

> I *think* the current ones to track are:

Yes, apart from:

> [PATCH v6 00/11] arm64: Branch Target Identification support

The BTI stuff is unrelated at this point, the annotations are only
needed for in kernel BTI which I've not posted yet, it also depends on
the in kernel pointer authentication stuff so I was waiting for that to
settle down before I finish off the in kernel bits and post them.
Pulling it into the series with the asm stuff would result in a very big
series with an absurdly large CC list which doesn't seem helpful.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

Re: [PATCH] arm64: kvm: Modernize annotation for __bp_harden_hyp_vecs

[Marc Zyngier]

On 2020-02-18 13:29, Mark Brown wrote:
> On Tue, Feb 18, 2020 at 01:09:53PM +0000, Will Deacon wrote:
>> On Tue, Feb 18, 2020 at 12:56:52PM +0000, Marc Zyngier wrote:
>> > I'd really appreciate it if you could send these as a series, instead of
>> > an isolated patch every other day.
> 
>> Same for the non-KVM parts, please :)
> 
> Ugh, right.  As one series or as different serieses for the different
> trees that apply things (eg, KVM and crypto)?  The multi tree stuff
> worries me.

Up to you. I personally think it is useful to see the whole thing for 
arm64
as a single series, and we can then decide who picks what between 
ourselves
(or shove the whole thing via a single tree).

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

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

Re: [PATCH] arm64: kvm: Modernize annotation for __bp_harden_hyp_vecs

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 916 bytes --]

On Tue, Feb 18, 2020 at 01:14:37PM +0000, Will Deacon wrote:
> On Tue, Feb 18, 2020 at 01:06:19PM +0000, Mark Brown wrote:

> > OK, I can do that for the KVM stuff - I've been actively trying to keep
> > the patches separate where there's no dependencies between them as it
> > avoids things getting caught up in review for more complicated stuff or
> > cases where someone decides they want extra cleanup while we're at it
> > which is especially useful when only some of the series is needed for
> > building on top of as is the case here.

> I get what you're saying, but I still it find it much easier to get a
> series of independent but functionally-related patches with a cover letter.
> I usually end up cherry-picking the ones that are ready to go, so then
> there's no need to respin those.

I see - I'd not seen that happening with the arch/arm64 stuff, more the
opposite, so I was working on that basis.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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