Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp542041pxf; Wed, 7 Apr 2021 06:04:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzXW05iiOWftKi5uxunNa5pLo35JmLpT64mHwuxdbNztguejjD7jaRqz7efB8sCOaBmmK/g X-Received: by 2002:a17:906:fb09:: with SMTP id lz9mr3533039ejb.285.1617800685608; Wed, 07 Apr 2021 06:04:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617800685; cv=none; d=google.com; s=arc-20160816; b=vWWbCxX0BEH8DiueJpQWwny3Tmri9hHjI5HY8XQhKu+MLC0C6qXpwTEKsQ9GNdIOSb Y91ulI7K/xbmGJWun6FGTCQ3gHsoQi6WgTikZD5um0Ed2aFDC8ZlAjPvb3WFcKA87de7 Y50nFBxh7E8wNmeDcohs73f7eqkTrFhooyDrF21AkhCDzjPR3EpOV+noTmtX351X+udo jwYPAQ5JqnLq+UswnsuGhDLWdYLEJudOA2p8dPMGHlsKpZyQtumm+ZTXXvALqQ/oMgEe u58Z4X+EtAXKg6pNVYc9o9SIFhtNM2ov9SwfZ1AcBWzqy1cj9NhSSZC3h1E5RV/DgDsk 3p5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:mime-version:message-id:date :reply-to:dkim-signature; bh=29qkvQNMyHwLCHP8pXWRgWswaf/k2g0dTyIZhsX4Pvk=; b=yXcODb6fvUsJ8nKSUH2ThrMaUxsbd8nlB0pawHsgyTxS4iBwWJbqfLLYQyGrjp7y/r XSMJSwBbUjY0x3m/DmhlHYyGHNrZrtC0vawTIVXmux2cvGQt2zh5BU/P4ZBIeuhLyIRi juMpL+t4XSJPPFpQxtUD25aOfBBUtDHZPyokatAOHRBUlchctc5toQxrdH9EEWuv1UHV CL14c/8D/O9x5LhmaSfg6gMb5qke/MtCQNYA6b4fiq9/ZQlslOgwbSj5Xg2J8n2fJ8H3 Q0qIfENv6/n94JOurFyVOvRDF1Ea0IpmuYxFSFtdHO0jUH4mlOZbbsnK4Dq3O099i3tq 5AMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mUCDW8go; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cw21si18595757edb.344.2021.04.07.06.04.05; Wed, 07 Apr 2021 06:04:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mUCDW8go; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344152AbhDFWuP (ORCPT + 99 others); Tue, 6 Apr 2021 18:50:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40044 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344128AbhDFWuO (ORCPT ); Tue, 6 Apr 2021 18:50:14 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 24D38C061756 for ; Tue, 6 Apr 2021 15:50:06 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id k15so15465529ybh.6 for ; Tue, 06 Apr 2021 15:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=reply-to:date:message-id:mime-version:subject:from:to:cc; bh=29qkvQNMyHwLCHP8pXWRgWswaf/k2g0dTyIZhsX4Pvk=; b=mUCDW8goB/BkfT+GMgye4Lbl4vbr0CWjFY7SeZiXn3jP2soqTvTb9NToTJe9mZv29V 697bWQTz0SxGedUF1HwLD0JFxJvs20ZajAvN5qgCNhk+5Wkyc1TqJZjxJ4O+0Y2u+937 wy4sxbq50hDa62jBWPsHBBDxUDYKJapcfE2lO37hms0Sm0NsKUBuf+St+Gb5/f42Ezml eAe2CumEX7m0PTiQSq7OEXrbZ0w8TP2hSA9KfCv+DP0hI4IDeeFuVplbD7HFe4QuL2Y9 7l5yJmN9dl/lx9CQDk5TGNWLKUv3ZvNrHWqkDon/XSBNVfX4Lz4zdf5HoQgI2n3ZLhVr /9ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:date:message-id:mime-version:subject :from:to:cc; bh=29qkvQNMyHwLCHP8pXWRgWswaf/k2g0dTyIZhsX4Pvk=; b=YrEDxYzI7USIyefDMrJItRkD9ioEpYsRUXSjzdBxVhbramCS6JJ617zf+/axyNrUGt H/3dWLFG2H/yhA0eVhlPcefoh7V46xBB3PFBTt3dXGAuqhgOyEQh/FVYOVPJqSMt6vs1 femyhkQqHuzRIq1rH9BgX6X5ZLQ4SSmfyyF0K8mydBxF5TYb5VkOsLT0r1MTMyeIrxh7 nJ06fiI7PYF7AYC/miTeXt97k+7Tb8Pv+Af3vfiAna/CxA57MMH/XUoF9koOF+zvQSFF X5WlXzbfkXxzV+g73Lzwqb7hKxLbRp1fzH5ecObQntBgmIGifV3eiwWDGMDIWVZln8vu OZpA== X-Gm-Message-State: AOAM532OB4QsJ0jWTaCsbW+LnNNtgQNZQmLaSfwFREcHEyZ1xMzqGm30 LXDrrZlIHm+mg3JlgLBhw7Qb8j05Ozc= X-Received: from seanjc798194.pdx.corp.google.com ([2620:15c:f:10:24a1:90fb:182b:777c]) (user=seanjc job=sendgmr) by 2002:a25:2351:: with SMTP id j78mr536179ybj.102.1617749405370; Tue, 06 Apr 2021 15:50:05 -0700 (PDT) Reply-To: Sean Christopherson Date: Tue, 6 Apr 2021 15:49:44 -0700 Message-Id: <20210406224952.4177376-1-seanjc@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.31.0.208.g409f899ff0-goog Subject: [PATCH v2 0/8] ccp: KVM: SVM: Use stack for SEV command buffers From: Sean Christopherson To: Paolo Bonzini , Brijesh Singh , Tom Lendacky , John Allen Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Borislav Petkov , Christophe Leroy Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org This series teaches __sev_do_cmd_locked() to gracefully handle vmalloc'd command buffers by copying _all_ incoming data pointers to an internal buffer before sending the command to the PSP. The SEV driver and KVM are then converted to use the stack for all command buffers. Tested everything except sev_ioctl_do_pek_import(), I don't know anywhere near enough about the PSP to give it the right input. v2: - Rebase to kvm/queue, commit f96be2deac9b ("KVM: x86: Support KVM VMs sharing SEV context"). - Unconditionally copy @data to the internal buffer. [Christophe, Brijesh] - Allocate a full page for the buffer. [Brijesh] - Drop one set of the "!"s. [Christophe] - Use virt_addr_valid() instead of is_vmalloc_addr() for the temporary patch (definitely feel free to drop the patch if it's not worth backporting). [Christophe] - s/intput/input/. [Tom] - Add a patch to free "sev" if init fails. This is not strictly necessary (I think; I suck horribly when it comes to the driver framework). But it felt wrong to not free cmd_buf on failure, and even more wrong to free cmd_buf but not sev. v1: - https://lkml.kernel.org/r/20210402233702.3291792-1-seanjc@google.com Sean Christopherson (8): crypto: ccp: Free SEV device if SEV init fails crypto: ccp: Detect and reject "invalid" addresses destined for PSP crypto: ccp: Reject SEV commands with mismatching command buffer crypto: ccp: Play nice with vmalloc'd memory for SEV command structs crypto: ccp: Use the stack for small SEV command buffers crypto: ccp: Use the stack and common buffer for status commands crypto: ccp: Use the stack and common buffer for INIT command KVM: SVM: Allocate SEV command structures on local stack arch/x86/kvm/svm/sev.c | 262 +++++++++++++---------------------- drivers/crypto/ccp/sev-dev.c | 197 +++++++++++++------------- drivers/crypto/ccp/sev-dev.h | 4 +- 3 files changed, 196 insertions(+), 267 deletions(-) -- 2.31.0.208.g409f899ff0-goog