From: Paolo Bonzini <pbonzini@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: "Christoffer Dall" <cdall@linaro.org>,
"Christoffer Dall" <christoffer.dall@linaro.org>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, KVM <kvm@vger.kernel.org>,
kernel-hardening@lists.openwall.com,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Marc Zyngier" <marc.zyngier@arm.com>
Subject: R: Re: [PATCH] KVM: arm/arm64: Allow usercopy to vcpu->arch.ctxt and arm64 debug
Date: Mon, 23 Oct 2017 17:06:14 -0400 (EDT) [thread overview]
Message-ID: <1024881182.14288556.1508792774084.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CAGXu5jKoLP8jN4ZtRQnFpy6RWK1JJTa7eBuA2p9huBfh11bWvg@mail.gmail.com>
----- Kees Cook <keescook@chromium.org> ha scritto:
> On Mon, Oct 23, 2017 at 7:14 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 22/10/2017 09:44, Christoffer Dall wrote:
> >> However, I think it's much clearer if I
> >> rewrite these to use get_user() and put_user(). v2 incoming.
> >
> > I'd actually prefer if you all do a trivial conversion to
> > kvm_init_usercopy to begin with. In fact, we could just change the
> > default from "0, 0" to "0, sizeof (kvm_arch_vcpu)" in kvm_init. Any
> > other change can be applied after the patches are merged to Linus's
> > tree, especially with KVM Forum and the merge window both coming soon.
> >
> > I'll send a v2 myself later this week.
>
> Okay, which patches would you like me to carry in the usercopy
> whitelisting tree for the coming merge window?
v2 of mine, which shall come in the next couple of days.
Paolo
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
WARNING: multiple messages have this Message-ID (diff)
From: pbonzini@redhat.com (Paolo Bonzini)
To: linux-arm-kernel@lists.infradead.org
Subject: R: Re: [PATCH] KVM: arm/arm64: Allow usercopy to vcpu->arch.ctxt and arm64 debug
Date: Mon, 23 Oct 2017 17:06:14 -0400 (EDT) [thread overview]
Message-ID: <1024881182.14288556.1508792774084.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CAGXu5jKoLP8jN4ZtRQnFpy6RWK1JJTa7eBuA2p9huBfh11bWvg@mail.gmail.com>
----- Kees Cook <keescook@chromium.org> ha scritto:
> On Mon, Oct 23, 2017 at 7:14 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 22/10/2017 09:44, Christoffer Dall wrote:
> >> However, I think it's much clearer if I
> >> rewrite these to use get_user() and put_user(). v2 incoming.
> >
> > I'd actually prefer if you all do a trivial conversion to
> > kvm_init_usercopy to begin with. In fact, we could just change the
> > default from "0, 0" to "0, sizeof (kvm_arch_vcpu)" in kvm_init. Any
> > other change can be applied after the patches are merged to Linus's
> > tree, especially with KVM Forum and the merge window both coming soon.
> >
> > I'll send a v2 myself later this week.
>
> Okay, which patches would you like me to carry in the usercopy
> whitelisting tree for the coming merge window?
v2 of mine, which shall come in the next couple of days.
Paolo
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: "Christoffer Dall" <cdall@linaro.org>,
"Christoffer Dall" <christoffer.dall@linaro.org>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, KVM <kvm@vger.kernel.org>,
kernel-hardening@lists.openwall.com,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Marc Zyngier" <marc.zyngier@arm.com>
Subject: [kernel-hardening] R: Re: [PATCH] KVM: arm/arm64: Allow usercopy to vcpu->arch.ctxt and arm64 debug
Date: Mon, 23 Oct 2017 17:06:14 -0400 (EDT) [thread overview]
Message-ID: <1024881182.14288556.1508792774084.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CAGXu5jKoLP8jN4ZtRQnFpy6RWK1JJTa7eBuA2p9huBfh11bWvg@mail.gmail.com>
----- Kees Cook <keescook@chromium.org> ha scritto:
> On Mon, Oct 23, 2017 at 7:14 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 22/10/2017 09:44, Christoffer Dall wrote:
> >> However, I think it's much clearer if I
> >> rewrite these to use get_user() and put_user(). v2 incoming.
> >
> > I'd actually prefer if you all do a trivial conversion to
> > kvm_init_usercopy to begin with. In fact, we could just change the
> > default from "0, 0" to "0, sizeof (kvm_arch_vcpu)" in kvm_init. Any
> > other change can be applied after the patches are merged to Linus's
> > tree, especially with KVM Forum and the merge window both coming soon.
> >
> > I'll send a v2 myself later this week.
>
> Okay, which patches would you like me to carry in the usercopy
> whitelisting tree for the coming merge window?
v2 of mine, which shall come in the next couple of days.
Paolo
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
next prev parent reply other threads:[~2017-10-23 21:06 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-20 23:25 [PATCH 0/2] KVM: fixes for the kernel-hardening tree Paolo Bonzini
2017-10-20 23:25 ` [kernel-hardening] " Paolo Bonzini
2017-10-20 23:25 ` [PATCH 1/2] KVM: allow setting a usercopy region in struct kvm_vcpu Paolo Bonzini
2017-10-20 23:25 ` [kernel-hardening] " Paolo Bonzini
2017-10-21 14:53 ` Kees Cook
2017-10-21 14:53 ` [kernel-hardening] " Kees Cook
2017-10-20 23:25 ` [PATCH 2/2] KVM: fix KVM_XEN_HVM_CONFIG ioctl Paolo Bonzini
2017-10-20 23:25 ` [kernel-hardening] " Paolo Bonzini
2017-10-21 18:45 ` [PATCH] KVM: arm/arm64: Allow usercopy to vcpu->arch.ctxt and arm64 debug Christoffer Dall
2017-10-21 18:45 ` [kernel-hardening] " Christoffer Dall
2017-10-21 18:45 ` Christoffer Dall
2017-10-22 3:06 ` Kees Cook
2017-10-22 3:06 ` [kernel-hardening] " Kees Cook
2017-10-22 3:06 ` Kees Cook
2017-10-22 7:44 ` Christoffer Dall
2017-10-22 7:44 ` [kernel-hardening] " Christoffer Dall
2017-10-22 7:44 ` Christoffer Dall
2017-10-23 14:14 ` Paolo Bonzini
2017-10-23 14:14 ` [kernel-hardening] " Paolo Bonzini
2017-10-23 14:14 ` Paolo Bonzini
2017-10-23 14:49 ` Christoffer Dall
2017-10-23 14:49 ` [kernel-hardening] " Christoffer Dall
2017-10-23 14:49 ` Christoffer Dall
2017-10-23 19:40 ` Kees Cook
2017-10-23 19:40 ` [kernel-hardening] " Kees Cook
2017-10-23 19:40 ` Kees Cook
2017-10-23 21:06 ` Paolo Bonzini [this message]
2017-10-23 21:06 ` [kernel-hardening] R: " Paolo Bonzini
2017-10-23 21:06 ` Paolo Bonzini
2017-10-22 7:48 ` [PATCH v2] " Christoffer Dall
2017-10-22 7:48 ` Christoffer Dall
2017-10-23 9:52 ` [PATCH 0/2] KVM: fixes for the kernel-hardening tree David Hildenbrand
2017-10-23 9:52 ` [kernel-hardening] " David Hildenbrand
2017-10-23 11:10 ` Christian Borntraeger
2017-10-23 11:10 ` [kernel-hardening] " Christian Borntraeger
2017-10-23 12:39 ` Cornelia Huck
2017-10-23 12:39 ` [kernel-hardening] " Cornelia Huck
2017-10-23 14:15 ` Paolo Bonzini
2017-10-23 14:15 ` [kernel-hardening] " Paolo Bonzini
2017-10-25 9:45 ` David Hildenbrand
2017-10-25 9:45 ` [kernel-hardening] " David Hildenbrand
2017-10-25 10:31 ` Christian Borntraeger
2017-10-25 10:31 ` [kernel-hardening] " Christian Borntraeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1024881182.14288556.1508792774084.JavaMail.zimbra@redhat.com \
--to=pbonzini@redhat.com \
--cc=cdall@linaro.org \
--cc=christoffer.dall@linaro.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
--cc=rkrcmar@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.