From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: Proposal: A new fs-verity interface Date: Tue, 15 Jan 2019 10:41:01 +1100 Message-ID: <20190114234101.GQ27534@dastard> References: <20190110051500.GA32361@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Eric Biggers , "Darrick J. Wong" , linux-f2fs-devel@lists.sourceforge.net, Christoph Hellwig , linux-fscrypt@vger.kernel.org, linux-fsdevel , linux-ext4@vger.kernel.org, Linus Torvalds To: "Theodore Y. Ts'o" Return-path: Content-Disposition: inline In-Reply-To: <20190110051500.GA32361@mit.edu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net List-Id: linux-fsdevel.vger.kernel.org On Thu, Jan 10, 2019 at 12:15:00AM -0500, Theodore Y. Ts'o wrote: > The following approach is based in Darrick's suggestion: I do not recall what that was, so this: > int ioctl(fd, FS_IOC_ENABLE_VERITY, struct fsverity_arg *arg); > > struct fsverity_arg { > int fsv_donor_fd; > u64 fsv_offset; > u64 fsv_size; > }; > > fsv_offset and fsz_size must be a multiple of the file system block > size. If the ioctl comples successfully, as a side effect the > donor_fd will have a hole punch operation on the specified range. In > other words, the equivalent of operation of fallocate(fsv_donor_fd, > FALLOC_FL_PUNCH_HOLE, fsv_offset, fsv_size), and the file specified by > fd will be protected using fsverity. makes no sense to me. What's in {offset, size} and why do you need to call this on that specific range? If it is the equivalent of a hole punch, then why wouldn't you just use FALLOC_FL_PUNCH_HOLE? Can you please write the man page for the interface so that the description of what it does and how it should be used is crystal clear and doesn't assume the reader knows "what darrick proposed"... Cheers, Dave. -- Dave Chinner david@fromorbit.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A78BDC43387 for ; Mon, 14 Jan 2019 23:41:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7D3FC20659 for ; Mon, 14 Jan 2019 23:41:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727188AbfANXlF (ORCPT ); Mon, 14 Jan 2019 18:41:05 -0500 Received: from ipmail07.adl2.internode.on.net ([150.101.137.131]:36617 "EHLO ipmail07.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727169AbfANXlF (ORCPT ); Mon, 14 Jan 2019 18:41:05 -0500 Received: from ppp59-167-129-252.static.internode.on.net (HELO dastard) ([59.167.129.252]) by ipmail07.adl2.internode.on.net with ESMTP; 15 Jan 2019 10:11:02 +1030 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1gjBqn-0000Gf-Cu; Tue, 15 Jan 2019 10:41:01 +1100 Date: Tue, 15 Jan 2019 10:41:01 +1100 From: Dave Chinner To: "Theodore Y. Ts'o" Cc: Linus Torvalds , Christoph Hellwig , "Darrick J. Wong" , Eric Biggers , linux-fscrypt@vger.kernel.org, linux-fsdevel , linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: Proposal: A new fs-verity interface Message-ID: <20190114234101.GQ27534@dastard> References: <20190110051500.GA32361@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190110051500.GA32361@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Message-ID: <20190114234101.DVU4toNG1qhlvsxBcS7ZAPGGnGqtx0PxigqAy-Cw1tc@z> On Thu, Jan 10, 2019 at 12:15:00AM -0500, Theodore Y. Ts'o wrote: > The following approach is based in Darrick's suggestion: I do not recall what that was, so this: > int ioctl(fd, FS_IOC_ENABLE_VERITY, struct fsverity_arg *arg); > > struct fsverity_arg { > int fsv_donor_fd; > u64 fsv_offset; > u64 fsv_size; > }; > > fsv_offset and fsz_size must be a multiple of the file system block > size. If the ioctl comples successfully, as a side effect the > donor_fd will have a hole punch operation on the specified range. In > other words, the equivalent of operation of fallocate(fsv_donor_fd, > FALLOC_FL_PUNCH_HOLE, fsv_offset, fsv_size), and the file specified by > fd will be protected using fsverity. makes no sense to me. What's in {offset, size} and why do you need to call this on that specific range? If it is the equivalent of a hole punch, then why wouldn't you just use FALLOC_FL_PUNCH_HOLE? Can you please write the man page for the interface so that the description of what it does and how it should be used is crystal clear and doesn't assume the reader knows "what darrick proposed"... Cheers, Dave. -- Dave Chinner david@fromorbit.com