Cc: brijesh.singh@amd.com, linux-kernel@vger.kernel.org, x86@kernel.org,
        kvm@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
        Borislav Petkov <bp@suse.de>, Joerg Roedel <joro@8bytes.org>,
        "Michael S . Tsirkin" <mst@redhat.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        =?UTF-8?B?XCJSYWRpbSBLcsSNbcOhxZlcIg==?= <rkrcmar@redhat.com>,
        Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [RFC Part2 PATCH v3 15/26] KVM: SVM: Add support for SEV
 LAUNCH_START command
To: Borislav Petkov <bp@alien8.de>
References: <20170724200303.12197-1-brijesh.singh@amd.com>
 <20170724200303.12197-16-brijesh.singh@amd.com>
 <20170913172510.azjkur3wsvat32aq@pd.tnic>
From: Brijesh Singh <brijesh.singh@amd.com>
Message-ID: <23c14fd9-f935-3bcd-412c-49889a94134a@amd.com>
Date: Wed, 13 Sep 2017 13:23:08 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170913172510.azjkur3wsvat32aq@pd.tnic>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2017 18:23:12.7892 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR12MB0156
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1893
Lines: 83


On 09/13/2017 12:25 PM, Borislav Petkov wrote:
...

>> +static void sev_deactivate_handle(struct kvm *kvm, int *error);
>> +static void sev_decommission_handle(struct kvm *kvm, int *error);
> 
> Please move code in a way that you don't need those forward
> declarations. Also, I'm wondering if having all the SEV-related code
> could live in sev.c or so - svm.c is humongous.
> 


Yes, svm.c is humongous.


...

>> +
>> +static void sev_decommission_handle(struct kvm *kvm, int *error)
>> +{
>> +	struct sev_data_decommission *data;
>> +
>> +	data = kzalloc(sizeof(*data), GFP_KERNEL);
> 
> Also, better on stack. Please do that for the other functions below too.


Yes, some structures are small and I don't expect them to grow in newer API
spec. We should be able to move them on the stack. I will audit the code and
make the necessary changes.


....

>> +	ret = -EFAULT;
>> +	if (copy_from_user(&params, (void *)argp->data,
>> +				sizeof(struct kvm_sev_launch_start)))
> 
> Sanity-check params. This is especially important if later we start
> using reserved fields.
> 

Yes, I will add some upper bound check on the length field and add the
sanity-check just after copying the parameters from userspace


...

>> +		goto e_free;
>> +
>> +	ret = -ENOMEM;
>> +	start = kzalloc(sizeof(*start), GFP_KERNEL);
>> +	if (!start)
>> +		goto e_free;
>> +
>> +	/* Bit 15:6 reserved, must be 0 */
>> +	start->policy = params.policy & ~0xffc0;
>> +
>> +	if (params.dh_cert_length && params.dh_cert_address) {
> 
> Yeah, we talked about this already: sanity-checking needed. But you get
> the idea.
> 

Will do

...

> 
>                  if (copy_from_user(session_addr,
> 				   (void *)params.session_address,
> 				   params.session_length))
> 
> reads better to me. Better yet if you shorten those member names into
> s_addr and s_len and so on...
> 
> 

Will use your recommendation.

thanks