lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3260968.WmIi4lir0Q@blindfold>
Date:   Mon, 27 Aug 2018 21:18:25 +0200
From:   Richard Weinberger <richard@....at>
To:     Sascha Hauer <s.hauer@...gutronix.de>
Cc:     linux-mtd@...ts.infradead.org, David Gstir <david@...ma-star.at>,
        kernel@...gutronix.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 12/25] ubifs: Add hashes to the tree node cache

Am Mittwoch, 4. Juli 2018, 14:41:24 CEST schrieb Sascha Hauer:
> As part of the UBIFS authentication support every branch in the index
> gets a hash covering the referenced node. To make that happen the tree
> node cache needs hashes over the nodes. This patch adds a hash argument
> to ubifs_tnc_add() and ubifs_tnc_add_nm(). The hashes are calculated
> from the callers of these functions which actually prepare the nodes.
> With this patch all the leaf nodes of the index tree get hashes, but
> currently nothing is done with these hashes, this is left for a later
> patch.
> 
> Signed-off-by: Sascha Hauer <s.hauer@...gutronix.de>
> ---
>  fs/ubifs/journal.c | 93 ++++++++++++++++++++++++++++++++++------------
>  fs/ubifs/replay.c  |  4 +-
>  fs/ubifs/tnc.c     | 10 ++++-
>  fs/ubifs/ubifs.h   |  7 +++-
>  4 files changed, 84 insertions(+), 30 deletions(-)
> 
> diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c
> index 754d969eb27e..55b35bc33c31 100644
> --- a/fs/ubifs/journal.c
> +++ b/fs/ubifs/journal.c
> @@ -517,6 +517,9 @@ int ubifs_jnl_update(struct ubifs_info *c, const struct inode *dir,
>  	struct ubifs_dent_node *dent;
>  	struct ubifs_ino_node *ino;
>  	union ubifs_key dent_key, ino_key;
> +	u8 hash_dent[UBIFS_MAX_HASH_LEN];
> +	u8 hash_ino[UBIFS_MAX_HASH_LEN];
> +	u8 hash_ino_host[UBIFS_MAX_HASH_LEN];

With authentication enabled, this makes perfectly sense.
But if someone builds UBIFS without and has a memory constraint system,
we could save by setting UBIFS_MAX_HASH_LEN to 0. What do you think?
Although, we need another define to not influence ubifs-media.h.

Thanks,
//richard


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ