Re: [PATCH v2] s390/cpacf: Unpoison instruction results

Harald Freudenberger <[email protected]>
Newsgroups org.kernel.vger.linux-s390,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 2026-08-07 14:20, Ilya Leoshkevich wrote:
> Stop KMSAN from complaining about CPACF outputs being uninitialized.
> 
> Do not unpoison variable-length parameter blocks: mapping function
> codes (like CPACF_KIMD_SHA_256) to lengths is ugly. Let the callers
> handle this once need arises.
> 
> Signed-off-by: Ilya Leoshkevich <[email protected]>
> ---
> v1:
> https://lore.kernel.org/linux-s390/[email protected]/
> v1 -> v2: Unpoison outputs of more instructions (Sashiko).
> 

See my comment below.

>  arch/s390/include/asm/cpacf.h | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/s390/include/asm/cpacf.h 
> b/arch/s390/include/asm/cpacf.h
> index a83683169d98d..13d6a6344802a 100644
> --- a/arch/s390/include/asm/cpacf.h
> +++ b/arch/s390/include/asm/cpacf.h
> @@ -301,6 +301,7 @@ static __always_inline void __cpacf_query(unsigned
> int opcode,
>  					  cpacf_mask_t *mask)
>  {
>  	__cpacf_query_insn(opcode, mask, CPACF_FC_QUERY);
> +	kmsan_unpoison_memory(mask, sizeof(*mask));
>  }
> 
>  static __always_inline int __cpacf_check_opcode(unsigned int opcode)
> @@ -370,6 +371,7 @@ static __always_inline int
> cpacf_query_func(unsigned int opcode,
>  static __always_inline void __cpacf_qai(unsigned int opcode, 
> cpacf_qai_t *qai)
>  {
>  	__cpacf_query_insn(opcode, qai, CPACF_FC_QUERY_AUTH_INFO);
> +	kmsan_unpoison_memory(qai, sizeof(*qai));
>  }
> 
>  /**
> @@ -422,6 +424,7 @@ static inline int cpacf_km(unsigned long func, void 
> *param,
>  		  [opc] "i" (CPACF_KM)
>  		: "cc", "memory", "0", "1");
> 
> +	kmsan_unpoison_memory(dest, src_len - s.odd);
>  	return src_len - s.odd;
>  }
> 
> @@ -454,6 +457,7 @@ static inline int cpacf_kmc(unsigned long func, 
> void *param,
>  		  [opc] "i" (CPACF_KMC)
>  		: "cc", "memory", "0", "1");
> 
> +	kmsan_unpoison_memory(dest, src_len - s.odd);
>  	return src_len - s.odd;
>  }
> 
> @@ -587,6 +591,7 @@ static inline int cpacf_kmctr(unsigned long func,
> void *param, u8 *dest,
>  		  [opc] "i" (CPACF_KMCTR)
>  		: "cc", "memory", "0", "1");
> 
> +	kmsan_unpoison_memory(dest, src_len - s.odd);
>  	return src_len - s.odd;
>  }
> 
> @@ -619,6 +624,7 @@ static inline void cpacf_prno(unsigned long func,
> void *param,
>  		: [fc] "d" (func), [pba] "d" ((unsigned long)param),
>  		  [seed] "d" (s.pair), [opc] "i" (CPACF_PRNO)
>  		: "cc", "memory", "0", "1");
> +	kmsan_unpoison_memory(dest, dest_len);
>  }
> 
>  /**
> @@ -731,6 +737,7 @@ static inline void cpacf_kma(unsigned long func,
> void *param, u8 *dest,
>  		: [fc] "d" (func), [pba] "d" ((unsigned long)param),
>  		  [opc] "i" (CPACF_KMA)
>  		: "cc", "memory", "0", "1");
> +	kmsan_unpoison_memory(dest, src_len);

I am unhappy with this kma thing. This would only work properly with
CC 0. But CC 1 and 2 are not handled properly. However, I had a closer
look onto the AR for kma and ... well this inline function should
handle CC 1 and CC 2 somehow and it should similar to the other inline
functions return the number of bytes processed like for example 
cpacf_km().
I'll open up a bugzilla to fix this kma inline function.
If you leave out this kma hunk you can add my R-b.

>  }
> 
>  #endif	/* _ASM_S390_CPACF_H */
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.