Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To: "dsterba@suse.cz" <dsterba@suse.cz>, Johannes Thumshirn <jth@kernel.org>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	Eric Biggers <ebiggers@google.com>,
	Richard Weinberger <richard@nod.at>,
	Johannes Thumshirn <jthumshirn@suse.de>
Subject: Re: [PATCH v3 2/3] btrfs: add authentication support
Date: Wed, 27 May 2020 13:54:51 +0000	[thread overview]
Message-ID: <SN4PR0401MB3598593BC0AF9909CC1986889BB10@SN4PR0401MB3598.namprd04.prod.outlook.com> (raw)
In-Reply-To: <20200527132428.GE18421@twin.jikos.cz>

On 27/05/2020 15:25, David Sterba wrote:
> On Thu, May 14, 2020 at 11:24:14AM +0200, Johannes Thumshirn wrote:
>> From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
>> Example usage:
>> Create a file-system with authentication key 0123456
>> mkfs.btrfs --csum "hmac(sha256)" --auth-key 0123456 /dev/disk
>>
>> Add the key to the kernel's keyring as keyid 'btrfs:foo'
>> keyctl add logon btrfs:foo 0123456 @u
>>
>> Mount the fs using the 'btrfs:foo' key
>> mount -o auth_key=btrfs:foo,auth_hash_name="hmac(sha256)" /dev/disk /mnt/point
> 
> I tried to follow the example but the filesystem does not mount. But
> what almost shocked me was the way the key is specified on the userspace
> side.
> 
> $ mkfs.btrfs --csum "hmac(sha256)" --auth-key 0123456 /dev/disk
> 
> "0123456" are the raw bytes of the key? Seriously?
> 
> And how it's passed to the hmac code:
> 
>  gcry_mac_hd_t mac;
>  gcry_mac_open(&mac, GCRY_MAC_HMAC_SHA256, 0, NULL);
>  gcry_mac_setkey(mac, fs_info->auth_key, strlen(fs_info->auth_key));
>  gcry_mac_write(mac, buf, length);
>  gcry_mac_read(mac, out, &length);
> 
> Strlen means the key must avoid char 0 and I don't think we want do any
> decoding from ascii-hex format, when there's the whole keyctl
> infrastructure.
> 
> The key for all userspace commands needs to be specified the same way as
> for kernel, ie. "--auth-key btrfs:foo" and use the appropriate ioctls to
> read the key bytes.
> 

Hohum?

Here's what I just did:

rapido1:/# keyctl add logon btrfs:foo 0123456 @u
1020349071
rapido1:/# mkfs.btrfs --csum "hmac(sha256)" --auth-key 0123456 /dev/zram1
btrfs-progs v5.6
See http://btrfs.wiki.kernel.org for more information.

Detected a SSD, turning off metadata duplication.  Mkfs with -m dup if you want to force metadata duplication.
Label:              (null)
UUID:               56ae43ac-f333-4ed4-933a-356aed534115
[   31.005743] BTRFS: device fsid 56ae43ac-f333-4ed4-933a-356aed534115 devid 1 transid 5 /dev/zram1 scanned by mkfs.btrfs (241)

Sector size:        4096
Filesystem size:    3.00GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         single            8.00MiB
  System:           single            4.00MiB
SSD detected:       yes
Incompat features:  extref, skinny-metadata
Checksum:           hmac-sha256
Number of devices:  1
Devices:
   ID        SIZE  PATH
    1     3.00GiB  /dev/zram1


rapido1:/# mount -o auth_key=btrfs:foo,auth_hash_name="hmac(sha256)" /dev/zram1 /mnt/       
[   65.959465] BTRFS info (device (efault)): doing authentication
[   65.963204] BTRFS info (device zram1): disk space caching is enabled
[   65.964137] BTRFS info (device zram1): has skinny extents
[   65.964912] BTRFS info (device zram1): flagging fs with big metadata feature
[   65.968302] BTRFS info (device zram1): enabling ssd optimizations
[   65.969551] BTRFS info (device zram1): checking UUID tree
rapido1:/#


  reply	other threads:[~2020-05-27 13:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14  9:24 [PATCH v3 0/3] Add file-system authentication to BTRFS Johannes Thumshirn
2020-05-14  9:24 ` [PATCH v3 1/3] btrfs: rename btrfs_parse_device_options back to btrfs_parse_early_options Johannes Thumshirn
2020-05-14  9:24 ` [PATCH v3 2/3] btrfs: add authentication support Johannes Thumshirn
2020-05-27 13:24   ` David Sterba
2020-05-27 13:54     ` Johannes Thumshirn [this message]
2020-05-27 14:01       ` Johannes Thumshirn
2020-05-27 18:04     ` Johannes Thumshirn
2020-06-01 14:30       ` David Sterba
2020-06-01 14:35       ` David Sterba
2020-05-14  9:24 ` [PATCH v3 3/3] btrfs: document btrfs authentication Johannes Thumshirn
2020-05-14 12:26   ` Jonathan Corbet
2020-05-14 14:54     ` Johannes Thumshirn
2020-05-14 15:14       ` Richard Weinberger
2020-05-14 16:00         ` Jonathan Corbet
2020-05-14 16:05           ` Richard Weinberger
2020-05-24 19:55   ` David Sterba
2020-05-25 10:57     ` Johannes Thumshirn
2020-05-25 11:26       ` David Sterba
2020-05-25 11:44         ` Johannes Thumshirn
2020-05-25 13:10 ` [PATCH v3 0/3] Add file-system authentication to BTRFS David Sterba
2020-05-26  7:50   ` Johannes Thumshirn
2020-05-26 11:53     ` David Sterba
2020-05-26 12:44       ` Johannes Thumshirn
2020-06-01 14:59         ` David Sterba
2020-05-27  2:08 ` Qu Wenruo
2020-05-27 11:27   ` David Sterba
2020-05-27 11:58     ` Qu Wenruo
2020-05-27 13:11   ` David Sterba

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=SN4PR0401MB3598593BC0AF9909CC1986889BB10@SN4PR0401MB3598.namprd04.prod.outlook.com \
    --to=johannes.thumshirn@wdc.com \
    --cc=dsterba@suse.cz \
    --cc=ebiggers@google.com \
    --cc=jth@kernel.org \
    --cc=jthumshirn@suse.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=richard@nod.at \
    --subject='Re: [PATCH v3 2/3] btrfs: add authentication support' \
    /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

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).