linux-kernel - Re: [PATCH v3 1/6] tools: iio: iio_generic

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: <20230925141629.00004522@Huawei.com>
Date:   Mon, 25 Sep 2023 14:16:29 +0100
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Matti Vaittinen <mazziesaccount@...il.com>
CC:     Jonathan Cameron <jic23@...nel.org>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Angel Iglesias <ang.iglesiasg@...il.com>,
        Andreas Klinger <ak@...klinger.de>,
        "Christophe JAILLET" <christophe.jaillet@...adoo.fr>,
        Benjamin Bara <bbara93@...il.com>, <linux-iio@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/6] tools: iio: iio_generic_buffer ensure alignment

On Mon, 25 Sep 2023 10:01:09 +0300
Matti Vaittinen <mazziesaccount@...il.com> wrote:

> On 9/24/23 18:57, Jonathan Cameron wrote:
> > On Fri, 22 Sep 2023 14:16:08 +0300
> > Matti Vaittinen <mazziesaccount@...il.com> wrote:
> >   
> >> The iio_generic_buffer can return garbage values when the total size of
> >> scan data is not a multiple of largest element in the scan. This can be
> >> demonstrated by reading a scan consisting for example of one 4 byte and
> >> one 2 byte element, where the 4 byte elemnt is first in the buffer.
> >>
> >> The IIO generic buffert code does not take into accunt the last two
> >> padding bytes that are needed to ensure that the 4byte data for next
> >> scan is correctly aligned.
> >>
> >> Add padding bytes required to align the next sample into the scan size.
> >>
> >> Signed-off-by: Matti Vaittinen <mazziesaccount@...il.com>
> >> ---
> >> Please note, This one could have RFC in subject.:
> >> I attempted to write the fix so that the alignment is done based on the
> >> biggest channel data. This may be wrong. Maybe a fixed 8 byte alignment
> >> should be used instead? This patch can be dropped from the series if the
> >> fix is not correct / agreed.
> >>
> >>   tools/iio/iio_generic_buffer.c | 15 ++++++++++++++-
> >>   1 file changed, 14 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/tools/iio/iio_generic_buffer.c b/tools/iio/iio_generic_buffer.c
> >> index 44bbf80f0cfd..fc562799a109 100644
> >> --- a/tools/iio/iio_generic_buffer.c
> >> +++ b/tools/iio/iio_generic_buffer.c
> >> @@ -54,9 +54,12 @@ enum autochan {
> >>   static unsigned int size_from_channelarray(struct iio_channel_info *channels, int num_channels)
> >>   {
> >>   	unsigned int bytes = 0;
> >> -	int i = 0;
> >> +	int i = 0, max = 0;
> >> +	unsigned int misalignment;
> >>   
> >>   	while (i < num_channels) {
> >> +		if (channels[i].bytes > max)
> >> +			max = channels[i].bytes;
> >>   		if (bytes % channels[i].bytes == 0)
> >>   			channels[i].location = bytes;
> >>   		else
> >> @@ -66,6 +69,16 @@ static unsigned int size_from_channelarray(struct iio_channel_info *channels, in
> >>   		bytes = channels[i].location + channels[i].bytes;
> >>   		i++;
> >>   	}
> >> +	/*
> >> +	 * We wan't the data in next sample to also be properly aligned so
> >> +	 * we'll add padding at the end if needed. TODO: should we use fixed
> >> +	 * 8 byte alignment instead of the size of the biggest samnple?
> >> +	 */  
> > 
> > Should be aligned to max size seen in the scan.  
> 
> Or, maybe it should be
> min(max_size_in_scan, 8);
> ?

Definitely not.   If you are grabbing just one channel of 8 bit data,
we want it to be tightly packed.

If we have a bug that already made that true then we might be stuck
with it, but I'm fairly sure we don't.
> 
> I think my suggestion above may yield undesirable effects should the 
> scan elements be greater than 8 bytes. (Don't know if this is supported 
> though)

It is supported in theory, in practice not seen one yet.

> 
> >   
> >> +	misalignment = bytes % max;
> >> +	if (misalignment) {
> >> +		printf("Misalignment %u. Adding Padding %u\n", misalignment,  max - misalignment);  
> > 
> > No print statement as this is correct behaviour (well the tool is buggy but the kernel generates it
> > correctly I believe).  Fine to add a comment though!  
> 
> Oh, indeed. The print was forgotten from my test runs. Thanks for 
> pointing it out!
> 
> >   
> >> +		bytes += max - misalignment;
> >> +	}
> >>   
> >>   	return bytes;
> >>   }  
> >   
> 
> Yours,
> 	-- Matti
>