From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D8CA37BE6A for ; Fri, 22 May 2026 19:29:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779478170; cv=none; b=smQPMLIZ2vpl6AH0iUqdiYoNuAgsx+9+4RuowzhDvctAe5hYPOZh+tRhSXgGQkeAFkPqdaW+HyjqSkjlpEtSWUyr16RahK405SSZDg4XH7/VZzyGn6T6OcrS2EAu50Xwv9HifTxZkLoasL8DRwendPJwTOxqZnyP7hAUwERAj30= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779478170; c=relaxed/simple; bh=ffzvcdohYfK2Nhcc6YKxgUldy2MbL1zw2CegD7bxo5g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=svf6wxCDPjYvuWjqaSvgLuZ24N02wxnPtHAiC3vfo7P1KsV0X5NsXv8S4GRCgu34y9XaENn98VbhNrFbLP0YN5pD8Kr7C/C1/Sc4qvq/ImQZI095JwmCLQ9QL57vi7LaGF+U4dUMG2+b1qbUgK6JiuY/kw63WGF/Qa5vrkcrAgQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=MKuHknHA; arc=none smtp.client-ip=209.85.214.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MKuHknHA" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2ba180a022dso795ad.1 for ; Fri, 22 May 2026 12:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779478168; x=1780082968; darn=vger.kernel.org; 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=6rXutVjEtLFCH+2KhZxwAs98V/nz+fnBuy6pdFon3Xw=; b=MKuHknHA+uK7OFtqGD9Vt8RZuG37VqaX+LHhb3O/JsqQD394shaLmVAk9ZWnBA+Rbs VFNzdiOOpDyeYPJSYCYMfdman2t52svpSCNm3vgMPPvCXY+XdtItwduwrX4mHoY8E7f4 blWwe4I/zRoBfWFN4HMiq395N7DKnD97nyz38b/6c9jYLWj0PitTpUwFzXrC/etUfr97 LwJzyu5J6+eaQfD0KoVc1slkLh4WbsQun90GaxjwH69HE+JJealOuEAlP6W082VkI66X GDX/o4hdzw7BVtzdxeA1i7Esn1dpdPHY5fdacpRFiGxcMzVCMGvRPog36kZn8BiQZ3cN JC6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779478168; x=1780082968; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6rXutVjEtLFCH+2KhZxwAs98V/nz+fnBuy6pdFon3Xw=; b=GUyk6Bi1jO6Bcwz7yQtINClaAOWKzDj4KmCRxqW3dxS2sFGmZF34N/Y/FZIpoxSviZ FhnNOorSUfZZgDn3OYabMh/ABbgSHGtwcweGM3b4pnjH2pffRAnqJHZxT10AQE6at38E Sg0isU8bE/nWdj/B898POza43/Uik7wNd3e3VU4p4n0f24Sau9t2MEI1ifuo6PWt0Ezs k6AerdtqOSjJffdzkPnJ+1gJD3RBQr0Kl71dkJPN1Rd2JlSh4utHZWzdnp9+a/KRkNJG UX5PZ9AnpdH5+j11Rp1xtTioOBjPYiKN10W7e1yUeJEmzlJU/P+sC5csPnuQ4OHPsWHY lZgw== X-Forwarded-Encrypted: i=1; AFNElJ/5SwmaYonVp28DgbxNZnVbvhGidYdqMKLcrmHYsrM9FOto/HKvTGEvUgiDeYvd0pYeNvx1v0C4KydL+nQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yzo3CYd+9cCMiVuMFIPMKWmLrlKTuRQlOernl11b3NfNfneHm4f OisCjx+B5E8SlrAJ864JVmFkYyY9KvO1e+XP1Z4fnFIAVqGZdFw8RXeGNKeydQ8WkntoV4EqShN uFLoIcg== X-Gm-Gg: Acq92OFaJvqun4aUJ0jhaRS4TmzoOO+coz42o52a0fn4BLK85kNCt83HNqt/eP1L1LU /3Q09+aezCdYZ6kqfer+BvVhlvKAygN4GsOucvBc4sXwT5XDkWeYy2Il3JWBvl3ax2DpS4uCTXw /hvJ56Iv4j4lUVwQUA5GXdQlJwz31M0yxKxK+G0DQYqLbuDnvP/DSH+1ebbIspX8/wO4A98Grez xH+OsERrNX6lzKjuyHeAfRPn7QX4d7wHiO4A1yKHuSo6rPmVa1LxNxFwzOwPar536tjWwKeUMOh rCCzRHdQCWpIBWzaKulBnT2bdbEiW+9pbzge9WX92N+MZ/smCTMSCRYc+p2SzxzXxnaqHv+h9WV 4D99PPBqZYB6d8ryXT3CSQvisw9qyrWj6ZxcuNGXA1VuDFeEEegTxwLP1fJ8zPX2auZJAy8l3U1 Zuif5Dtcz5sHDCXLgkuSXOYyo7iKjzTKeYqQF1BmsUjkIYFymbmxGdtHG9HIcLyo+YlKBA X-Received: by 2002:a17:903:17c4:b0:2a8:ffed:4663 with SMTP id d9443c01a7336-2bebe9eff1amr388115ad.12.1779478167409; Fri, 22 May 2026 12:29:27 -0700 (PDT) Received: from google.com (44.234.124.34.bc.googleusercontent.com. [34.124.234.44]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84164ac9c77sm2981586b3a.2.2026.05.22.12.29.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2026 12:29:26 -0700 (PDT) Date: Fri, 22 May 2026 19:29:18 +0000 From: Pranjal Shrivastava To: Samiullah Khawaja Cc: David Woodhouse , Lu Baolu , Joerg Roedel , Will Deacon , Jason Gunthorpe , YiFei Zhu , Robin Murphy , Kevin Tian , Alex Williamson , Shuah Khan , iommu@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Saeed Mahameed , Adithya Jayachandran , Parav Pandit , Leon Romanovsky , William Tu , Pratyush Yadav , Pasha Tatashin , David Matlack , Andrew Morton , Chris Li , Vipin Sharma Subject: Re: [PATCH v2 13/16] iommufd: Persist iommu hardware pagetables for live update Message-ID: References: <20260427175633.1978233-1-skhawaja@google.com> <20260427175633.1978233-14-skhawaja@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, May 22, 2026 at 04:01:43PM +0000, Pranjal Shrivastava wrote: > On Wed, May 20, 2026 at 07:40:05PM +0000, Samiullah Khawaja wrote: > > On Wed, May 20, 2026 at 12:00:44AM +0000, Pranjal Shrivastava wrote: > > > On Mon, Apr 27, 2026 at 05:56:30PM +0000, Samiullah Khawaja wrote: > [...] > > > > > #include "double_span.h" > > > > @@ -1421,6 +1422,7 @@ struct iopt_pages *iopt_alloc_file_pages(struct file *file, > > > > > > > > { > > > > struct iopt_pages *pages; > > > > + int seals; > > > > > > > > pages = iopt_alloc_pages(start_byte, length, writable); > > > > if (IS_ERR(pages)) > > > > @@ -1428,6 +1430,11 @@ struct iopt_pages *iopt_alloc_file_pages(struct file *file, > > > > pages->file = get_file(file); > > > > pages->start = start - start_byte; > > > > pages->type = IOPT_ADDRESS_FILE; > > > > + > > > > + seals = memfd_get_seals(file); > > > > + if (seals > 0) > > > > + pages->seals = seals; > > > > + > > > > > > Can caching memfd seals create a TOCTOU issue? > > > IIUC, iopt_alloc_file_pages happens at map time, However, the userspace > > > is allowed to map a memfd and then apply the F_ADD_SEALS via fcntl() > > > later in its setup sequence? For example a sequence like: > > > > > > 1. VMM creates a memfd. It has 0 seals. > > > 2. VMM calls IOMMU_IOAS_MAP_FILE. IOMMUFD caches pages->seals = 0. > > > 3. VMM finishes its setup and calls: > > > fcntl(fd, F_ADD_SEALS, F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_SEAL). > > > > > > 4.VMM initiates Live Update. > > > 5.check_iopt_pages_preserved looks at the cached pages->seals > > > (which is still 0), sees the seals are missing, & kills the LiveUpdate > > > with -EINVAL, even though the file is properly sealed.. > > > > This is true and it is intentionally this way to make sure that the seal > > is applied during mapping otherwise user can apply the seal after > > resizing the memfd and preserve IOMMU mappings that are pointing to > > unpreserved pages. Consider following: > > > > 1. VMM creates a memfd and seals is zero. > > 2. VMM maps memfd into ioas/hwpt. > > 3. VMM resizes the memfd. > > 4. VMM seals memfd > > 5. VMM preserves the memfd (it only preseves the current size). > > 6. VMM preserves iommufd and it succeeds as memfd is sealed. > > > > But the pages being referred by the iommu mappings are refcounted in > > current kernel, but not preserved. > > > > Check the comment in check_iopt_pages_preserved() also. I will add a > > comment here also. > > > > > I understand the intent to enforce a policy to Seal-at-Map to ensure > consistency. I am wondering if this policy is a little too restrictive. > Should we consider performing a dynamic i_size check during preservation > instead? I can't think of a good use-case as of now.. (maybe let it be?) On another thought, I guess we should go ahead with the current policy, to ensure we preserve the right pages. If an unsealed file is shrunk and then grown back to its original size before preservation we might have a problem. We can ignore this comment. Thanks, Praan