From: Artem Bityutskiy <dedekind1@gmail.com>
To: Joel Reardon <joel@clambassador.com>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] UBIFS: add crypto lookup field to tree node cache
Date: Tue, 15 May 2012 09:21:57 +0300 [thread overview]
Message-ID: <1337062917.2528.109.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1205111323010.17715@eristoteles.iwoars.net>
[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]
On Fri, 2012-05-11 at 13:24 +0200, Joel Reardon wrote:
> This patch adds a new field to the TNC's zbranch and allows it to be set when
> a node is added or replaced. The field is called 'crypto_lookup' and it refers
> to a location in the key storage area---a pointer to a key that is used to
> encrypt/decrypt the data node. It can be set to 0 or a negative number when it
> is not being used. When a new node is added, this value is passed and set
> When a node is replace, the old value is replaced with the new value.
>
> These values will be used in future patchs. Replacing a
> crypto_lookup value will also mark the old value as deleted and the new value
> as used; adding a new node will mark the value as used. Additionally, deleting
> or removing TNC nodes will mark the values as deleted.
>
> TNC's crypto_lookup values are not stored on disk. They will be stored in the
> data
> node's header. Therefore, if a crypto_lookup value is invalid (but a valid one
> is to be expected and needs to be used) then a function will be added that
> reads the data node to
> obtain the value. Additionally, when a data node is ever read, the
> crypto_lookup position that is read will be set in the corresponding zbranch.
>
> The values are not stored on disk to avoid having different on-disk formats of
> the the ubifs_branch structure.
>
> Signed-off-by: Joel Reardon <reardonj@inf.ethz.ch>
Pushed to the "joel" branch, thanks!
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2012-05-15 6:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-11 11:24 Joel Reardon
2012-05-14 13:21 ` Artem Bityutskiy
2012-05-14 17:20 ` Joel Reardon
2012-05-14 18:28 ` Artem Bityutskiy
2012-05-14 18:45 ` Joel Reardon
2012-05-14 19:14 ` Artem Bityutskiy
2012-05-15 6:21 ` Artem Bityutskiy [this message]
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=1337062917.2528.109.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=joel@clambassador.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®