All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: kreijack@inwind.it, Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
Cc: Johannes Thumshirn <jth@kernel.org>,
	David Sterba <dsterba@suse.cz>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: btree [was Re: [PATCH v2 1/2] btrfs: add authentication support]
Date: Thu, 7 May 2020 06:57:38 +0800	[thread overview]
Message-ID: <2ca44136-438d-2b88-160d-9a321cff6f49@gmx.com> (raw)
In-Reply-To: <d649407a-7ca4-e9ee-f291-7845c89c622b@libero.it>


[-- Attachment #1.1: Type: text/plain, Size: 2099 bytes --]



On 2020/5/7 上午4:40, Goffredo Baroncelli wrote:
> Hi Qu,
> 
> I will go a bit off topic, because I am interested more in the
> understanding of the btrees than the topic of this thread

Then removing unrelated CCs to reduce the noise.

> On 5/5/20 11:26 AM, Qu Wenruo wrote:
> [...]
>>
>> My personal idea on this swap-tree attack is, the first key, generation,
>> bytenr protection can prevent such case.
>>
>> The protection chain begins from superblock, and ends at the leaf tree
>> blocks, as long as superblock is also protected by hmac hash, it should
>> be safe.
>>
>>
>> Btrfs protects parent-child relationship by:
>> - Parent has the pointer (bytenr) of its child
>>    The main protection. If attacker wants to swap one tree block, it must
>>    change the parent tree block.
>>    The parent is either a tree block (parent node), or root item in root
>>    tree, or a super block.
>>    All protected by hmac csum. Thus attack can only do such attach by
>>    knowing the key.
>>
>> - Parent has the first key of its child
>>    Unlike previous one, this is just an extra check, no extra protection.
>>    And root item doesn't contain the first key.
> 
> It always true ? When a key is inserted, we update the key of the parent
> to be equal to the first of the (right) child. However when a key is
> removed, this should be not mandatory. Is it enough that the parent key
> is greater (or equal) than the first key of the left node, and lesser
> than the last of the right node ?
> 
> Supposing to have
> 
>             1 10 (A)
>            /    \
> 1 2 3 4 5 (B)     10 11 12 13 (C)
> 
> If you remove 10 in the right child node, is it mandatory to updated the
> '10' in the parent node (to 11) ?

Yes. And we're always COW so tree block C and A will get COWed (and if A
has parents, the path towards the tree root will get COWed).

If we remove 10, then the result would be:
	1 11 (Cowed A)
       /    \
1 ~ 5 (B)    11 12 13 (Cowed C)

Thanks,
Qu

> 
> 
> [...]
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-05-06 22:57 UTC|newest]

Thread overview: 48+ 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  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-06 22:57               ` Qu Wenruo [this message]
2020-05-05 22:19           ` [PATCH v2 1/2] btrfs: add authentication support David Sterba
2020-05-05 22:37           ` 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=2ca44136-438d-2b88-160d-9a321cff6f49@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=Johannes.Thumshirn@wdc.com \
    --cc=dsterba@suse.cz \
    --cc=jth@kernel.org \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.