Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-13 Thread David Hildenbrand
On 13.09.19 09:43, Thomas Huth wrote: > On 13/09/2019 09.37, David Hildenbrand wrote: >> On 13.09.19 09:34, Thomas Huth wrote: >>> On 13/09/2019 09.20, Cornelia Huck wrote: On Thu, 12 Sep 2019 13:23:38 +0200 Thomas Huth wrote: > Hmm, we already talked about deprecating support f

Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-13 Thread Thomas Huth
On 13/09/2019 09.37, David Hildenbrand wrote: > On 13.09.19 09:34, Thomas Huth wrote: >> On 13/09/2019 09.20, Cornelia Huck wrote: >>> On Thu, 12 Sep 2019 13:23:38 +0200 >>> Thomas Huth wrote: >>> Hmm, we already talked about deprecating support for pre-3.15 kernel stuff in the past (see

Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-13 Thread David Hildenbrand
On 13.09.19 09:34, Thomas Huth wrote: > On 13/09/2019 09.20, Cornelia Huck wrote: >> On Thu, 12 Sep 2019 13:23:38 +0200 >> Thomas Huth wrote: >> >>> Hmm, we already talked about deprecating support for pre-3.15 kernel >>> stuff in the past (see >>> https://wiki.qemu.org/ChangeLog/2.12#Future_incom

Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-13 Thread Thomas Huth
On 13/09/2019 09.20, Cornelia Huck wrote: > On Thu, 12 Sep 2019 13:23:38 +0200 > Thomas Huth wrote: > >> Hmm, we already talked about deprecating support for pre-3.15 kernel >> stuff in the past (see >> https://wiki.qemu.org/ChangeLog/2.12#Future_incompatible_changes for >> example), > > Btw: di

Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-13 Thread Cornelia Huck
On Thu, 12 Sep 2019 13:23:38 +0200 Thomas Huth wrote: > Hmm, we already talked about deprecating support for pre-3.15 kernel > stuff in the past (see > https://wiki.qemu.org/ChangeLog/2.12#Future_incompatible_changes for > example), Btw: did we ever do that? I don't quite recall what code we wer

Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-12 Thread Thomas Huth
On 12/09/2019 12.52, Christian Borntraeger wrote: > > > On 12.09.19 11:20, Thomas Huth wrote: >> On 12/09/2019 11.14, David Hildenbrand wrote: >>> On 12.09.19 11:00, Thomas Huth wrote: When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject an interrupt, we convert them f

Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-12 Thread Thomas Huth
On 12/09/2019 12.47, Christian Borntraeger wrote: > > > On 12.09.19 11:00, Thomas Huth wrote: >> When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject >> an interrupt, we convert them from the legacy struct kvm_s390_interrupt >> to the new struct kvm_s390_irq via the s390int_to_s

Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-12 Thread Christian Borntraeger
On 12.09.19 12:58, David Hildenbrand wrote: > On 12.09.19 11:20, Thomas Huth wrote: >> On 12/09/2019 11.14, David Hildenbrand wrote: >>> On 12.09.19 11:00, Thomas Huth wrote: When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject an interrupt, we convert them from the l

Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-12 Thread David Hildenbrand
On 12.09.19 11:20, Thomas Huth wrote: > On 12/09/2019 11.14, David Hildenbrand wrote: >> On 12.09.19 11:00, Thomas Huth wrote: >>> When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject >>> an interrupt, we convert them from the legacy struct kvm_s390_interrupt >>> to the new struct

Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-12 Thread Christian Borntraeger
On 12.09.19 11:20, Thomas Huth wrote: > On 12/09/2019 11.14, David Hildenbrand wrote: >> On 12.09.19 11:00, Thomas Huth wrote: >>> When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject >>> an interrupt, we convert them from the legacy struct kvm_s390_interrupt >>> to the new str

Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-12 Thread Christian Borntraeger
On 12.09.19 11:00, Thomas Huth wrote: > When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject > an interrupt, we convert them from the legacy struct kvm_s390_interrupt > to the new struct kvm_s390_irq via the s390int_to_s390irq() function. > However, this function does not take

Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-12 Thread Janosch Frank
On 9/12/19 11:20 AM, Thomas Huth wrote: > On 12/09/2019 11.14, David Hildenbrand wrote: >> On 12.09.19 11:00, Thomas Huth wrote: >>> When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject >>> an interrupt, we convert them from the legacy struct kvm_s390_interrupt >>> to the new stru

Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-12 Thread Thomas Huth
On 12/09/2019 11.14, David Hildenbrand wrote: > On 12.09.19 11:00, Thomas Huth wrote: >> When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject >> an interrupt, we convert them from the legacy struct kvm_s390_interrupt >> to the new struct kvm_s390_irq via the s390int_to_s390irq() f

Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-12 Thread David Hildenbrand
On 12.09.19 11:00, Thomas Huth wrote: > When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject > an interrupt, we convert them from the legacy struct kvm_s390_interrupt > to the new struct kvm_s390_irq via the s390int_to_s390irq() function. > However, this function does not take car

[PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

2019-09-12 Thread Thomas Huth
When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject an interrupt, we convert them from the legacy struct kvm_s390_interrupt to the new struct kvm_s390_irq via the s390int_to_s390irq() function. However, this function does not take care of all types of interrupts that we can injec