linux-kernel - Re: [PATCH] UBIFS: add crypto lookup field to tree node cache

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: <alpine.DEB.2.00.1205142032210.12448@eristoteles.iwoars.net>
Date:	Mon, 14 May 2012 20:45:42 +0200 (CEST)
From:	Joel Reardon <joel@...mbassador.com>
To:	Artem Bityutskiy <dedekind1@...il.com>
cc:	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] UBIFS: add crypto lookup field to tree node cache

I use this because I figured it should be abstracted in functions that
have these values, but don't need to know about the internal structure.
>From the view of all UBIFS components (except the new keymap), two values
have no more meaning than one, its all just some value the keymap gives
out and returns the same key on read_key.

cheers,
Joel Reardon

On Mon, 14 May 2012, Artem Bityutskiy wrote:

> On Mon, 2012-05-14 at 19:20 +0200, Joel Reardon wrote:
> > The long long is divided as follows:
> > 32 bits for the (KSA-relative) LEB number, 32 bits for the offset in the
> > leb where the key is found. So its the same as the lnum/offs for the
> > current one. Theres substancial compression though, that is available,
> > since theres likely not more than 2^^32 LEBS for the KSA and the number of
> > bits needed for key offset is LEB_SHIFT - 4.
> >
> > Is 32 bits sufficient to address all keys:
> > one key per datanode means 4096 * 2^32 = 2^44, so only 16 TB available
> > for 32 bit key addresses.
> >
> > Though there is similar waste for lnum/offs as well. Perhaps zbranches can
> > be stored as a u8[] and demarshalled with bit-op macros when needed for
> > computations.
>
> OK, thanks for explanation. Why not to then store 2x32-bit fields
> instead, which is consistent with the current style? Why "long long"?
>
> --
> Best Regards,
> Artem Bityutskiy
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/