Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp224825pxb; Wed, 11 Nov 2020 01:57:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJzOpyZywySstDU2BZcEHbJN/sPjCbWbtioECjm3wWC0+JFWJ6CCoYDjybyKLyEAxdUIQek6 X-Received: by 2002:a50:f98b:: with SMTP id q11mr4207623edn.345.1605088627361; Wed, 11 Nov 2020 01:57:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605088627; cv=none; d=google.com; s=arc-20160816; b=WCmJ78D0/fy5jqEzps+Xvn/PXLF5mKEv97WbDVtep0x3ym8PpQN2re5tMwMaEXgBI0 sx7fk/7+zSrZ/utbwUVB4/GV/oiaAtTl2iI7ZItnKMXZVWLiHGE0qAU5DbQpYX+Wbh9Y kJLRXkld5fyXRe98S2APyflMnFzExwFzSSW32JU1R14Tw+z2K2xJ5q8Dgs0aChMZu3S/ 11HGirWINQnjU6BLxrEVWNEYM1JqysxK9h9gsyFxPmvsGp0jsVrURPd/7EZv/MQ/TJsy aVNETI89Lhu60HmMvFdjhJ4bj7lSeqvKnJ20yS2pCTJUQB2Gmy6nZ01U51IG5t82zN5b i8kw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :ironport-sdr:ironport-sdr; bh=45Mts1m3Dk1009SyMsUmew7QHnDyxoLk0l305xjLfCc=; b=G7CcpiLWFaVUKDF/6YgRdl8oxmYm8n+qB4dlegjB9znMkSp8W1vYyAlgMa2Ayu6QIa QG1rDXnZklXTaNmUcYoD6j/UneRXGfz1IYBdlhnEhA+63PnqO53VRckn2LK1yih+sFPC SD/RDKT61nFsBQHxgjiu+6OAUEYlLf1tKfVf3d1OUhnOr+xBO6k5W4zr4/c5fIz+A+5x USDV38JPQuyey/573ewyje8CA0hqLJ6xH9cQktLFbJHETa0Sb7dH4QzgTJqfMf2DC2JG E8IlhhoVu5bMa5QIO2Qn50uPXb/fdsuuLCgJXf0PsC5QdiFbENGGlYwHoz9xD0kCMMeB t+CA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 1si1146857edv.354.2020.11.11.01.56.43; Wed, 11 Nov 2020 01:57:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727284AbgKKJyp (ORCPT + 99 others); Wed, 11 Nov 2020 04:54:45 -0500 Received: from mga03.intel.com ([134.134.136.65]:24494 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725995AbgKKJyn (ORCPT ); Wed, 11 Nov 2020 04:54:43 -0500 IronPort-SDR: Wv5aFNtcV7EFU0jeuHWVVCbS/9kJqWrIww7S0/CFrNYI61JoaXeZ5SORYFhQD9oiKSK05HNAE/ FmlJ4TGidlFw== X-IronPort-AV: E=McAfee;i="6000,8403,9801"; a="170232556" X-IronPort-AV: E=Sophos;i="5.77,469,1596524400"; d="scan'208";a="170232556" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Nov 2020 01:54:38 -0800 IronPort-SDR: IQQc4une4KiOKuUL6UxQpwa6jaTZgg450jzpVV1OwLxar3FPzfRgM0gH6dI1JEjq8a65iDea/M L8ZuAMYSU0qA== X-IronPort-AV: E=Sophos;i="5.77,469,1596524400"; d="scan'208";a="541719728" Received: from shuo-intel.sh.intel.com (HELO localhost) ([10.239.154.30]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Nov 2020 01:54:33 -0800 Date: Wed, 11 Nov 2020 17:54:31 +0800 From: Shuo A Liu To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, x86@kernel.org, "H . Peter Anvin" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Sean Christopherson , Yu Wang , Reinette Chatre , Zhi Wang , Zhenyu Wang Subject: Re: [PATCH v5 07/17] virt: acrn: Introduce an ioctl to set vCPU registers state Message-ID: <20201111095431.GH17702@shuo-intel.sh.intel.com> References: <20201019061803.13298-1-shuo.a.liu@intel.com> <20201019061803.13298-8-shuo.a.liu@intel.com> <20201109170940.GA2013864@kroah.com> <20201110131419.GG17702@shuo-intel.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 10.Nov'20 at 15:54:26 +0100, Greg Kroah-Hartman wrote: >On Tue, Nov 10, 2020 at 09:14:19PM +0800, Shuo A Liu wrote: >> > And there really is no validation of >> > any fields? >> >> Yes. Because HSM driver has little knowledge to do the validation. > >What is "HSM driver"? And you all are ready for fuzzers to break this >into small pieces, right? No validation of any input parameters feels >really really wrong. Best of luck! This driver is HSM (Hypervisor Service Module) driver. Take this hypercall for example. The register values are set by user, we can do nothing to verify them. If the values are wrong, the VM will crash and the hypervisor will handle that. > >> > > +struct acrn_regs { >> > > + struct acrn_gp_regs gprs; >> > > + struct acrn_descriptor_ptr gdt; >> > > + struct acrn_descriptor_ptr idt; >> > > + >> > > + __u64 rip; >> > >> > As these are all crossing the user/kernel boundry and then on to >> > somewhere "else", you have to specify the endian of all of these, right? >> > >> > if not, why not? >> >> The hypervisor and the driver only support X86_64 platform for now. So, the >> endian should be certain. > >Then specify it please. Ok. Will be __le64. I will also fix other instances in this file. > >> > > + __u16 reserved0[3]; >> > >> > What does the reserved fields do? >> >> To keep same layout with the hypervisor. Because the structure will be >> passed to hypervisor directly. >> >> > >> > Is there a pointer to a public document for all of these structures >> > somewhere? >> >> Unfortunately, no. I have added some documents for some strutures >> in the code via kernel-doc format. > >Is this not the hypervisor that this code is for: > https://projectacrn.org/ >? > >If not, what is this thing? > >If so, how is there not documentation for it? Oh, yes. We have the structures documentation on the website. Pls refer https://projectacrn.github.io/latest/api/hypercall_api.html# I meant that some fields of structures might be lack of explanation. > >> > > + struct acrn_regs vcpu_regs; >> > > +} __attribute__((aligned(8))); >> > >> > What does the alignment do here? >> >> The hypervisor wants to access aligned data block to improve the >> efficiency. Currently, the hypervisor only runs on x86_64 platform. > >That's nice, but what do you think that adding this attribute to a >structure provides you? Have you tested this really is doing what you >think it is doing? It could make the compiler put the data structure at aligned address. In the kernel the structures are almost from kmalloc, so the attribute might be not meaningful. But in the hypervisor, there are many such data structures in stack or in static pool, this attribute can make sure the data structures are located at the aligned address. Thanks shuo