[PATCH v8 07/11] KVM: arm64: Enable writable for ID_AA64PFR0_EL1

[Marc Zyngier]

On Mon, 07 Aug 2023 17:22:05 +0100,
Jing Zhang <jingzhangos at google.com> wrote:
> 
> All valid fields in ID_AA64PFR0_EL1 are writable from usrespace
> with this change.

userspace

> 
> Signed-off-by: Jing Zhang <jingzhangos at google.com>
> ---
>  arch/arm64/kvm/sys_regs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 879004fd37e5..392613bec560 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2041,7 +2041,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>  	  .get_user = get_id_reg,
>  	  .set_user = set_id_reg,
>  	  .reset = read_sanitised_id_aa64pfr0_el1,
> -	  .val = ID_AA64PFR0_EL1_CSV2_MASK | ID_AA64PFR0_EL1_CSV3_MASK, },
> +	  .val = GENMASK(63, 0), },
>  	ID_SANITISED(ID_AA64PFR1_EL1),
>  	ID_UNALLOCATED(4,2),
>  	ID_UNALLOCATED(4,3),

Same remark as the previous patch. What makes it legal to make
*everything* writable? For example, we don't expose the AMU. And yet
you are telling userspace "sure, go ahead".

Userspace will then try and restore *something*, and will eventually
crap itself because the kernel won't allow it.

Why do we bother describing the writable fields if userspace can't
write to them?

	M.

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