Re: [PATCH 1/9] dpp: prep for moving AAD within dpp_append_wrapped_data

[James Prestwood <prestwoj@gmail.com>]

Hi Denis,

On 4/2/24 8:10 AM, Denis Kenzior wrote:
> 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?
>
I did this to prep for patch 2, which uses buffer offsets and the frame 
type to calculate the AAD data. Its true the AAD data is always broken 
up into header and payload but I didn't want to use iov's because we 
would then have to assume iov[0] is the header and iov[1] is the 
payload. A single buffer makes it a lot clearer: we can minimally parse 
the frame, find the type, and calculate AAD offsets. With iov's we would 
have to check iov[0] for the type, then use some offset in iov[1] for 
the second AAD chunk. This then requires the iov's be exactly what we 
expect, which isn't a great API.

Yes, passing the entire frame also requires the buffer is exactly what 
we expect but documenting "the frame must start at the action byte" is a 
lot better than "iov[0] must be the header starting at the action byte" 
and "iov[1] must be the DPP attributes".

Thanks,

James