Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp878253ybg; Wed, 10 Jun 2020 16:36:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwYr5Yh6f8Z3LwuLYF37O0bMnGtshXl32ka8ba98N79EU0Er6oc2+X7Ukf3ydECged2ZK6B X-Received: by 2002:a17:907:369:: with SMTP id rs9mr5609405ejb.187.1591832180521; Wed, 10 Jun 2020 16:36:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591832180; cv=none; d=google.com; s=arc-20160816; b=dTL3ovmDeAMv3XDEu+WBvksGTFv0XoQRfPV1Z7ZI2CMvjrXD8WpTQAh1mN/kwrwJsJ DqG0EhS3/D1+wMnzNEZZq+IJ8fZCCrgGNJJavdPbg5kASHd+C0pggflFBpCQMr+3rxBA Z5/ciozgbfibOTMHDRoBUvcpRQA91sp6qWm7SNfksXd14FUccEgq6z8sbRQzn/EmZvu8 Lu8YIzICygNSEr8cUPhnASZcVzeeqfglWPzc1yNzQnrshPTuUHeDuUdOmKr3RlxrnaFv V0CQYPKaTvNEonD6s/4a8sD6gFpRpQ70ZaBGgglp6gYdmK5LtgTFkbPEyf1ydTG5Ty01 5PFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=tHyLqUmtTTMIbIqoDwVSMrkpYuG5yIqYL6HxByUSF1k=; b=g77gVVlwVH89Bf6LiUurcrYmLs/xMnNqj1Hfs4NyR7pFjDDCmobGPmStWFqRfH41uR zgcknGa7nmkVwmK5L2FOh58QLHNOxpvdfHSYiuuPxXkKO9GxsK7WiocJUBKeV/qkk+nc 9g3dGddMNjMbyMHsAo0/BGCfIKsNplsy09JS5wmtD4B1aRFYBNflyKT7YUx0WaDt0abu DzhoMpPMwmAufr0OSXXlgB7EUVosCPRhkQidnWBwkVHtmr1Fba5OoSQ+bkCuo0hRKJoL Jqcyk8kfCtPWKH2LMAKWeGM1aiKknC7cMBdH0URHT5Qev7szu/YDyLId0fhwYOaKvpZD Oiig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XG9A+T23; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dp6si987767ejc.472.2020.06.10.16.35.56; Wed, 10 Jun 2020 16:36:20 -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=@gmail.com header.s=20161025 header.b=XG9A+T23; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726881AbgFJXbf (ORCPT + 99 others); Wed, 10 Jun 2020 19:31:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726374AbgFJXbe (ORCPT ); Wed, 10 Jun 2020 19:31:34 -0400 Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D63DFC03E96B for ; Wed, 10 Jun 2020 16:31:32 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id n23so4649819ljh.7 for ; Wed, 10 Jun 2020 16:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tHyLqUmtTTMIbIqoDwVSMrkpYuG5yIqYL6HxByUSF1k=; b=XG9A+T23tcxH5dzLrr0ymPt9XR35a61ozhwFwcrizTaPccaz9PvTnfAwC6+xJe1Z32 bQhAZj7s4dptgCg/IUpHZopInAaxskDR5LI7XPW1MILHn0fk8E+x6zcGc6ilRrbp8SnT 0VL2rAodo13s6qbJTM69fmuhCZ9qbEVDVdV/2Zz+cB/lML5pIoOSGlF/0d2OEVoYGTCK OVIjFc/CcuNMS/VhJcZZ3ZY0cLO0MwTvwS8WkKRkL2HVZXP+3BbcKE7YIkvRBL5UVPwz WAZkh9HrMoFlVUtr9z7OnyENLfUF+7/yqwuTBZFZJ9HiNSPWJhV3i4RijqKxyVTSBW1G eSww== 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:content-transfer-encoding; bh=tHyLqUmtTTMIbIqoDwVSMrkpYuG5yIqYL6HxByUSF1k=; b=K8pxtCDGhaQ+dMzIAtLnujp9ygLKbzYsndEucc69BytSMFxGijh92oN4IqEAWgd/J+ Kw9yauoJqfOpLcfZxb9HBdv54nPjtF4a8sLek3TSWY6+poTfyofTU8bStTBwf6NfpMoN 1FrISzU2hfsLujEJQf6KRPHgC2P7OdvBxCH47lVl2f6xSM2jd+WFXy0Mw9iD9UMNgB7v dLKLb1gkt7cLqIKQDbw2YsWPf7aXouPkIL5YgpUBcBz85lefwbdXlnhdf83tohjcbiZS +NFHk05EmbkiLjS1/y/V5w6QE1R4e19TWif2Fwy64e5H2Lt5s2u6m57JmTmtN0Md0MWj zr7w== X-Gm-Message-State: AOAM531Yvp+vsyGOK/6TZ2N/lNzpSH04Q7Jq8vJcN9VmWgPxWOCe5cAb HfSJRDiGihvni1M2KxeihhN/FzSMSO0Ih7ISBFLmHJXNAflZjw== X-Received: by 2002:a2e:92cf:: with SMTP id k15mr2988702ljh.333.1591831891058; Wed, 10 Jun 2020 16:31:31 -0700 (PDT) MIME-Version: 1.0 References: <20200609060137.143501-1-daeho43@gmail.com> <20200609165107.GA228564@gmail.com> <20200610031532.GA6286@sol.localdomain> In-Reply-To: From: Daeho Jeong Date: Thu, 11 Jun 2020 08:31:20 +0900 Message-ID: Subject: Re: [f2fs-dev] [PATCH] f2fs: add F2FS_IOC_SEC_TRIM_FILE ioctl To: Eric Biggers Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com, Daeho Jeong Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > > > + > > > > > + if (f2fs_readonly(sbi->sb)) > > > > > + return -EROFS; > > > > > > > > Isn't this redundant with mnt_want_write_file()? > > > > > > > > Also, shouldn't write access to the file be required, i.e. > > > > (filp->f_mode & FMODE_WRITE)? Then the f2fs_readonly() and > > > > mnt_want_write_file() checks would be unnecessary. > > > > > > > > > > Using FMODE_WRITE is more proper for this case, since we're going to > > > modify the data. But I think mnt_want_write_file() is still required > > > to prevent the filesystem from freezing or something else. > > > > Right, the freezing check is actually still necessary. But getting wri= te access > > to the mount is not necessary. I think you should use file_start_write= () and > > file_end_write(), like vfs_write() does. I've checked this again. But I think mnt_want_write_file() looks better than the combination of checking FMODE_WRITE and file_start_write(), because mnt_want_write_file() handles all the things we need. It checks FMODE_WRITER, which is set in do_dentry_open() when FMODE_WRITE is already set, and does the stuff that file_start_write() is doing. This is why the other filesystem system calls use it. What do you think? 2020=EB=85=84 6=EC=9B=94 10=EC=9D=BC (=EC=88=98) =EC=98=A4=ED=9B=84 12:55, = Daeho Jeong =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > > > > > > To prevent the file data from garbage collecting, the user needs to > > > use pinfile ioctl and fallocate system call after creating the file. > > > The sequence is like below. > > > 1. create an empty file > > > 2. pinfile > > > 3. fallocate() > > > > Is that persistent? So the file will never be moved afterwards? > > > > Is there a place where this is (or should be) documented? > > Yes, this is persistent. F2FS_IOC_SET_PIN_FILE ioctl is to prevent > file data from moving and being garbage collected, and further update > to the file will be handled in in-place update manner. > I don't see any document on this, but you can find the below in > Documentation/filesystems/f2fs.rst > > However, once F2FS receives ioctl(fd, F2FS_IOC_SET_PIN_FILE) in prior to > fallocate(fd, DEFAULT_MODE), it allocates on-disk blocks addresses having > zero or random data, which is useful to the below scenario where: > > 1. create(fd) > 2. ioctl(fd, F2FS_IOC_SET_PIN_FILE) > 3. fallocate(fd, 0, 0, size) > 4. address =3D fibmap(fd, offset) > 5. open(blkdev) > 6. write(blkdev, address) > > > Right, the freezing check is actually still necessary. But getting wri= te access > > to the mount is not necessary. I think you should use file_start_write= () and > > file_end_write(), like vfs_write() does. > > Yes, agreed. > > 2020=EB=85=84 6=EC=9B=94 10=EC=9D=BC (=EC=88=98) =EC=98=A4=ED=9B=84 12:15= , Eric Biggers =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > > > On Wed, Jun 10, 2020 at 11:05:46AM +0900, Daeho Jeong wrote: > > > > > Added a new ioctl to send discard commands or/and zero out > > > > > to whole data area of a regular file for security reason. > > > > > > > > With this ioctl available, what is the exact procedure to write and= then later > > > > securely erase a file on f2fs? In particular, how can the user pre= vent f2fs > > > > from making multiple copies of file data blocks as part of garbage = collection? > > > > > > > > > > To prevent the file data from garbage collecting, the user needs to > > > use pinfile ioctl and fallocate system call after creating the file. > > > The sequence is like below. > > > 1. create an empty file > > > 2. pinfile > > > 3. fallocate() > > > > Is that persistent? So the file will never be moved afterwards? > > > > Is there a place where this is (or should be) documented? > > > > > > > + > > > > > + if (f2fs_readonly(sbi->sb)) > > > > > + return -EROFS; > > > > > > > > Isn't this redundant with mnt_want_write_file()? > > > > > > > > Also, shouldn't write access to the file be required, i.e. > > > > (filp->f_mode & FMODE_WRITE)? Then the f2fs_readonly() and > > > > mnt_want_write_file() checks would be unnecessary. > > > > > > > > > > Using FMODE_WRITE is more proper for this case, since we're going to > > > modify the data. But I think mnt_want_write_file() is still required > > > to prevent the filesystem from freezing or something else. > > > > Right, the freezing check is actually still necessary. But getting wri= te access > > to the mount is not necessary. I think you should use file_start_write= () and > > file_end_write(), like vfs_write() does. > > > > > > > > > > > + > > > > > + if (get_user(flags, (u32 __user *)arg)) > > > > > + return -EFAULT; > > > > > + if (!(flags & F2FS_TRIM_FILE_MASK)) > > > > > + return -EINVAL; > > > > > > > > Need to reject unknown flags: > > > > > > > > if (flags & ~F2FS_TRIM_FILE_MASK) > > > > return -EINVAL; > > > > > > I needed a different thing here. This was to check neither discard no= r > > > zeroing out are not here. But we still need to check unknown flags, > > > too. > > > The below might be better. > > > if (!flags || flags & ~F2FS_TRIM_FILE_MASK) > > > return -EINVAL; > > > > Sure, but please put parentheses around the second clause: > > > > if (flags =3D=3D 0 || (flags & ~F2FS_TRIM_FILE_MASK)) > > return -EINVAL; > > > > - Eric