Received: by 2002:a05:7412:6592:b0:d7:7d3a:4fe2 with SMTP id m18csp594645rdg; Thu, 10 Aug 2023 12:41:05 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGXWuJ0dWnw/pgtrVUZNfHKePKP3xQhL75t6Oul9AIj9T6DnGWespOCk9VcRtJxE3TBOZ9l X-Received: by 2002:a17:902:d484:b0:1b8:936f:c34d with SMTP id c4-20020a170902d48400b001b8936fc34dmr3791857plg.27.1691696465347; Thu, 10 Aug 2023 12:41:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691696465; cv=none; d=google.com; s=arc-20160816; b=psCmgKe4vqNRGNXev+EGV7Z1n25DX3YVa76FZf45I1/MQWctkeoZURXcs9nf5h3F0o ys1ppDJIy8MZGKWt0xCAlEltvo4Bk78PX3CrGumjvsM0BMip7uSIj3Y6M/ydXZcprkEO CWCirb8rxMwk9rWcwQW60PKh7Ef07zibBbMaxvw3ovjng2B+8MVUlok1gxIAYodLAhpJ gY1JJJynp+JgmHpoofU42vN6graMKhXLhwl+7RhOX2McS210GxMA1ypkxHe+bb249Svp QaLrLecCA0xDyTAi2feuv2bEGmz2QHkeLBVa3tNaQK9yUGM7HTZia154ZjnliEQiuVgN H2FQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=osZx9MFsTjA+0nKdtnzmcExs253v22D1JcCvOo2WUgU=; fh=xltAmSPd/yLdUi9FHi45DAi3RH3y0htPE7VC5DZecA8=; b=o1BiuAttzeMkxL+rcqOqJw2goDwkDZmgZKVvVrg0Bl99OoI/ImResomCZSBTBv/xRT BMYSU9dl3/Wx8uBXXTED0MYoo30s31pfd3F04Dcyg6BpGZJf6DTrxKi6RQPzTxxwuszp /4E0JnE/Wr1N19xKGS40YkjxwK84XNt5Pn7mHPlMCkuRiaZV+LfHho7uok1IyVtJgE33 2zzdox0rubZ2XoQn6OzMKPejAu6GdWkPsIsMH5J5HEAz0dTHZCX9J9Jhk1uY7nMkECWf nAK0FHkOS0YMmUGbFvzSdosZ7P8RKdfExphicAjO9p2ROvrC1o7yct6pKqn9ZgM7K1uZ 2wYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=CrGiYGDg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z6-20020a170903018600b001b88dbc8b09si1989002plg.454.2023.08.10.12.40.48; Thu, 10 Aug 2023 12:41:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b=CrGiYGDg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234845AbjHJTHW (ORCPT + 99 others); Thu, 10 Aug 2023 15:07:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232296AbjHJTHV (ORCPT ); Thu, 10 Aug 2023 15:07:21 -0400 Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03572E56 for ; Thu, 10 Aug 2023 12:07:20 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id af79cd13be357-76595a7b111so93629885a.2 for ; Thu, 10 Aug 2023 12:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1691694439; x=1692299239; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=osZx9MFsTjA+0nKdtnzmcExs253v22D1JcCvOo2WUgU=; b=CrGiYGDgYC79bexKd3l7JPFKAwwigsGds4ZjU66r3w/rWcMQZMvcVpU6Jc3M9glE5b a6eGeyNZkBhnV20mRtRQ4O8ps+dn3sV/cw7K8As1cdTOhuC5cgbnliCtuPSrsZ5k/QYC Cru+gTxewyFKQQhU0DY5lm4pLtrEnCqnWeWnoSvZFTQhbA/1oHnxChPsSmlSxwn7Ewut Awnh5OiPRtt3hGM0viOKJ66zQhSOioUKxdE6l5VpwQSpdRXVn8gy2XU4OyRKMv4c6mqo 2id6eHaLk9ye4giWjZ3+2FkJdVtQ9yEJU/GKg/TA3Hs+0eSubTT57MlIblich7TnvqrY zfwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691694439; x=1692299239; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=osZx9MFsTjA+0nKdtnzmcExs253v22D1JcCvOo2WUgU=; b=b129n8uPKPZ8KR+J/8ryWu2eZA/S4Agp89AgDE0J6w6Kvu9VygQFiwsSniqd6Rfc8l DpNdZ+57+0uTTQ4p5GZY4TYeGIrMQIG21qx+ph0AQktioiGdft+Sdaa0x2cYs7wMIIwC UAjIHwTR6OqeAQ3QFi6q43VDzYCLp/osV2jspQw0ZpYoysziv4rluGia6jDAqa/jRXZp aeW/wWV9xfu39yHAOlvYwP5mQPbe5Yb4V33/uJ9pVcgdYVe1a5JhEEuPk7tviLUZdZKK /cMC4rENJ5N/Sa+/VPt9FEqmB4p8BYutNrmB0pejh5qO2cuppwxYL+Yn2Cg1NvD9E4oq V3cQ== X-Gm-Message-State: AOJu0YxghgtuxVOmsw1YMJZa55Rksx6SugHGcDh6dn+wSdxk7ZTSWGmI gjx+Tz/rmm6oecX1jnlPNLIzlA== X-Received: by 2002:a05:620a:f14:b0:76c:d958:d549 with SMTP id v20-20020a05620a0f1400b0076cd958d549mr3452297qkl.11.1691694439152; Thu, 10 Aug 2023 12:07:19 -0700 (PDT) Received: from ziepe.ca ([206.223.160.26]) by smtp.gmail.com with ESMTPSA id p17-20020a0cf551000000b00635eeb8a4fcsm684434qvm.114.2023.08.10.12.07.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Aug 2023 12:07:18 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1qUB09-005IkR-PB; Thu, 10 Aug 2023 16:07:17 -0300 Date: Thu, 10 Aug 2023 16:07:17 -0300 From: Jason Gunthorpe To: Lu Baolu Cc: Joerg Roedel , Will Deacon , Robin Murphy , Kevin Tian , Jean-Philippe Brucker , Nicolin Chen , Yi Liu , Jacob Pan , iommu@lists.linux.dev, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 10/12] iommu: Make iommu_queue_iopf() more generic Message-ID: References: <20230727054837.147050-1-baolu.lu@linux.intel.com> <20230727054837.147050-11-baolu.lu@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230727054837.147050-11-baolu.lu@linux.intel.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 27, 2023 at 01:48:35PM +0800, Lu Baolu wrote: > @@ -137,6 +136,16 @@ int iommu_queue_iopf(struct iommu_fault *fault, struct device *dev) > return 0; > } > > + if (fault->prm.flags & IOMMU_FAULT_PAGE_REQUEST_PASID_VALID) > + domain = iommu_get_domain_for_dev_pasid(dev, fault->prm.pasid, 0); > + else > + domain = iommu_get_domain_for_dev(dev); How does the lifetime work for this? What prevents UAF on domain? > diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c > index ab42cfdd7636..668f4c2bcf65 100644 > --- a/drivers/iommu/iommu-sva.c > +++ b/drivers/iommu/iommu-sva.c > @@ -157,7 +157,7 @@ EXPORT_SYMBOL_GPL(iommu_sva_get_pasid); > /* > * I/O page fault handler for SVA > */ > -enum iommu_page_response_code > +static enum iommu_page_response_code > iommu_sva_handle_iopf(struct iommu_fault *fault, void *data) > { > vm_fault_t ret; > @@ -241,23 +241,16 @@ static void iopf_handler(struct work_struct *work) > { > struct iopf_fault *iopf; > struct iopf_group *group; > - struct iommu_domain *domain; > enum iommu_page_response_code status = IOMMU_PAGE_RESP_SUCCESS; > > group = container_of(work, struct iopf_group, work); > - domain = iommu_get_domain_for_dev_pasid(group->dev, > - group->last_fault.fault.prm.pasid, 0); > - if (!domain || !domain->iopf_handler) > - status = IOMMU_PAGE_RESP_INVALID; > - > list_for_each_entry(iopf, &group->faults, list) { > /* > * For the moment, errors are sticky: don't handle subsequent > * faults in the group if there is an error. > */ > if (status == IOMMU_PAGE_RESP_SUCCESS) > - status = domain->iopf_handler(&iopf->fault, > - domain->fault_data); > + status = iommu_sva_handle_iopf(&iopf->fault, group->data); > } > > iopf_complete_group(group->dev, &group->last_fault, status); > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index 157a28a49473..535a36e3edc9 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -3330,7 +3330,7 @@ struct iommu_domain *iommu_sva_domain_alloc(struct device *dev, > domain->type = IOMMU_DOMAIN_SVA; > mmgrab(mm); > domain->mm = mm; > - domain->iopf_handler = iommu_sva_handle_iopf; > + domain->iopf_handler = iommu_sva_handle_iopf_group; > domain->fault_data = mm; This also has lifetime problems on the mm. The domain should flow into the iommu_sva_handle_iopf() instead of the void *data. The SVA code can then just use domain->mm directly. We need to document/figure out some how to ensure that the faults are all done processing before a fault enabled domain can be freed. This patch would be better ordered before the prior patch. Jason