From: David Sterba <dsterba@suse.cz>
To: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
Cc: Eric Biggers <ebiggers@kernel.org>,
Johannes Thumshirn <jth@kernel.org>,
David Sterba <dsterba@suse.cz>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
Richard Weinberger <richard@nod.at>
Subject: Re: [PATCH v2 1/2] btrfs: add authentication support
Date: Wed, 6 May 2020 00:19:27 +0200 [thread overview]
Message-ID: <20200505221927.GX18421@twin.jikos.cz> (raw)
In-Reply-To: <SN4PR0401MB359843476634082E8329168A9BA70@SN4PR0401MB3598.namprd04.prod.outlook.com>
On Tue, May 05, 2020 at 08:11:56AM +0000, Johannes Thumshirn wrote:
> On 04/05/2020 22:59, Eric Biggers wrote:
> [...]
>
> > But your proposed design doesn't do this completely, since some times of offline
> > modifications are still possible.
> >
> > So that's why I'm asking *exactly* what security properties it will provide.
>
> [...]
>
> > Does this mean that a parent node's checksum doesn't cover the checksum of its
> > child nodes, but rather only their locations? Doesn't that allow subtrees to be
> > swapped around without being detected?
>
> I was about to say "no you can't swap the subtrees as the header also
> stores the address of the block", but please give me some more time to
> think about it. I don't want to give a wrong answer.
Note that block addresses are of two types, the physical and logical.
The metadata blocks use the logical one, so the block can be moved to
another location still maintaining the authenticated checksum, but then
the physical address will not match. And the physical<->logical mapping
is stored as metadata item, thus in the metadata blocks protected by the
authenticated checksum.
next prev parent reply other threads:[~2020-05-05 22:20 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 10:58 [PATCH v2 0/2] Add file-system authentication to BTRFS Johannes Thumshirn
2020-04-28 10:58 ` [PATCH v2 1/2] btrfs: add authentication support Johannes Thumshirn
2020-04-29 7:23 ` kbuild test robot
2020-04-29 11:46 ` Johannes Thumshirn
2020-05-01 5:39 ` Eric Biggers
2020-05-01 6:30 ` Eric Biggers
2020-05-04 8:38 ` Johannes Thumshirn
2020-05-05 22:33 ` David Sterba
2020-05-06 8:10 ` Johannes Thumshirn
2020-05-04 10:09 ` Johannes Thumshirn
2020-05-04 20:59 ` Eric Biggers
2020-05-05 8:11 ` Johannes Thumshirn
2020-05-05 9:26 ` Qu Wenruo
2020-05-05 9:59 ` Qu Wenruo
2020-05-05 22:32 ` David Sterba
2020-05-05 23:55 ` Qu Wenruo
2020-05-06 20:40 ` btree [was Re: [PATCH v2 1/2] btrfs: add authentication support] Goffredo Baroncelli
2020-05-05 22:19 ` David Sterba [this message]
2020-05-05 22:37 ` [PATCH v2 1/2] btrfs: add authentication support Eric Biggers
2020-05-06 8:30 ` Johannes Thumshirn
2020-05-05 22:14 ` David Sterba
2020-05-05 22:31 ` Eric Biggers
2020-05-05 22:46 ` David Sterba
2020-05-05 23:31 ` Eric Biggers
2020-05-06 0:29 ` David Sterba
2020-05-06 0:44 ` Eric Biggers
2020-05-04 21:37 ` Richard Weinberger
2020-05-05 7:46 ` Johannes Thumshirn
2020-05-05 11:56 ` Richard Weinberger
2020-05-04 21:59 ` Richard Weinberger
2020-05-05 7:55 ` Johannes Thumshirn
2020-05-05 12:36 ` Jeff Mahoney
2020-05-05 12:39 ` Qu Wenruo
2020-05-05 12:41 ` Jeff Mahoney
2020-05-05 12:48 ` Qu Wenruo
2020-05-05 23:02 ` David Sterba
2020-05-06 21:24 ` Goffredo Baroncelli
2020-05-05 23:00 ` David Sterba
2020-05-05 9:43 ` Qu Wenruo
2020-05-06 20:59 ` Goffredo Baroncelli
2020-04-28 10:58 ` [PATCH v2 2/2] btrfs: rename btrfs_parse_device_options back to btrfs_parse_early_options Johannes Thumshirn
2020-05-01 6:03 ` [PATCH v2 0/2] Add file-system authentication to BTRFS Eric Biggers
2020-05-04 8:39 ` Johannes Thumshirn
2020-05-05 23:16 ` David Sterba
2020-05-01 21:26 ` Jason A. Donenfeld
2020-05-05 23:38 ` 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=20200505221927.GX18421@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=Johannes.Thumshirn@wdc.com \
--cc=ebiggers@kernel.org \
--cc=jth@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=richard@nod.at \
/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).