Wireless Daemon for Linux
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: James Prestwood <prestwoj@gmail.com>, iwd@lists.linux.dev
Subject: Re: [PATCH 1/9] dpp: prep for moving AAD within dpp_append_wrapped_data
Date: Tue, 2 Apr 2024 10:10:01 -0500	[thread overview]
Message-ID: <ebcfd870-b9a2-4215-b652-3008d3d2b6b7@gmail.com> (raw)
In-Reply-To: <20240327151957.1446149-1-prestwoj@gmail.com>

Hi James,

On 3/27/24 10:19, James Prestwood wrote:
> The AAD pointers for DPP are specific to the frame type. This is
> currently sorted out by the caller within the respective frame
> building functions but its quite unreadable. There are some comments
> but lots of magic numbers. This should be moved within the
> dpp_append_wrapped_data utility but the first step is to make the
> frame buffer continuous. This will allow the entire frame to be

continuous -> contiguous?

> passed and dpp_append_wrapped_data can calculate the AAD offsets
> itself.

I'm a bit confused as to why?  Whether we have an iov or a contiguous buffer, 
the end result is the same, no?  If you want to omit parts of the header from 
the wrapped data calculation, wouldn't you just break up the header into 
multiple iovs instead?

> ---
>   src/dpp.c | 239 +++++++++++++++++++++++++-----------------------------
>   1 file changed, 112 insertions(+), 127 deletions(-)
> 

<snip>

> diff --git a/src/dpp.c b/src/dpp.c
> index 567fe8d2..5aac22a7 100644
> --- a/src/dpp.c
> +++ b/src/dpp.c
> @@ -648,7 +648,7 @@ static void dpp_frame_retry(struct dpp_sm *dpp)
>   
>   static size_t dpp_build_header(const uint8_t *src, const uint8_t *dest,
>   				enum dpp_frame_type type,
> -				uint8_t buf[static 32])
> +				uint8_t *buf)

Is this really needed?

>   {
>   	uint8_t *ptr = buf + 24;
>   
> @@ -672,7 +672,7 @@ static size_t dpp_build_header(const uint8_t *src, const uint8_t *dest,
>   
>   static size_t dpp_build_config_header(const uint8_t *src, const uint8_t *dest,
>   					uint8_t diag_token,
> -					uint8_t buf[static 37])
> +					uint8_t *buf)

Or this?

>   {
>   	uint8_t *ptr = buf + 24;
>   

<snip>

> @@ -780,42 +779,39 @@ static void dpp_configuration_start(struct dpp_sm *dpp, const uint8_t *addr)
>   	 * In this case there is no query request/response fields, nor any
>   	 * attributes besides wrapped data meaning zero AD components.
>   	 */
> -	ptr += dpp_append_wrapped_data(NULL, 0, NULL, 0, ptr, sizeof(attrs),
> +	ptr += dpp_append_wrapped_data(NULL, 0, NULL, 0, ptr, sizeof(frame),

The sizeof(frame) is now likely wrong in this setup.  No error checking also 
worries me a bit.

<snip>

>   static void send_config_result(struct dpp_sm *dpp, const uint8_t *to)
>   {
> -	uint8_t hdr[32];
> -	struct iovec iov[2];
> -	uint8_t attrs[256];
> -	uint8_t *ptr = attrs;
> +	struct iovec iov;
> +	uint8_t frame[256];
> +	uint8_t *ptr = frame;
>   	uint8_t zero = 0;
>   
> -	iov[0].iov_len = dpp_build_header(netdev_get_address(dpp->netdev), to,
> -					DPP_FRAME_CONFIGURATION_RESULT, hdr);
> -	iov[0].iov_base = hdr;
> -
> -	ptr += dpp_append_wrapped_data(hdr + 26, 6, attrs, 0, ptr,
> -			sizeof(attrs), dpp->ke, dpp->key_len, 2,
> +	ptr += dpp_build_header(netdev_get_address(dpp->netdev), to,
> +					DPP_FRAME_CONFIGURATION_RESULT, ptr);
> +	ptr += dpp_append_wrapped_data(frame + 26, 6, ptr, 0, ptr,
> +			sizeof(frame), dpp->ke, dpp->key_len, 2,

Same comment here

>   			DPP_ATTR_STATUS, (size_t) 1, &zero,
>   			DPP_ATTR_ENROLLEE_NONCE, dpp->nonce_len, dpp->e_nonce);
>   
> -	iov[1].iov_base = attrs;
> -	iov[1].iov_len = ptr - attrs;
> +	iov.iov_base = frame;
> +	iov.iov_len = ptr - frame;
>   
> -	dpp_send_frame(dpp, iov, 2, dpp->current_freq);
> +	dpp_send_frame(dpp, &iov, 1, dpp->current_freq);
>   }
>   
>   static void dpp_write_config(struct dpp_configuration *config,

<snip>

> @@ -1211,26 +1205,26 @@ static void dpp_send_config_response(struct dpp_sm *dpp, uint8_t status)
>   		json = dpp_configuration_to_json(dpp->config);
>   		json_len = strlen(json);
>   
> -		ptr += dpp_append_wrapped_data(attrs + 2, ptr - attrs - 2,
> -						NULL, 0, ptr, sizeof(attrs),
> +		ptr += dpp_append_wrapped_data(lptr + 2, ptr - lptr - 2,
> +						NULL, 0, ptr, sizeof(frame),

Is sizeof(frame) correct here?

>   						dpp->ke, dpp->key_len, 2,
>   						DPP_ATTR_ENROLLEE_NONCE,
>   						dpp->nonce_len, dpp->e_nonce,
>   						DPP_ATTR_CONFIGURATION_OBJECT,
>   						json_len, json);
>   	} else
> -		ptr += dpp_append_wrapped_data(attrs + 2, ptr - attrs - 2,
> -						NULL, 0, ptr, sizeof(attrs),
> +		ptr += dpp_append_wrapped_data(lptr + 2, ptr - lptr - 2,
> +						NULL, 0, ptr, sizeof(frame),

and here?

>   						dpp->ke, dpp->key_len, 2,
>   						DPP_ATTR_ENROLLEE_NONCE,
>   						dpp->nonce_len, dpp->e_nonce);
>   
> -	l_put_le16(ptr - attrs - 2, attrs);
> +	l_put_le16(ptr - lptr - 2, lptr);
>   
> -	iov[1].iov_base = attrs;
> -	iov[1].iov_len = ptr - attrs;
> +	iov.iov_base = frame;
> +	iov.iov_len = ptr - frame;
>   
> -	dpp_send_frame(dpp, iov, 2, dpp->current_freq);
> +	dpp_send_frame(dpp, &iov, 1, dpp->current_freq);
>   }
>   
>   static bool dpp_check_config_header(const uint8_t *ptr)

<snip>

Regards,
-Denis

  parent reply	other threads:[~2024-04-02 15:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27 15:19 [PATCH 1/9] dpp: prep for moving AAD within dpp_append_wrapped_data James Prestwood
2024-03-27 15:19 ` [PATCH 2/9] dpp-util: move AAD logic within dpp_append_wrapped_attributes James Prestwood
2024-04-02 15:19   ` Denis Kenzior
2024-03-27 15:19 ` [PATCH 3/9] dpp-util: add dpp_append_point James Prestwood
2024-03-27 15:19 ` [PATCH 4/9] dpp: use dpp_append_point James Prestwood
2024-03-27 15:19 ` [PATCH 5/9] dpp-common: Skeleton for common DPP module James Prestwood
2024-03-27 15:19 ` [PATCH 6/9] dpp-common: add TX/RX handlers to dpp_sm James Prestwood
2024-04-02 15:27   ` Denis Kenzior
2024-04-15 14:05     ` James Prestwood
2024-03-27 15:19 ` [PATCH 7/9] build: add dpp-common.{c,h} James Prestwood
2024-03-27 15:19 ` [PATCH 8/9] dpp: remove most crypto/frame processing James Prestwood
2024-03-27 15:19 ` [PATCH 9/9] dpp: use common state machine James Prestwood
2024-04-02 15:10 ` Denis Kenzior [this message]
2024-04-15 14:02   ` [PATCH 1/9] dpp: prep for moving AAD within dpp_append_wrapped_data James Prestwood
2024-04-15 19:00     ` Denis Kenzior

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=ebcfd870-b9a2-4215-b652-3008d3d2b6b7@gmail.com \
    --to=denkenz@gmail.com \
    --cc=iwd@lists.linux.dev \
    --cc=prestwoj@gmail.com \
    /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