arm64: kaslr: Check command line before looking for a seed

mainline inclusion
from mainline-v5.4-rc3
commit 2203e1ad
category:feature
bugzilla:NA
CVE:NA

--------------------------------

Now that we print diagnostics at boot the reason why we do not initialise
KASLR matters. Currently we check for a seed before we check if the user
has explicitly disabled KASLR on the command line which will result in
misleading diagnostics so reverse the order of those checks. We still
parse the seed from the DT early so that if the user has both provided a
seed and disabled KASLR on the command line we still mask the seed on
the command line.
Signed-off-by: NMark Brown <broonie@kernel.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

arch/arm64/kernel/kaslr.c

@@ -29,7 +29,7 @@ enum kaslr_status {
 	KASLR_DISABLED_FDT_REMAP,
 };
 
-enum kaslr_status __ro_after_init kaslr_status;
+static enum kaslr_status __initdata kaslr_status;
 u64 __ro_after_init module_alloc_base;
 u16 __initdata memstart_offset_seed;
 
@@ -114,10 +114,6 @@ u64 __init kaslr_early_init(u64 dt_phys)
 	 * Retrieve (and wipe) the seed from the FDT
 	 */
 	seed = get_kaslr_seed(fdt);
-	if (!seed) {
-		kaslr_status = KASLR_DISABLED_NO_SEED;
-		return 0;
-	}
 
 	/*
 	 * Check if 'nokaslr' appears on the command line, and
@@ -130,6 +126,11 @@ u64 __init kaslr_early_init(u64 dt_phys)
 		return 0;
 	}
 
+	if (!seed) {
+		kaslr_status = KASLR_DISABLED_NO_SEED;
+		return 0;
+	}
+
 	/*
 	 * OK, so we are proceeding with KASLR enabled. Calculate a suitable
 	 * kernel image offset from the seed. Let's place the kernel in the