Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1079891yba; Fri, 26 Apr 2019 13:46:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqxcvfLyCf5k6bfrTVBmuvtjsWJXD/FfMe5wPVor/bKvFRhuVGnSrFd9D8WiVPRvnGhXCHpP X-Received: by 2002:a63:3746:: with SMTP id g6mr8840710pgn.422.1556311573009; Fri, 26 Apr 2019 13:46:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556311573; cv=none; d=google.com; s=arc-20160816; b=gcX1MKto/M8qDdC2GWdPuVLVeYTnlu9/sW+pWUWsILdU/dVt6DsPuGtO2fwWlHsIPx WCsQC/yCW1a+/xPPQ01M7c4j2Ygiq1mRv/lfDQPD+3VAKKsA3/MOLd//DSxmRVgyyefF MN51jfD3HCLlYAymjbbJaiAuToYhV1BdqxG5nr6Loc8fIItNADwB7+03sBryPPgCl8h0 QfR1plMEleV0sxPnwlWg/DBLiW+RFm+ZNtTvg66B3bTzgqR5X7MHFkjBLZEiAlZzGNe5 fctoi4b4bUokdg/LY8F5P1rH8UfKwpZlGUW26TT0FfcDIOWEehMc46+cfuPWXB6aZhzU 1w0w== 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:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=kXB1g4Q/liHvtVscRPvwjUG5OzhpKgLw2jqufJFRoFc=; b=qxC8gYCD8jDbh+aTpAhE9Qc62xl2WKhwt2Km/0U4gkzmKFQt68tnKAD2Uzc1rLxPl0 pvBNXB5yB98Onrr+pQa+lhL9rRtCsm6omaBVy1ttGm86GnabB6Q79jmjytfn0rqEX9xI xr0RNJd6aykJHZUgNiGP18YXHznd/0zcVImAaK4X6DY9J5liLmeUj145wJsgwlTpAGHV Dq2W+YXTk55r83cVuENTmAMuuSffLFVhV79YLMWlyNuR8qb1iV133L274UkY2bBdnITm XuCAkXYVabQpS9ncFm3LZjGkIPmHQTGORy3FycdAsyGnRuu52Vfga8fTishPatn1sHb0 E2kg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=iNe0bkY5; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id g2si25505222pgi.19.2019.04.26.13.45.53; Fri, 26 Apr 2019 13:46:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=iNe0bkY5; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 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 S1726974AbfDZUpl (ORCPT + 99 others); Fri, 26 Apr 2019 16:45:41 -0400 Received: from mail.kernel.org ([198.145.29.99]:45048 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725966AbfDZUpl (ORCPT ); Fri, 26 Apr 2019 16:45:41 -0400 Received: from ebiggers-linuxstation.mtv.corp.google.com (unknown [104.132.1.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 30C4D2084F; Fri, 26 Apr 2019 20:45:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556311539; bh=QBzsfd+MU5VtO+7hIbVdsXDNdbivvbWInMAeH9h0hHo=; h=From:To:Cc:Subject:Date:From; b=iNe0bkY5yOnxzpYoourHgxIUR4Db5Tzu1vlm5a2zsmJ4m8mFyuCdBA4H7y96+VSp2 oAk/OcJXiUAqdxnHuL/ZQ0/5E42UGJ3tqOw80lzuhyA4v1uoiZiTLme+p1mYojKYWm xgDtT5E2ZcoT8+QXcp63C93yLN5SUXHeHgWkeCqQ= From: Eric Biggers To: fstests@vger.kernel.org Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: [RFC PATCH 0/7] xfstests: verify fscrypt-encrypted contents and filenames Date: Fri, 26 Apr 2019 13:41:46 -0700 Message-Id: <20190426204153.101861-1-ebiggers@kernel.org> X-Mailer: git-send-email 2.21.0.593.g511ec345e18-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hello, This series adds xfstests which verify that encrypted contents and filenames on ext4 and f2fs are actually correct, i.e. that the encryption uses the correct algorithms, keys, IVs, and padding amounts. The new tests work by creating encrypted files, unmounting the filesystem, reading the ciphertext from disk using dd and debugfs or dump.f2fs, and then comparing it against ciphertext computed independently by a new test program that implements the same algorithms. These tests are important because: - The whole point of file encryption is that the files are actually encrypted correctly on-disk. Except for generic/399, current xfstests only tests the filesystem semantics, not the actual encryption. generic/399 only tests for incompressibility of encrypted file contents using one particular encryption setting, which isn't much. - fscrypt now supports 4 main combinations of encryption settings, rather than 1 as it did originally. This may be doubled to 8 soon (https://patchwork.kernel.org/patch/10908153/). We should test all settings. And without tests, even if the initial implementation is correct, breakage in one specific setting could go undetected. - Though Linux's crypto API has self-tests, these only test the algorithms themselves, not how they are used, e.g. by fscrypt. Patch 1 is a cleanup patch. Patches 2-4 add the common helpers for ciphertext verification tests. Patches 5-7 add the actual tests. These tests require e2fsprogs and f2fs-tools patches I recently sent out to fix printing encrypted filenames. So, this series might not be suitable for merging into mainline xfstests until those patches are applied. Regardless, comments are appreciated. The needed patches are: debugfs: avoid ambiguity when printing filenames (https://marc.info/?l=linux-ext4&m=155596495624232&w=2) f2fs-tools: improve filename printing (https://sourceforge.net/p/linux-f2fs/mailman/message/36648641/) This series can also be retrieved from git at https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/xfstests-dev.git branch "ciphertext-verification". I also have patches on top of this series which verify the ciphertext produced from v2 encryption policies, which are proposed by my kernel patch series "fscrypt: key management improvements" (https://patchwork.kernel.org/cover/10908107/). v2 encryption policies will use a different key derivation function, and thus their ciphertext will be different. These additional patches can be found at branch "fscrypt-key-mgmt-improvements" of my git repo above. But I've arranged things such that this shorter series can potentially be applied earlier, to test what's in the kernel now. Eric Biggers (7): common/encrypt: introduce helpers for set_encpolicy and get_encpolicy fscrypt-crypt-util: add utility for reproducing fscrypt encrypted data common/encrypt: support requiring other encryption settings common/encrypt: add helper for ciphertext verification tests generic: verify ciphertext of v1 encryption policies with AES-256 generic: verify ciphertext of v1 encryption policies with AES-128 generic: verify ciphertext of v1 encryption policies with Adiantum .gitignore | 1 + common/encrypt | 482 ++++++++++- src/Makefile | 3 +- src/fscrypt-crypt-util.c | 1645 ++++++++++++++++++++++++++++++++++++++ tests/ext4/024 | 3 +- tests/generic/395 | 28 +- tests/generic/395.out | 2 +- tests/generic/396 | 15 +- tests/generic/397 | 3 +- tests/generic/398 | 5 +- tests/generic/399 | 3 +- tests/generic/419 | 3 +- tests/generic/421 | 3 +- tests/generic/429 | 3 +- tests/generic/435 | 3 +- tests/generic/440 | 5 +- tests/generic/700 | 41 + tests/generic/700.out | 5 + tests/generic/701 | 41 + tests/generic/701.out | 5 + tests/generic/702 | 43 + tests/generic/702.out | 10 + tests/generic/group | 3 + 23 files changed, 2308 insertions(+), 47 deletions(-) create mode 100644 src/fscrypt-crypt-util.c create mode 100755 tests/generic/700 create mode 100644 tests/generic/700.out create mode 100755 tests/generic/701 create mode 100644 tests/generic/701.out create mode 100755 tests/generic/702 create mode 100644 tests/generic/702.out -- 2.21.0.593.g511ec345e18-goog