From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49338C43219 for ; Fri, 26 Apr 2019 20:43:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 19C742084F for ; Fri, 26 Apr 2019 20:43:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alien8.de header.i=@alien8.de header.b="UhdPGQOL" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726314AbfDZUna (ORCPT ); Fri, 26 Apr 2019 16:43:30 -0400 Received: from mail.skyhub.de ([5.9.137.197]:39724 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725966AbfDZUn3 (ORCPT ); Fri, 26 Apr 2019 16:43:29 -0400 Received: from zn.tnic (p200300EC2F0E4E00943B2A4E3B498EBE.dip0.t-ipconnect.de [IPv6:2003:ec:2f0e:4e00:943b:2a4e:3b49:8ebe]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id E91221EC0380; Fri, 26 Apr 2019 22:43:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1556311408; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=U/CTz5SAE+pabViqpyUk1tFxQ7Z2FiMtt9crX5ZBuxU=; b=UhdPGQOLrAf8IGQf0LFY/S4cUffWG3c4g9ftiz6gJMEqqlTKDul2WnVMT5615oZgOgXDnJ ++VBWOsicl1sJqsDfbbe8zvCah3EZWOKI05JbmK2U00zXthBByudvMSRKV7SFtwhqV+Miv zO7NC654c1E1HbrUsIITY8nVh74sj4g= Date: Fri, 26 Apr 2019 22:43:27 +0200 From: Borislav Petkov To: "Singh, Brijesh" Cc: "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , Joerg Roedel , "Lendacky, Thomas" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH v1 01/10] KVM: SVM: Add KVM_SEV SEND_START command Message-ID: <20190426204327.GM4608@zn.tnic> References: <20190424160942.13567-1-brijesh.singh@amd.com> <20190424160942.13567-2-brijesh.singh@amd.com> <20190426141042.GF4608@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org 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? 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... -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.