linux-kernel - Re: [RFC PATCH v1 01/10] KVM: SVM: Add KVM_SEV SEND

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: <2b63d983-a622-3bec-e6ac-abfd024e19c0@amd.com>
Date:   Mon, 29 Apr 2019 15:01:24 +0000
From:   "Singh, Brijesh" <brijesh.singh@....com>
To:     Borislav Petkov <bp@...en8.de>
CC:     "Singh, Brijesh" <brijesh.singh@....com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Joerg Roedel <joro@...tes.org>,
        "Lendacky, Thomas" <Thomas.Lendacky@....com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v1 01/10] KVM: SVM: Add KVM_SEV SEND_START command



On 4/26/19 3:43 PM, Borislav Petkov wrote:
> On Fri, Apr 26, 2019 at 02:29:31PM +0000, Singh, Brijesh wrote:
>> Yes that's doable but I am afraid that caching the value may lead us to
>> wrong path and also divergence from the SEV API spec. The spec says the
>> returned length is a minimum length but its possible that caller can
>> give a bigger buffer and FW will still work with it.
> 
> Does the caller even have a valid reason to give a bigger buffer len?
> 


Practically I don't see any reason why caller would do that but
theoretically it can. If we cache the len then we also need to consider
adding another flag to hint whether userspace ever requested length.
e.g an application can compute the length of session blob by looking at
the API version and spec and may never query the length.


> I mean I'm still thinking defensively here but maybe the only thing that
> would happen here with a bigger buffer is if the kmalloc() would fail,
> leading to eventual failure of the migration.
> 
> If the code limits the allocation to some sane max length, the migration
> won't fail even if userspace gives it too big values...
>