linux-kernel - Re: [patch] Move CRC computation to separate function

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.1203231739330.22944@eristoteles.iwoars.net>
Date:	Fri, 23 Mar 2012 17:45:30 +0100 (CET)
From:	Joel Reardon <joel@...mbassador.com>
To:	Artem Bityutskiy <dedekind1@...il.com>
cc:	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [patch] Move CRC computation to separate function

When GCing a data node, it may be reencrypted as a means of organizing the
KSA and reducing the number of LEBs that need to be erased. A Long term
keys in one half for stable data, short term in the other.  During this
reencryption the CRC is recomputed. Also, after truncating it the last
chunk needs to be reencrypted too, or else the key can be used with the
old version to find the truncated part.

For the misc.h approach, it does not currently include ubifs-media.h, but
that is where UBIFS_CRC32_INIT is defined, so move it also to misc.h



On Fri, 23 Mar 2012, Artem Bityutskiy wrote:

> On Mon, 2012-03-19 at 23:46 +0100, Joel Reardon wrote:
> >  /**
> > + * ubifs_set_datanode_crc - writes the crc for a data node to the common
> > + * header.
> > + * @node: the data node
> > + */
> > +void ubifs_set_datanode_crc(void *node)
> > +{
> > +	struct ubifs_ch *ch = (struct ubifs_ch *) node;
> > +	int len = le32_to_cpu(ch->len);
> > +	ch->crc = cpu_to_le32(crc32(UBIFS_CRC32_INIT, node + 8, len - 8));
> > +}
>
> Will this be used by other code, outside of io.c? Because currently
> there is only one user in the same file, which does not justify
> introducing it and making non-static. If answers are "yes", then it is
> better to make it static inline and put to misc.h instead, because it is
> very small.
>
> >  void ubifs_prepare_node(struct ubifs_info *c, void *node, int len, int pad)
> >  {
> > -	uint32_t crc;
> >  	struct ubifs_ch *ch = node;
> >  	unsigned long long sqnum = next_sqnum(c);
> >
> > @@ -390,8 +401,7 @@ void ubifs_prepare_node(struct ubifs_info *c, void *node, int len, int pad)
> >  	ch->group_type = UBIFS_NO_NODE_GROUP;
> >  	ch->sqnum = cpu_to_le64(sqnum);
> >  	ch->padding[0] = ch->padding[1] = 0;
> > -	crc = crc32(UBIFS_CRC32_INIT, node + 8, len - 8);
> > -	ch->crc = cpu_to_le32(crc);
> > +	ubifs_set_datanode_crc(node);
>
> But ubifs_prepare_node() is generic and works for any node type, not
> just data nodes, which means that using 'datanode' in the name is not a
> good idea.
>
> --
> 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/