Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2846314pxb; Mon, 19 Apr 2021 15:54:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyb4y4yjUrBadNSaAFrizYnLgH8T8dXIYpznoUUwXadmOccveJ85qnBwrTk4WgQP2F+CMha X-Received: by 2002:a63:6ec1:: with SMTP id j184mr13972803pgc.364.1618872857199; Mon, 19 Apr 2021 15:54:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618872857; cv=none; d=google.com; s=arc-20160816; b=UNcj5YhJCFI1CHnj5GWU27Una+QooZw0RQh9myZNdnmqZgyWhzsWdvIWSZulyVzUxF M/8OS0EAWBm77ejb3MMF1Aa0QuIEUB6ccElQj9CK/uLZ2vl7tsA0RI3dRzzDqLjfRyxq oV8rjWeFqFd02iAZBeRsQV1DVlf5F80pGWmsPZSEUFnjsuYXY6Kpdq67tPopq1dbzBCg VGiP3B2sJnRO5PctIhDb3bM0XEedomRa/TKjHQoK5pLONfyUYJaZBFCFIHbo3+Trlsvw vg5F93uhy2xMs6e5wY3Fiu0asSQLuS3p1fy2HgZoYTGxYXO1Qf1spPehzWo9xlozHeiP sIow== 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=CUZjpyjVfZJ917uSir3/ajyX9vDvZqc3Re3FA4NdcU4=; b=wlKCLdZAhh0OGkeONFXZJwkCTw7M6AU88anIcludD+rHW26CqeK3EbbY749YdyBJXM MefzFdFbpp5Ymri4rzl6D7UwbSuWnRMfwh8/4084dr/h0jOjvKP2wvMX5P9tDlTEottG DWp0qL3A0RQe9M27BB8IaXOUBE9Azk8jmEdQ5v73LhEByAAIs/ocY/jpyAIs8ggqC0ZX ScrhzhoiGcX6HkyD967V1W4x/pE2zxtYVf+Kco7ZR/mg5SvFLvStgWk6lXqbMKkP6tbQ wXfBF8Y1yc9LibUvitsq0ikB8ZP5tY8DNGgD7CkKmdq3H7PZFgv1E0KmeNZgZDOwCtfJ H2eA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=DhQY2ji4; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i19si19296431pgb.524.2021.04.19.15.53.56; Mon, 19 Apr 2021 15:54:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-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=@kernel.org header.s=k20201202 header.b=DhQY2ji4; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229718AbhDSWyY (ORCPT + 99 others); Mon, 19 Apr 2021 18:54:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:55914 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229681AbhDSWyY (ORCPT ); Mon, 19 Apr 2021 18:54:24 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0D58B60FF1; Mon, 19 Apr 2021 22:53:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618872834; bh=vmca3TN6y61NV3O1qxeh+me1eGIPDrZgpmPtfmFcpjI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DhQY2ji42qmejsWXGF3GxQEZqDO3iTOZwUkWOHtDtjGa7tGac6UG/J+MUj4zlTexM ixwDjqJ7sT3bdG8BKRQzKM4OqzuolLEWelwGwwpX5xOHqK5J/dF/xQZsJgCzxlLiNQ QdgRoSsMq4lAcL82NJ5G/exCFrS7T/JlGZre8jMAXKtRf/6/3AYZuBsDbNkAkCRBVP nxmLouZak7WLe/4gq4oOfM1FXn5SFUGd6+LXAamRNO5Xu882lw0/9KS34xiC7hrU1h xojQtuHMgDZxqyn2bcYPOXWmLAbcTrS1efgWR9kevdXFuq2UCokf9Fmv+JkRSstxHx 0XA2bZjT2W3wg== Date: Mon, 19 Apr 2021 15:53:52 -0700 From: Eric Biggers To: Leah Rumancik Cc: linux-ext4@vger.kernel.org, tytso@mit.edu Subject: Re: [PATCH v3] ext4: wipe filename upon file deletion Message-ID: References: <20210419162100.1284475-1-leah.rumancik@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210419162100.1284475-1-leah.rumancik@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Mon, Apr 19, 2021 at 04:21:00PM +0000, Leah Rumancik wrote: > Upon file deletion, zero out all fields in ext4_dir_entry2 besides inode > and rec_len. In case sensitive data is stored in filenames, this ensures > no potentially sensitive data is left in the directory entry upon deletion. > Also, wipe these fields upon moving a directory entry during the conversion > to an htree and when splitting htree nodes. This should include more explanation about why this is useful, and what its limitations are (e.g. how do the properties of the storage device affect whether the filename is *really* deleted)... > diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c > index 883e2a7cd4ab..df7809a4821f 100644 > --- a/fs/ext4/namei.c > +++ b/fs/ext4/namei.c > @@ -1778,6 +1778,11 @@ dx_move_dirents(char *from, char *to, struct dx_map_entry *map, int count, > ((struct ext4_dir_entry_2 *) to)->rec_len = > ext4_rec_len_to_disk(rec_len, blocksize); > de->inode = 0; > + > + /* wipe name_len through and name field */ > + memset(&de->name_len, 0, ext4_rec_len_from_disk(de->rec_len, > + blocksize) - 6); > + The comment is confusing. IMO it would make more sense to mention what is *not* being zeroed: /* wipe the dir_entry excluding the rec_len field */ de->inode = 0; memset(&de->name_len, 0, ext4_rec_len_from_disk(de->rec_len, blocksize) - 6); > @@ -2492,6 +2498,11 @@ int ext4_generic_delete_entry(struct inode *dir, > else > de->inode = 0; > inode_inc_iversion(dir); > + > + /* wipe name_len through name field */ > + memset(&de->name_len, 0, > + ext4_rec_len_from_disk(de->rec_len, blocksize) - 6); > + > return 0; And maybe here too, although here why is the condition for setting the inode to 0 not the same as the condition for zeroing the other fields? Also, maybe use offsetof(struct ext4_dir_entry_2, name_len) instead of '6'... - Eric