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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 58211C43381 for ; Tue, 9 Mar 2021 19:43:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 407E865275 for ; Tue, 9 Mar 2021 19:43:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231264AbhCITnM (ORCPT ); Tue, 9 Mar 2021 14:43:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42196 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231286AbhCITnE (ORCPT ); Tue, 9 Mar 2021 14:43:04 -0500 Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B5C0BC06175F for ; Tue, 9 Mar 2021 11:43:04 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id n10so9498262pgl.10 for ; Tue, 09 Mar 2021 11:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=nrSjbcfbtpDu99fWTpmyTiTS4z7P8iLrCevZq+OwJDk=; b=fxZkdSwllM3KcD1tprgJ8Qwwl3PI5A+cU8oORbvgRMWthQA0elQUWYTsTefxo87ZMH csmfaAMMCvh7WBAPvVauUmDmZGZj1yKsoDGNatLLTaHDvpE93tQVrzeqnmrkE8dw+19g H4NzNxqJTkhxUUKb6moJUDCHrSdkD3Mn2YC8vv8/ax319/eIZFWqVitKiicr3Q9vwnWL C8iZA/cO52ZIoF+Y0a8FtA3ipQmjOmywD6Dl4b4oDoU8/FL4gYiEU9PEuhi7cG6ryrpP LpmHctDWZMDMaQIz2OpaVQeOHmmf0/qTOSIh/dx5RZKdqq6dBJPmVN2QpiTqphqK9QNM SSGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nrSjbcfbtpDu99fWTpmyTiTS4z7P8iLrCevZq+OwJDk=; b=QUSMlGksfOfcA8gdqD/svJH+PrV4Nao5MwLY9OzWYoK2AYGZc5C6Wi1u/EQrgPCjKd pw3AvCwgA9SD+el66v+u6+X1OYhbkVvSv5TDjs5tIeRq1pVhXlCG/J916PvotYVDpfZE sxn4d8hPUs79S3JLJoQ4Sg9KBO2AFO8JYexKYMffDguKclDPntLzqp3f3N/UhEU4RohK SZ6h9B3lKHTm7WZQ9iTpHC/OrrEsUQpTgF38wAXJQNDIoYgeKnfjMHbdPiOu4LPRHrqU 6GjYwiv2PswlYmk2Sb0mUTu/a235X0W6BZeaF/kcll2S6QeLcadazBLVTJsc3BaJj2t9 /2dA== X-Gm-Message-State: AOAM533b3Rw5jgyf1dlCzjDzVH7U99CvHRoqpddTKJq6aw8CP6pN6Wxl DEluXdAyxH/PpQJXc8nvB/rpsw== X-Google-Smtp-Source: ABdhPJxG0mCqsNk6TCaFJMi2aql7w63MaxtH/VOu8x+69eBxPHe97w/5N8Km/Rme/8HzauKwfNe/gw== X-Received: by 2002:a62:3085:0:b029:1ec:a6b8:6dd2 with SMTP id w127-20020a6230850000b02901eca6b86dd2mr26760622pfw.7.1615318983949; Tue, 09 Mar 2021 11:43:03 -0800 (PST) Received: from google.com ([2620:15c:f:10:e4dd:6c31:9463:f8da]) by smtp.gmail.com with ESMTPSA id 25sm14296910pfh.199.2021.03.09.11.43.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Mar 2021 11:43:03 -0800 (PST) Date: Tue, 9 Mar 2021 11:42:56 -0800 From: Sean Christopherson To: Steve Rutherford Cc: Brijesh Singh , Ashish Kalra , "pbonzini@redhat.com" , "joro@8bytes.org" , "Lendacky, Thomas" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "venu.busireddy@oracle.com" , Will Deacon , Quentin Perret Subject: Re: [PATCH v10 10/16] KVM: x86: Introduce KVM_GET_SHARED_PAGES_LIST ioctl Message-ID: References: <20210224175122.GA19661@ashkalra_ubuntu_server> <20210225202008.GA5208@ashkalra_ubuntu_server> <20210226140432.GB5950@ashkalra_ubuntu_server> <20210308104014.GA5333@ashkalra_ubuntu_server> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, Mar 08, 2021, Steve Rutherford wrote: > On Mon, Mar 8, 2021 at 1:11 PM Brijesh Singh wrote: > > On 3/8/21 1:51 PM, Sean Christopherson wrote: > > > If the guest does the hypercall after writing the page, then the guest is hosed > > > if it gets migrated while writing the page (scenario #1): > > > > > > vCPU Userspace > > > zero_bytes[0:N] > > > > > > > > > zero_bytes[N+1:4095] > > > set_shared (dest) > > > kaboom! > > > > > > Maybe I am missing something, this is not any different from a normal > > operation inside a guest. Making a page shared/private in the page table > > does not update the content of the page itself. In your above case, I > > assume zero_bytes[N+1:4095] are written by the destination VM. The > > memory region was private in the source VM page table, so, those writes > > will be performed encrypted. The destination VM later changed the memory > > to shared, but nobody wrote to the memory after it has been transitioned > > to the shared, so a reader of the memory should get ciphertext and > > unless there was a write after the set_shared (dest). Sorry, that wasn't clear, there's an implied page table update to make the page shared before zero_bytes. > > > If userspace does GET_DIRTY after GET_LIST, then the host would transfer bad > > > data by consuming a stale list (scenario #2): > > > > > > vCPU Userspace > > > get_list (from KVM or internally) > > > set_shared (src) > > > zero_page (src) > > > get_dirty > > > > > > > > > kaboom! > > > > > > I don't remember how things are done in recent Ashish Qemu/KVM patches > > but in previous series, the get_dirty() happens before the querying the > > encrypted state. There was some logic in VMM to resync the encrypted > > bitmap during the final migration stage and perform any additional data > > transfer since last sync. It's likely that Ashish's patches did the correct thing, I just wanted to point out that both host and guest need to do everything in a very specific order. > > > If both guest and host order things to avoid #1 and #2, the host can still > > > migrate the wrong data (scenario #3): > > > > > > vCPU Userspace > > > set_private > > > zero_bytes[0:4096] > > > get_dirty > > > set_shared (src) > > > get_list > > > > > > > > > set_private (dest) > > > kaboom! > > > > > > Since there was no write to the memory after the set_shared (src), so > > the content of the page should not have changed. After the set_private > > (dest), the caller should be seeing the same content written by the > > zero_bytes[0:4096] > > I think Sean was going for the situation where the VM has moved to the > destination, which would have changed the VEK. That way the guest > would be decrypting the old ciphertext with the new (wrong) key. I think that's what I was saying? I was pointing out that the userspace VMM would see the page as "shared" and so read the guest memory directly instead of routing it through the PSP. Anyways, my intent wasn't to point out a known issue anywhere. I was working through how GET_LIST would interact with GET_DIRTY_LOG to convince myself that the various flows were bombproof. I wanted to record those thoughts so that I can remind myself of the requirements when I inevitably forget them in the future. > > > Scenario #3 is unlikely, but plausible, e.g. if the guest bails from its > > > conversion flow for whatever reason, after making the initial hypercall. Maybe > > > it goes without saying, but to address #3, the guest must consider existing data > > > as lost the instant it tells the host the page has been converted to a different > > > type. > > > > > >> For the above reason if we do in-kernel hypercall handling for page > > >> encryption status (which we probably won't require for SEV-SNP & > > >> correspondingly there will be no hypercall exiting), > > > As above, that doesn't preclude KVM from exiting to userspace on conversion. > > > > > >> then we can implement a standard GET/SET ioctl interface to get/set the guest > > >> page encryption status for userspace, which will work across SEV, SEV-ES and > > >> SEV-SNP.