linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Gix, Brian" <brian.gix@intel.com>
To: "linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	"Stotland, Inga" <inga.stotland@intel.com>
Subject: Re: [PATCH BlueZ] mesh: Add App and Net Key Refresh keyring back-end
Date: Wed, 22 May 2019 16:20:07 +0000	[thread overview]
Message-ID: <1558542005.332.15.camel@intel.com> (raw)
In-Reply-To: <cac7634e3fae82e060728b9cfe096a31a9e86c70.camel@intel.com>

Hi Inga... I will correct the various spelling issues, and perhaps also segment the patches as you suggest

On Tue, 2019-05-21 at 23:44 -0700, Stotland, Inga wrote:
> On Tue, 2019-05-21 at 10:01 -0700, Brian Gix wrote:
> > 
> > +	struct mesh_node *node = user_data;
> > +	uint8_t key[16];
> >  	uint16_t net_idx;
> >  
> > -	if (!l_dbus_message_get_arguments(msg, "q", &net_idx))
> > +	if (!l_dbus_message_get_arguments(msg, "q", &net_idx) ||
> > !net_idx)
> 
> 
> Maybe use explicit value for net_idx check, i.e., 
> net_idx == MESH_PRIMARY_NET_INDEX_DEFAULT
> 
> Currently DEFAULT_PRIMARY_NET_INDEX is defined in node.c
> WE should move it into mesh-defs.h and rename accordingly

I can do this...  Although I don't know that we will ever have any other Net Index except 0 ever be defined by
the spec as "Primary".

> 
> > -	if (!l_dbus_message_get_arguments(msg, "q", &net_idx))
> > +	if (!l_dbus_message_get_arguments(msg, "q", &net_idx) ||
> > +						net_idx > MAX_KEY_IDX)
> >  		return dbus_error(msg, MESH_ERROR_INVALID_ARGS, NULL);
> >  
> > -	/* TODO */
> > -	return dbus_error(msg, MESH_ERROR_NOT_IMPLEMENTED, NULL);
> > +	if (!keyring_get_net_key(node, net_idx, &key))
> > +		return dbus_error(msg, MESH_ERROR_DOES_NOT_EXIST,
> > NULL);
> > +
> > +	switch (key.phase) {
> > +	case KEY_REFRESH_PHASE_NONE:
> > +		/* Generate Key and update phase */
> > +		l_getrandom(key.new_key, sizeof(key.new_key));
> > +		key.phase = KEY_REFRESH_PHASE_ONE;
> 
> line break?
> 
> > +		if (!keyring_put_net_key(node, net_idx, &key))
> > +			return dbus_error(msg, MESH_ERROR_FAILED,
> > NULL);
> 
> Wouldn't we want to revert the key phase back to KEY_REFRESH_PHASE_NONE
> in case of failure?

I don't think this is neccessary. This is the only place in the function where a *Change* is made to the
persistent data...  If it fails then it fails, and the old data will still be there.



> 
> > +static struct l_dbus_message *store_new_appkey(struct mesh_node
> > *node,
> > +					struct l_dbus_message *msg,
> > +					uint16_t net_idx, uint16_t
> > app_idx,
> > +					uint8_t *new_key)
> > +{
> > +	struct keyring_net_key net_key;
> > +	struct keyring_app_key app_key;
> > +
> > +	if (net_idx > MAX_KEY_IDX || app_idx > MAX_KEY_IDX)
> > +		return dbus_error(msg, MESH_ERROR_INVALID_ARGS, NULL);
> > +
> > +	if (!keyring_get_net_key(node, net_idx, &net_key))
> > +		return dbus_error(msg, MESH_ERROR_DOES_NOT_EXIST,
> > NULL);
> 
> NULL -> "Bound net key not found"
> Also, I don't think "org.bluez.mesh.Error.DoesNotExist" error is
> documented in mesh-api.txt for either CreateAppKey() or ImportAppKey(),
> needs to be added.

Will add

> 
> > 
> >  static struct l_dbus_message *update_appkey_call(struct l_dbus
> > *dbus,
> >  						struct l_dbus_message
> > *msg,
> >  						void *user_data)
> >  {
> > -	uint16_t net_idx, app_idx;
> > +	struct mesh_node *node = user_data;
> > +	struct keyring_net_key net_key;
> > +	struct keyring_app_key app_key;
> > +	uint16_t app_idx;
> >  
> > -	if (!l_dbus_message_get_arguments(msg, "qq", &net_idx,
> > &app_idx))
> > +	if (!l_dbus_message_get_arguments(msg, "q", &app_idx) ||
> > +						app_idx > MAX_KEY_IDX)
> >  		return dbus_error(msg, MESH_ERROR_INVALID_ARGS, NULL);
> >  
> > -	/* TODO */
> > -	return dbus_error(msg, MESH_ERROR_NOT_IMPLEMENTED, NULL);
> > +	if (!keyring_get_app_key(node, app_idx, &app_key) ||
> > +			!keyring_get_net_key(node, app_key.net_idx,
> > &net_key))
> > +		return dbus_error(msg, MESH_ERROR_DOES_NOT_EXIST,
> > NULL);
> > +
> > +	switch (net_key.phase) {
> > +	case KEY_REFRESH_PHASE_NONE:
> > +	case KEY_REFRESH_PHASE_ONE:
> 
> What if the net key is in key refresh phase one and This method has
> been called mre than once? i.e., do we want to protect the application
> from potentially overwriting already updated application key?

Well, Application keys don't actually have a phase...  It is inherited from the bound net key. The controlling
Config Client app needs to set up *all* the updates in the keyring before starting to send the updates to the
remote nodes.  We can warn in the mesh-api.txt the correct order of things, but as long as the App does not
start sending the updates over-the-air, there is no problem with Updating the key-ring's App Key redundantly
prior to starting to propagate.  As long as the *spec* is followed, we don't have a problem.  


> 
> > 
> >  static struct l_dbus_message *set_key_phase_call(struct l_dbus
> > *dbus,
> >  						struct l_dbus_message
> > *msg,
> >  						void *user_data)
> >  {
> > +	struct mesh_node *node = user_data;
> > +	struct keyring_net_key key;
> >  	uint16_t net_idx;
> >  	uint8_t phase;
> >  
> > -	if (!l_dbus_message_get_arguments(msg, "qy", &net_idx, &phase))
> > +	if (!l_dbus_message_get_arguments(msg, "qy", &net_idx, &phase)
> > > > 
> > 
> > +					phase == KEY_REFRESH_PHASE_ONE
> > > > 
> > 
> > +					phase >
> > KEY_REFRESH_PHASE_THREE)
> >  		return dbus_error(msg, MESH_ERROR_INVALID_ARGS, NULL);
> >  
> > -	/* TODO */
> > -	return dbus_error(msg, MESH_ERROR_NOT_IMPLEMENTED, NULL);
> > +	if (!keyring_get_net_key(node, net_idx, &key))
> > +		return dbus_error(msg, MESH_ERROR_DOES_NOT_EXIST,
> > NULL);
> > +
> > +	if (phase == KEY_REFRESH_PHASE_THREE &&
> > +					key.phase !=
> > KEY_REFRESH_PHASE_NONE) {
> > +		memcpy(key.old_key, key.new_key, 16);
> > +		key.phase = KEY_REFRESH_PHASE_NONE;
> > +	} else
> > +		key.phase = phase;
> > +
> > +	if (!keyring_put_net_key(node, net_idx, &key))
> > +		return dbus_error(msg, MESH_ERROR_FAILED, NULL);
> 
> Restore the phase to the previous value in case of failure?


As with the above comment, a failure is a failure... If this method fails for *any* reason, it means nothing
about the keys were updated, so there is nothing to restore.

> 
> > 
> Thank you,
> 
> 
> Inga

      reply	other threads:[~2019-05-22 16:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-21 17:01 [PATCH BlueZ] mesh: Add App and Net Key Refresh keyring back-end Brian Gix
2019-05-22  6:44 ` Stotland, Inga
2019-05-22 16:20   ` Gix, Brian [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=1558542005.332.15.camel@intel.com \
    --to=brian.gix@intel.com \
    --cc=inga.stotland@intel.com \
    --cc=linux-bluetooth@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).