[PATCH 2/2] powerpc/prom_init: Pass linux_banner to firmware via option vector 7

[Tyrel Datwyler]

On 6/20/21 11:49 PM, Michael Ellerman wrote:
> Pass the value of linux_banner to firmware via option vector 7.
> 
> Option vector 7 is described in "LoPAR" Linux on Power Architecture
> Reference v2.9, in table B.7 on page 824:
> 
>   An ASCII character formatted null terminated string that describes
>   the client operating system. The string shall be human readable and
>   may be displayed on the console.
> 
> The string can be up to 256 bytes total, including the nul terminator.
> 
> linux_banner contains lots of information, and should make it possible
> to identify the exact kernel version that is running:
> 
>   const char linux_banner[] =
>   "Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
>   LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
> 
> For example:
>   Linux version 4.15.0-144-generic (buildd at bos02-ppc64el-018) (gcc
>   version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #148-Ubuntu SMP Sat May 8
>   02:32:13 UTC 2021 (Ubuntu 4.15.0-144.148-generic 4.15.18)
> 
> It's also printed at boot to the console/dmesg, which should make it
> possible to correlate what firmware receives with the console/dmesg on
> the machine.
> 
> Signed-off-by: Michael Ellerman <mpe at ellerman.id.au>
> ---
> 
> NB. linux_banner is already allowed by prom_init_check.sh
> 
> LoPAR: https://openpowerfoundation.org/?resource_lib=linux-on-power-architecture-reference-a-papr-linux-subset-review-draft
> ---
>  arch/powerpc/kernel/prom_init.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index c18d55f8b951..7343076b261c 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -27,6 +27,7 @@
>  #include <linux/initrd.h>
>  #include <linux/bitops.h>
>  #include <linux/pgtable.h>
> +#include <linux/printk.h>
>  #include <asm/prom.h>
>  #include <asm/rtas.h>
>  #include <asm/page.h>
> @@ -944,6 +945,10 @@ struct option_vector6 {
>  	u8 os_name;
>  } __packed;
> 
> +struct option_vector7 {
> +	u8 os_id[256];
> +} __packed;
> +
>  struct ibm_arch_vec {
>  	struct { u32 mask, val; } pvrs[14];
> 
> @@ -966,6 +971,9 @@ struct ibm_arch_vec {
> 
>  	u8 vec6_len;
>  	struct option_vector6 vec6;
> +
> +	u8 vec7_len;
> +	struct option_vector7 vec7;
>  } __packed;
> 
>  static const struct ibm_arch_vec ibm_architecture_vec_template __initconst = {
> @@ -1112,6 +1120,9 @@ static const struct ibm_arch_vec ibm_architecture_vec_template __initconst = {
>  		.secondary_pteg = 0,
>  		.os_name = OV6_LINUX,
>  	},
> +
> +	/* option vector 7: OS Identification */
> +	.vec7_len = VECTOR_LENGTH(sizeof(struct option_vector7)),
>  };
> 
>  static struct ibm_arch_vec __prombss ibm_architecture_vec  ____cacheline_aligned;
> @@ -1340,6 +1351,10 @@ static void __init prom_check_platform_support(void)
>  	memcpy(&ibm_architecture_vec, &ibm_architecture_vec_template,
>  	       sizeof(ibm_architecture_vec));
> 
> +	prom_strscpy_pad(ibm_architecture_vec.vec7.os_id, linux_banner, 256);
> +	// Ensure nul termination
> +	ibm_architecture_vec.vec7.os_id[255] = '\0';
> +

Doesn't the implementation of prom_strscpy_pad() in patch 1 ensure nul termination?

-Tyrel

>  	if (prop_len > 1) {
>  		int i;
>  		u8 vec[8];
>