linux-kernel - Re: [PATCH 0/4] KVM: fix KVM_EXIT_SYSTEM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ef5c6c5b-2ed1-7d4c-e757-ed8bcead5d18@redhat.com>
Date:   Fri, 22 Apr 2022 11:41:34 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Oliver Upton <oupton@...gle.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org, will@...nel.org,
        maz@...nel.org, apatel@...tanamicro.com, atishp@...osinc.com,
        seanjc@...gle.com, pgonda@...gle.com
Subject: Re: [PATCH 0/4] KVM: fix KVM_EXIT_SYSTEM_EVENT mess

On 4/22/22 09:58, Oliver Upton wrote:
> Is there any way we could clean this up in 5.18 and leave the whole
> ndata/data pattern for 5.19?
> 
> IOW, for 5.18 go back and fix the padding:
> 
> 	struct {
> 		__u32 type;
> 		__u32 pad;
> 		__u64 flags;
> 	} system_event;
> 
> Then for 5.19 circle back on the data business, except use a flag bit
> for it:
> 
> 	struct {
> 		__u32 type;
> 		__u32 pad;
> 	#define KVM_SYSTEM_EVENT_NDATA_VALID	(1u << 63)
> 		__u64 flags;
> 		__u64 ndata;
> 		__u64 data[16];
> 	} system_event;
> 
> Where we apply that bit to system_event::flags this time instead of
> ::type. Could also go the CAP route.

These patches are against kvm/next, so that is already what I did. :)

On the other hand right now the ARM and RISC-V flags are unusable with 
32-bit userspace, so we need to fix _something_ in 5.18 as well.  For 
your proposal, all that's missing is a 5.18 patch to add the padding. 
But since the flags UAPI was completely unused before 5.18 and there's 
no reason to inflict the different naming of fields to userspace.  So I 
think we want to apply this UAPI change in 5.18 too.

Paolo