Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3805785ybt; Tue, 30 Jun 2020 11:36:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLl6CnYjvsLtBfCygXIKoU8qD68W62kJfBnbxcMqNnvXUpTaa6NX5/xjShkxIPEve/0ApT X-Received: by 2002:a17:906:4b59:: with SMTP id j25mr14928163ejv.301.1593542056918; Tue, 30 Jun 2020 11:34:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593542056; cv=none; d=google.com; s=arc-20160816; b=xWZITVS+93QlRs+0gF5kNUhcYLYzStZKJByX7Oae20oBoTxhwHlnG4DgBBi3tHw9yR +nuXECVFre1D2S8HmzYr2Da6z8tq9aJxK5ismkqzJOuICzp+mw0gFdwP8lkpmnTRGLJi 0oGhyIqg2vgVG/iueot6qFg1T0vfFK0P6vRuWxE3LwkXxKAnquamY5Ybl6uUAGHU8NYc ulA98q88I9PrOSFJQuaRAk9HPbdCMzAK+p1U9qX3YfsK22UyKbz9YHG32gtK+7Z54Ipw rZ8/z2zmvzkhmNn8gPrAMrAwL7nbw4RRTsgSIqflSqo4fA2dNmteWwP/u1G5pZLbltml P+AQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=f7Ay0BZPslo+/hkCnggDepdpgQUh8gMzDJFRyBpq1nE=; b=KFG9CsOU3G7j+H3/UmI2vOSLuyEi+y+H7bbp1y9DWJMcQgTCwdAkjKMc4fkWsRXctr 5Ku27AUy5giRLYy2/LchJ5zSkCZWeZax4U9ZzEWYad0O4GlGML6XfFWY+7jbHGkl3CAg 9vhz2efb1WapvEdoOGMmwFaFa/z8MBv2oquU9YOGS6UfVpr86JvbUdGaiYAJc19Hpclk qRSBJZ+nClBjAFGUIqLBO5qlUjIHzL/ZuIMnwfXFaxHKXt8aB3jGrlpFce2xGgCBS440 ntbFCE1l2SqIJfFsWX4o6HE0qiFw2U/xDO/DywzdedAQLGdtOtl6rh14krtyjGR4Vpze iMNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=Us1GnfTV; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u6si2192469ejf.218.2020.06.30.11.33.53; Tue, 30 Jun 2020 11:34:16 -0700 (PDT) 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; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=Us1GnfTV; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732312AbgF3Qsg (ORCPT + 99 others); Tue, 30 Jun 2020 12:48:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728022AbgF3Qsf (ORCPT ); Tue, 30 Jun 2020 12:48:35 -0400 Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 434E4C061755 for ; Tue, 30 Jun 2020 09:48:35 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id l2so18783697wmf.0 for ; Tue, 30 Jun 2020 09:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f7Ay0BZPslo+/hkCnggDepdpgQUh8gMzDJFRyBpq1nE=; b=Us1GnfTVGgPfn6BZ4oalx8awSn0OTVLHxF/OybbrBjUNIdDbMMtrsNdC8UeBizxeQr kLqIeB2f+/UErnJCKJ6L7kCAV0MjzaTFXCYV9VSYnLPtipEG5VQZwo6UTPOz/ZpSZpP6 c8uOASv+hgH2OPRdLBkQkNbrrtYeVoV8XmsXMBatc7/gSEndnveufJCTL1si/k1glEuf glgrqCQpQUU/nu8aDXdW/SdKiJe1Y8njN6bLtrkajqa/Z9YFXHjBhjWDJ63rVH5X+95F 7WoSYv6DPgWq0PKhILzkm4iU9hBm2T1hjlA4HK3cw/aSdRttrTnktnryceVXfxZGLVcf uzsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f7Ay0BZPslo+/hkCnggDepdpgQUh8gMzDJFRyBpq1nE=; b=cVjG/0FZwULLjwNgUjFbpF3l35FEu2lJVqtHLb8bhymt8p37a/Dh0ysp8x1XPnCXf3 oYfUAkO4Fy2MtumAPQDIEpY7WkN2KUBE8b42P80Vtl70vLWkeYnOHYdgp1RCR6H2Q2vd QUcqii2eyVsJQBUKG31m5EF5F7OpvR0mx3wDe6bqrIRWsj4sbCQkIxbgUXUYLup44hjp Boi/O3OQDWf+uXIUY7BciWrTBaKxC5Bj/W1YCbQ5UvvQSfqcCOpGHhRU7sbts5UZVkpL IQq9X1uAFXSfB9od0y4zgrwCoOMIrM8SQkoqyXg520V24YUT5YMaWfrCo2n0k54wfICM +GWA== X-Gm-Message-State: AOAM531UlSP2IqDT1VVPJkFoo7iiPfGB4E3f+B1Ow9W7n/f7ZaEpLQQd ra5VpNjq+dBG6bH/SJahO0wP5jHasoGg20YH078iaQ== X-Received: by 2002:a7b:c92e:: with SMTP id h14mr21564715wml.36.1593535713991; Tue, 30 Jun 2020 09:48:33 -0700 (PDT) MIME-Version: 1.0 References: <20200617220844.57423-1-jarkko.sakkinen@linux.intel.com> <20200617220844.57423-16-jarkko.sakkinen@linux.intel.com> <20200629171022.GC32176@zn.tnic> <20200630060055.GS12312@linux.intel.com> <20200630084128.GA1093@zn.tnic> In-Reply-To: <20200630084128.GA1093@zn.tnic> From: Andy Lutomirski Date: Tue, 30 Jun 2020 09:48:22 -0700 Message-ID: Subject: Re: [PATCH v33 15/21] x86/vdso: Add support for exception fixup in vDSO functions To: Borislav Petkov Cc: Sean Christopherson , Jarkko Sakkinen , X86 ML , linux-sgx@vger.kernel.org, LKML , Jethro Beekman , Andrew Morton , Andy Shevchenko , asapek@google.com, "Xing, Cedric" , chenalexchen@google.com, conradparker@google.com, cyhanish@google.com, Dave Hansen , "Huang, Haitao" , Josh Triplett , "Huang, Kai" , "Svahn, Kai" , kmoy@google.com, Christian Ludloff , Andrew Lutomirski , Neil Horman , npmccallum@redhat.com, puiterwijk@redhat.com, David Rientjes , Thomas Gleixner , yaozhangx@google.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 30, 2020 at 1:41 AM Borislav Petkov wrote: > > On Mon, Jun 29, 2020 at 11:00:55PM -0700, Sean Christopherson wrote: > > E.g. the vDSO function should get the fixup even if userspace screws > > up mmap() and invokes __vdso_sgx_enter_enclave() without being tagged > > an SGX task. > > I sincerely hope you don't mean this seriously. > > Please add a member to task_struct which denotes that a task is an > sgx task, test that member where needed and forget real quickly about > running *any* *fixup* for unrelated tasks. I don't see the problem. If you call this magic vDSO function and get a fault, it gets handled. What's the failure mode? > > > No hard dependency, it's normal kernel code. My reasoning for dropping it > > in .../vdso was largely to co-locate it with vdso/extable.h due to the > > dependency on the format of 'struct vdso_exception_table_entry'. > > A struct which you defined instead of simply using struct > exception_table_entry even if it has a handler member which would remain > unused? Don't forget the cross-arch issue. We need that structure to have constant layout so that the -m32 build from the vDSO has the same layout as in the kernel. So my only actual objection to the patch is that there should probably be a comment above the structure reminding people that it needs to have the same layout on 32-bit, x32, and x86_64. So maybe the entries should be s32 instead of int, although this doesn't really matter.