linux-fscrypt.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eryu Guan <guaneryu@gmail.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: fstests@vger.kernel.org, linux-fscrypt@vger.kernel.org
Subject: Re: [RFC PATCH 3/9] common/encrypt: support checking for v2 encryption policy support
Date: Sun, 1 Sep 2019 20:08:06 +0800	[thread overview]
Message-ID: <20190901120320.GE2622@desktop> (raw)
In-Reply-To: <20190812175809.34810-4-ebiggers@kernel.org>

On Mon, Aug 12, 2019 at 10:58:03AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Allow passing '-v 2' to _require_scratch_encryption() to check for v2
> encryption policy support on the scratch device, and for xfs_io support
> for setting and getting v2 encryption policies.
> 
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  common/encrypt | 41 +++++++++++++++++++++++++++++++----------
>  1 file changed, 31 insertions(+), 10 deletions(-)
> 
> diff --git a/common/encrypt b/common/encrypt
> index a086e80f..fa6e2672 100644
> --- a/common/encrypt
> +++ b/common/encrypt
> @@ -6,12 +6,13 @@
>  
>  #
>  # _require_scratch_encryption [-c CONTENTS_MODE] [-n FILENAMES_MODE]
> +#			      [-v POLICY_VERSION]
>  #
>  # Require encryption support on the scratch device.
>  #
> -# This checks for support for the default type of encryption policy (AES-256-XTS
> -# and AES-256-CTS).  Options can be specified to also require support for a
> -# different type of encryption policy.
> +# This checks for support for the default type of encryption policy (v1 with
> +# AES-256-XTS and AES-256-CTS).  Options can be specified to also require
> +# support for a different type of encryption policy.
>  #
>  _require_scratch_encryption()
>  {
> @@ -68,13 +69,15 @@ _require_encryption_policy_support()
>  	local mnt=$1
>  	local dir=$mnt/tmpdir
>  	local set_encpolicy_args=""
> +	local policy_version=1
>  	local c
>  
>  	OPTIND=2
> -	while getopts "c:n:" c; do
> +	while getopts "c:n:v:" c; do
>  		case $c in
> -		c|n)
> +		c|n|v)
>  			set_encpolicy_args+=" -$c $OPTARG"
> +			[ $c = v ] && policy_version=$OPTARG

Why not checking 'v' in a separate case?

>  			;;
>  		*)
>  			_fail "Unrecognized option '$c'"
> @@ -87,10 +90,26 @@ _require_encryption_policy_support()
>  		>> $seqres.full
>  
>  	mkdir $dir
> -	_require_command "$KEYCTL_PROG" keyctl
> -	_new_session_keyring
> -	local keydesc=$(_generate_session_encryption_key)
> -	if _set_encpolicy $dir $keydesc $set_encpolicy_args \
> +	if (( policy_version > 1 )); then
> +		_require_xfs_io_command "get_encpolicy" "-t"
> +		local output=$(_get_encpolicy $dir -t)
> +		if [ "$output" != "supported" ]; then
> +			if [ "$output" = "unsupported" ]; then
> +				_notrun "kernel does not support $FSTYP encryption v2 API"
> +			fi
> +			_fail "Unexpected output from 'get_encpolicy -t'"

Print $output in the _fail message as well?

Thanks,
Eryu

> +		fi
> +		# Both the kernel and xfs_io support v2 encryption policies, and
> +		# therefore also filesystem-level keys -- since that's the only
> +		# way to provide keys for v2 policies.
> +		local raw_key=$(_generate_raw_encryption_key)
> +		local keyspec=$(_add_enckey $mnt "$raw_key" | awk '{print $NF}')
> +	else
> +		_require_command "$KEYCTL_PROG" keyctl
> +		_new_session_keyring
> +		local keyspec=$(_generate_session_encryption_key)
> +	fi
> +	if _set_encpolicy $dir $keyspec $set_encpolicy_args \
>  		2>&1 >>$seqres.full | egrep -q 'Invalid argument'; then
>  		_notrun "kernel does not support encryption policy: '$set_encpolicy_args'"
>  	fi
> @@ -103,7 +122,9 @@ _require_encryption_policy_support()
>  	if ! echo foo > $dir/file; then
>  		_notrun "encryption policy '$set_encpolicy_args' is unusable; probably missing kernel crypto API support"
>  	fi
> -	$KEYCTL_PROG clear @s
> +	if (( policy_version <= 1 )); then
> +		$KEYCTL_PROG clear @s
> +	fi
>  	rm -r $dir
>  }
>  
> -- 
> 2.23.0.rc1.153.gdeed80330f-goog
> 

  reply	other threads:[~2019-09-01 12:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-12 17:58 [RFC PATCH 0/9] xfstests: add tests for fscrypt key management improvements Eric Biggers
2019-08-12 17:58 ` [RFC PATCH 1/9] common/encrypt: disambiguate session encryption keys Eric Biggers
2019-08-12 17:58 ` [RFC PATCH 2/9] common/encrypt: add helper functions that wrap new xfs_io commands Eric Biggers
2019-08-12 17:58 ` [RFC PATCH 3/9] common/encrypt: support checking for v2 encryption policy support Eric Biggers
2019-09-01 12:08   ` Eryu Guan [this message]
2019-08-12 17:58 ` [RFC PATCH 4/9] common/encrypt: support verifying ciphertext of v2 encryption policies Eric Biggers
2019-08-12 17:58 ` [RFC PATCH 5/9] generic: add basic test for fscrypt API additions Eric Biggers
2019-08-12 17:58 ` [RFC PATCH 6/9] generic: add test for non-root use of " Eric Biggers
2019-08-12 17:58 ` [RFC PATCH 7/9] generic: verify ciphertext of v2 encryption policies with AES-256 Eric Biggers
2019-08-12 17:58 ` [RFC PATCH 8/9] generic: verify ciphertext of v2 encryption policies with AES-128 Eric Biggers
2019-08-12 17:58 ` [RFC PATCH 9/9] generic: verify ciphertext of v2 encryption policies with Adiantum Eric Biggers
2019-09-01 12:29 ` [RFC PATCH 0/9] xfstests: add tests for fscrypt key management improvements Eryu Guan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190901120320.GE2622@desktop \
    --to=guaneryu@gmail.com \
    --cc=ebiggers@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).