Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Cc:     brijesh.singh@amd.com, Ashish Kalra <Ashish.Kalra@amd.com>,
        pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com,
        hpa@zytor.com, joro@8bytes.org, bp@suse.de,
        thomas.lendacky@amd.com, x86@kernel.org, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, rientjes@google.com,
        srutherford@google.com, luto@kernel.org
Subject: Re: [PATCH v6 01/14] KVM: SVM: Add KVM_SEV SEND_START command
To:     Venu Busireddy <venu.busireddy@oracle.com>
References: <cover.1585548051.git.ashish.kalra@amd.com>
 <3f90333959fd49bed184d45a761cc338424bf614.1585548051.git.ashish.kalra@amd.com>
 <20200402062726.GA647295@vbusired-dt>
 <89a586e4-8074-0d32-f384-a4597975d129@amd.com>
 <20200402163717.GA653926@vbusired-dt>
 <8b1b4874-11a8-1422-5ea1-ed665f41ab5c@amd.com>
 <20200402185706.GA655878@vbusired-dt>
From:   Brijesh Singh <brijesh.singh@amd.com>
Message-ID: <6ced22f7-cbe5-a698-e650-7716566d4d8a@amd.com>
Date:   Thu, 2 Apr 2020 14:17:26 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.6.0
In-Reply-To: <20200402185706.GA655878@vbusired-dt>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from Brijeshs-MacBook-Pro.local (165.204.77.11) by SN4PR0501CA0120.namprd05.prod.outlook.com (2603:10b6:803:42::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.6 via Frontend Transport; Thu, 2 Apr 2020 19:17:22 +0000
X-Originating-IP: [165.204.77.11]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 1eda7630-cb20-4f0e-01cf-08d7d73a79ab
X-MS-TrafficTypeDiagnostic: SA0PR12MB4349:|SA0PR12MB4349:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <SA0PR12MB4349EE03349D23486172E193E5C60@SA0PR12MB4349.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-Forefront-PRVS: 0361212EA8
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA0PR12MB4400.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(10009020)(4636009)(39860400002)(376002)(396003)(366004)(136003)(346002)(7416002)(6486002)(2616005)(6916009)(6512007)(6506007)(36756003)(66946007)(31696002)(53546011)(8936002)(66476007)(956004)(81156014)(81166006)(8676002)(52116002)(86362001)(44832011)(5660300002)(2906002)(4326008)(16526019)(186003)(66556008)(31686004)(478600001)(26005)(316002);DIR:OUT;SFP:1101;
Received-SPF: None (protection.outlook.com: amd.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: OXt8vEFTSSp8/RS/yEkk9tZ2+svoePvVkW4TTZD1/gMetdpSUukd0eR3XpYqzTrhzquANA31AtprNNDTgmqgokxCChNM31peAGHRBXGpzw2cNifnbN29SOllbSB4H+Ce4hQPaPd0d1huF7pOgd7GjBkA957vAupX0vMbQZ+I+31gyRPyFQt5v2WEk1mqPiX+VpOb85lh6048YmQc7WmbDFCdUwnzj3jZ0xStNSM/0AV9mK7iusrN4jRizuE9mnBRujj0pVP0pQCAxSVQ80YS+B/zgFvXuUbb9VnLT8y6WlaxJc4rC3/e0qbGrHkWdFw/59Gok5fFaa4JYkJPLPUeX8xh0ua6lDtxrOIGFHHn2hreXn5waedmTtGoDetWBgLXw0sjxkfEDmWbnt/KH4HUqj5CW29s3pCYonoMtYEkCvhbJ1PEyOyg7lijghmBc580
X-MS-Exchange-AntiSpam-MessageData: WJvC5WEfzIKKn/NkQHY6Tq8JVOvYeYx4pLv9FZTGPkvGge2b77GK4RLBHOe9WEpLh+wvy0W1Mg5CxHJN9MQWQcoVsvBdoiVoisaN2qY7DJqLbdoytkKuN5fhGC5RtfNqNetqIBtFnBWV+eZS95FTIQ==
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1eda7630-cb20-4f0e-01cf-08d7d73a79ab
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2020 19:17:24.7750
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: hB2R8IYolXLJOTedJWw0vLe+Eh/wIYiiQlqXIZ3Fg3GChrZoSaHTptYJfCgFfoauV2xE2JwJJWs/LfElueY64w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4349
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 4/2/20 1:57 PM, Venu Busireddy wrote:
[snip]...

>> The question is, how does a userspace know the session length ? One
>> method is you can precalculate a value based on your firmware version
>> and have userspace pass that, or another approach is set
>> params.session_len = 0 and query it from the FW. The FW spec allow to
>> query the length, please see the spec. In the qemu patches I choose
>> second approach. This is because session blob can change from one FW
>> version to another and I tried to avoid calculating or hardcoding the
>> length for a one version of the FW. You can certainly choose the first
>> method. We want to ensure that kernel interface works on the both cases.
> I like the fact that you have already implemented the functionality to
> facilitate the user space to obtain the session length from the firmware
> (by setting params.session_len to 0). However, I am trying to address
> the case where the user space sets the params.session_len to a size
> smaller than the size needed.
>
> Let me put it differently. Let us say that the session blob needs 128
> bytes, but the user space sets params.session_len to 16. That results
> in us allocating a buffer of 16 bytes, and set data->session_len to 16.
>
> What does the firmware do now?
>
> Does it copy 128 bytes into data->session_address, or, does it copy
> 16 bytes?
>
> If it copies 128 bytes, we most certainly will end up with a kernel crash.
>
> If it copies 16 bytes, then what does it set in data->session_len? 16,
> or 128? If 16, everything is good. If 128, we end up causing memory
> access violation for the user space.

My interpretation of the spec is, if user provided length is smaller
than the FW expected length then FW will reports an error with
data->session_len set to the expected length. In other words, it should
*not* copy anything into the session buffer in the event of failure. If
FW is touching memory beyond what is specified in the session_len then
its FW bug and we can't do much from kernel. Am I missing something ?


>
> Perhaps, this can be dealt a little differently? Why not always call
> sev_issue_cmd(kvm, SEV_CMD_SEND_START, ...) with zeroed out data? Then,
> if the user space has set params.session_len to 0, we return with the
> needed params.session_len. Otherwise, we check if params.session_len is
> large enough, and if not, we return -EINVAL?