| Message ID | 20240222222335.work.759-kees@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] iio: pressure: dlhl60d: Check mask_width for IRQs | expand |
On Thu, 22 Feb 2024 14:23:39 -0800 Kees Cook <keescook@chromium.org> wrote: > Clang tripped over a FORTIFY warning in this code, and while it seems it > may be a false positive in Clang due to loop unwinding, the code in > question seems to make a lot of assumptions. Hi Kees, The assumptions are mostly characteristics of how the IIO buffers work with the scan masks defined based on indexes in the driver provided struct iio_chan_spec arrays. This driver is doing more work than it should need to as we long ago moved some of the more fiddly handling into the IIO core. > Comments added, and the > Clang warning[1] has been worked around by growing the array size. > Also there was an uninitialized 4th byte in the __be32 array that was > being sent through to iio_push_to_buffers(). That is indeed not good - the buffer should have been zero initialized. > > Link: https://github.com/ClangBuiltLinux/linux/issues/2000 [1] > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > Cc: Jonathan Cameron <jic23@kernel.org> > Cc: Lars-Peter Clausen <lars@metafoo.de> > Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Cc: "Nuno Sá" <nuno.sa@analog.com> > Cc: linux-iio@vger.kernel.org > --- > drivers/iio/pressure/dlhl60d.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/iio/pressure/dlhl60d.c b/drivers/iio/pressure/dlhl60d.c > index 28c8269ba65d..9bbecd0bfe88 100644 > --- a/drivers/iio/pressure/dlhl60d.c > +++ b/drivers/iio/pressure/dlhl60d.c > @@ -250,20 +250,27 @@ static irqreturn_t dlh_trigger_handler(int irq, void *private) > struct dlh_state *st = iio_priv(indio_dev); > int ret; > unsigned int chn, i = 0; > - __be32 tmp_buf[2]; > + /* This was only an array pair of 4 bytes. */ True, which is the right size as far as I can tell. If we need this to suppress a warning then comment should say that. > + __be32 tmp_buf[4] = { }; > > ret = dlh_start_capture_and_read(st); > if (ret) > goto out; > > + /* Nothing was checking masklength vs ARRAY_SIZE(tmp_buf)? */ Not needed but no way a compiler could know that. > + if (WARN_ON_ONCE(indio_dev->masklength > ARRAY_SIZE(tmp_buf))) > + goto out; > + > for_each_set_bit(chn, indio_dev->active_scan_mask, This is all a bit pointless if not 'wrong' other than the 4th byte uninitialized part. The limit can be hard coded as 2 as that's a characteristic of this driver. For device that always read a particular set of channels they should provide indio_dev->available_scan_masks = { BIT(1) | BIT(0), 0 }; and then always push all the data making this always memcpy(&tmp_buf[0], &st->rx_buf[1], 3); mempcy(&tmp_buf[1], &st->rx_buf[1] + 3, 3); The buffer demux code in the IIO core will deal with repacking the data if only one channel is enabled. > indio_dev->masklength) { > - memcpy(tmp_buf + i, > + /* This is copying 3 bytes. What about the 4th? */ > + memcpy(&tmp_buf[i], > &st->rx_buf[1] + chn * DLH_NUM_DATA_BYTES, > DLH_NUM_DATA_BYTES); > i++; > } > > + /* How do we know the iio buffer_list has only 2 items? */ Can only include items from the channels array at indexes up to the max scan_index in there, so 0 and 1 in this case (1 might not be present if only one channel is enabled). Sizes (and alignment) are given by storagebits so 4 bytes for each. > iio_push_to_buffers(indio_dev, tmp_buf); > > out:
On Fri, Feb 23, 2024 at 05:09:18PM +0000, Jonathan Cameron wrote: > On Thu, 22 Feb 2024 14:23:39 -0800 > Kees Cook <keescook@chromium.org> wrote: > > > Clang tripped over a FORTIFY warning in this code, and while it seems it > > may be a false positive in Clang due to loop unwinding, the code in > > question seems to make a lot of assumptions. > > Hi Kees, > > The assumptions are mostly characteristics of how the IIO buffers work > with the scan masks defined based on indexes in the driver provided > struct iio_chan_spec arrays. > > This driver is doing more work than it should need to as we long ago > moved some of the more fiddly handling into the IIO core. > > > Comments added, and the > > Clang warning[1] has been worked around by growing the array size. > > Also there was an uninitialized 4th byte in the __be32 array that was > > being sent through to iio_push_to_buffers(). > > That is indeed not good - the buffer should have been zero initialized. Okay, I'll get this respun and include the fix. > > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/2000 [1] > > Signed-off-by: Kees Cook <keescook@chromium.org> > > --- > > Cc: Jonathan Cameron <jic23@kernel.org> > > Cc: Lars-Peter Clausen <lars@metafoo.de> > > Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> > > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > Cc: "Nuno Sá" <nuno.sa@analog.com> > > Cc: linux-iio@vger.kernel.org > > --- > > drivers/iio/pressure/dlhl60d.c | 11 +++++++++-- > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/iio/pressure/dlhl60d.c b/drivers/iio/pressure/dlhl60d.c > > index 28c8269ba65d..9bbecd0bfe88 100644 > > --- a/drivers/iio/pressure/dlhl60d.c > > +++ b/drivers/iio/pressure/dlhl60d.c > > @@ -250,20 +250,27 @@ static irqreturn_t dlh_trigger_handler(int irq, void *private) > > struct dlh_state *st = iio_priv(indio_dev); > > int ret; > > unsigned int chn, i = 0; > > - __be32 tmp_buf[2]; > > + /* This was only an array pair of 4 bytes. */ > > True, which is the right size as far as I can tell. > If we need this to suppress a warning then comment should say that. Okay. I think I'll leave it as 2 and manually "unroll" the loop. > > > + __be32 tmp_buf[4] = { }; > > > > ret = dlh_start_capture_and_read(st); > > if (ret) > > goto out; > > > > + /* Nothing was checking masklength vs ARRAY_SIZE(tmp_buf)? */ > > Not needed but no way a compiler could know that. > > > + if (WARN_ON_ONCE(indio_dev->masklength > ARRAY_SIZE(tmp_buf))) > > + goto out; > > + > > for_each_set_bit(chn, indio_dev->active_scan_mask, > > This is all a bit pointless if not 'wrong' other than the > 4th byte uninitialized part. The limit can be hard coded as 2 as > that's a characteristic of this driver. > > For device that always read a particular set of channels they > should provide indio_dev->available_scan_masks = { BIT(1) | BIT(0), 0 }; > and then always push all the data making this always > > memcpy(&tmp_buf[0], &st->rx_buf[1], 3); > mempcy(&tmp_buf[1], &st->rx_buf[1] + 3, 3); Okay, so this could be unrolled manually to check just for bits 0 and 1? > > The buffer demux code in the IIO core will deal with repacking the data > if only one channel is enabled. > > > indio_dev->masklength) { > > - memcpy(tmp_buf + i, > > + /* This is copying 3 bytes. What about the 4th? */ > > + memcpy(&tmp_buf[i], > > &st->rx_buf[1] + chn * DLH_NUM_DATA_BYTES, > > DLH_NUM_DATA_BYTES); > > i++; > > } > > > > + /* How do we know the iio buffer_list has only 2 items? */ > > Can only include items from the channels array at indexes up to the max > scan_index in there, so 0 and 1 in this case (1 might not be present if only > one channel is enabled). Sizes (and alignment) are given by storagebits so > 4 bytes for each. This code pattern seems repeated through all of iio, so I guess we'll leave it as-is. It seems like it'd be nice to have a "length" argument to iio_push_to_buffers(), just to sanity check, but that would need to be a pretty large patch. :P > > > iio_push_to_buffers(indio_dev, tmp_buf); > > > > out: Thanks for looking at this! -Kees
On Fri, 23 Feb 2024 09:14:53 -0800 Kees Cook <keescook@chromium.org> wrote: > On Fri, Feb 23, 2024 at 05:09:18PM +0000, Jonathan Cameron wrote: > > On Thu, 22 Feb 2024 14:23:39 -0800 > > Kees Cook <keescook@chromium.org> wrote: > > > > > Clang tripped over a FORTIFY warning in this code, and while it seems it > > > may be a false positive in Clang due to loop unwinding, the code in > > > question seems to make a lot of assumptions. > > > > Hi Kees, > > > > The assumptions are mostly characteristics of how the IIO buffers work > > with the scan masks defined based on indexes in the driver provided > > struct iio_chan_spec arrays. > > > > This driver is doing more work than it should need to as we long ago > > moved some of the more fiddly handling into the IIO core. > > > > > Comments added, and the > > > Clang warning[1] has been worked around by growing the array size. > > > Also there was an uninitialized 4th byte in the __be32 array that was > > > being sent through to iio_push_to_buffers(). > > > > That is indeed not good - the buffer should have been zero initialized. > > Okay, I'll get this respun and include the fix. > > > > > > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/2000 [1] > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > > --- > > > Cc: Jonathan Cameron <jic23@kernel.org> > > > Cc: Lars-Peter Clausen <lars@metafoo.de> > > > Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> > > > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > > Cc: "Nuno Sá" <nuno.sa@analog.com> > > > Cc: linux-iio@vger.kernel.org > > > --- > > > drivers/iio/pressure/dlhl60d.c | 11 +++++++++-- > > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/iio/pressure/dlhl60d.c b/drivers/iio/pressure/dlhl60d.c > > > index 28c8269ba65d..9bbecd0bfe88 100644 > > > --- a/drivers/iio/pressure/dlhl60d.c > > > +++ b/drivers/iio/pressure/dlhl60d.c > > > @@ -250,20 +250,27 @@ static irqreturn_t dlh_trigger_handler(int irq, void *private) > > > struct dlh_state *st = iio_priv(indio_dev); > > > int ret; > > > unsigned int chn, i = 0; > > > - __be32 tmp_buf[2]; > > > + /* This was only an array pair of 4 bytes. */ > > > > True, which is the right size as far as I can tell. > > If we need this to suppress a warning then comment should say that. > > Okay. I think I'll leave it as 2 and manually "unroll" the loop. Without the available mask that is a little fiddly you'll have deal with channel 0 only enabled, channel 1 only enabled and both channels 0 and channel 1 enabled. Not too bad though as only 2 channels. > > > > > > + __be32 tmp_buf[4] = { }; > > > > > > ret = dlh_start_capture_and_read(st); > > > if (ret) > > > goto out; > > > > > > + /* Nothing was checking masklength vs ARRAY_SIZE(tmp_buf)? */ > > > > Not needed but no way a compiler could know that. > > > > > + if (WARN_ON_ONCE(indio_dev->masklength > ARRAY_SIZE(tmp_buf))) > > > + goto out; > > > + > > > for_each_set_bit(chn, indio_dev->active_scan_mask, > > > > This is all a bit pointless if not 'wrong' other than the > > 4th byte uninitialized part. The limit can be hard coded as 2 as > > that's a characteristic of this driver. > > > > For device that always read a particular set of channels they > > should provide indio_dev->available_scan_masks = { BIT(1) | BIT(0), 0 }; > > and then always push all the data making this always > > > > memcpy(&tmp_buf[0], &st->rx_buf[1], 3); > > mempcy(&tmp_buf[1], &st->rx_buf[1] + 3, 3); > > Okay, so this could be unrolled manually to check just for bits 0 and 1? Ideally it wouldn't check them - the hardwork has been done to read both channels anyway and the IIO core handles userspace or in kernel consumers that want a subset of what is enabled, but that needs the available_scan_masks to be set so that the IIO core knows all channels always enabled. > > > > > The buffer demux code in the IIO core will deal with repacking the data > > if only one channel is enabled. > > > > > indio_dev->masklength) { > > > - memcpy(tmp_buf + i, > > > + /* This is copying 3 bytes. What about the 4th? */ > > > + memcpy(&tmp_buf[i], > > > &st->rx_buf[1] + chn * DLH_NUM_DATA_BYTES, > > > DLH_NUM_DATA_BYTES); > > > i++; > > > } > > > > > > + /* How do we know the iio buffer_list has only 2 items? */ > > > > Can only include items from the channels array at indexes up to the max > > scan_index in there, so 0 and 1 in this case (1 might not be present if only > > one channel is enabled). Sizes (and alignment) are given by storagebits so > > 4 bytes for each. > > This code pattern seems repeated through all of iio, so I guess we'll > leave it as-is. It seems like it'd be nice to have a "length" argument > to iio_push_to_buffers(), just to sanity check, but that would need to > be a pretty large patch. :P yeah. Hindsight! We could add it in an incremental fashion though iio_push_to_bufs(struct iio_dev *indio_dev, void *buf, size_t buf_len) with a length parameter. The oddity that is iio_push_to_buffers_with_timestamp() would benefit here as that needs a bigger buffer than immediately apparent in the driver and we've had a few bugs around that over the years. It would probably be a one way check. I might have a play and see how useful this would be. > > > > > > iio_push_to_buffers(indio_dev, tmp_buf); > > > > > > out: > > Thanks for looking at this! > > -Kees >
diff --git a/drivers/iio/pressure/dlhl60d.c b/drivers/iio/pressure/dlhl60d.c index 28c8269ba65d..9bbecd0bfe88 100644 --- a/drivers/iio/pressure/dlhl60d.c +++ b/drivers/iio/pressure/dlhl60d.c @@ -250,20 +250,27 @@ static irqreturn_t dlh_trigger_handler(int irq, void *private) struct dlh_state *st = iio_priv(indio_dev); int ret; unsigned int chn, i = 0; - __be32 tmp_buf[2]; + /* This was only an array pair of 4 bytes. */ + __be32 tmp_buf[4] = { }; ret = dlh_start_capture_and_read(st); if (ret) goto out; + /* Nothing was checking masklength vs ARRAY_SIZE(tmp_buf)? */ + if (WARN_ON_ONCE(indio_dev->masklength > ARRAY_SIZE(tmp_buf))) + goto out; + for_each_set_bit(chn, indio_dev->active_scan_mask, indio_dev->masklength) { - memcpy(tmp_buf + i, + /* This is copying 3 bytes. What about the 4th? */ + memcpy(&tmp_buf[i], &st->rx_buf[1] + chn * DLH_NUM_DATA_BYTES, DLH_NUM_DATA_BYTES); i++; } + /* How do we know the iio buffer_list has only 2 items? */ iio_push_to_buffers(indio_dev, tmp_buf); out:
Clang tripped over a FORTIFY warning in this code, and while it seems it may be a false positive in Clang due to loop unwinding, the code in question seems to make a lot of assumptions. Comments added, and the Clang warning[1] has been worked around by growing the array size. Also there was an uninitialized 4th byte in the __be32 array that was being sent through to iio_push_to_buffers(). Link: https://github.com/ClangBuiltLinux/linux/issues/2000 [1] Signed-off-by: Kees Cook <keescook@chromium.org> --- Cc: Jonathan Cameron <jic23@kernel.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: "Nuno Sá" <nuno.sa@analog.com> Cc: linux-iio@vger.kernel.org --- drivers/iio/pressure/dlhl60d.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)