On Thu, Nov 9, 2023 at 7:09 PM Nikita Kiryushin <[email protected]> wrote:
>
> In lpit_update_residency there is a possibility of overflow
> in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
That would be a TSC ticking at hundreds of millions of kHz if I'm not
mistaken. Why is it really a concern?
> Change multiplication to mul_u32_u32.
So why is this better?
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: eeb2d80d502a ("ACPI / LPIT: Add Low Power Idle Table (LPIT) support")
> Signed-off-by: Nikita Kiryushin <[email protected]>
> ---
> drivers/acpi/acpi_lpit.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpi_lpit.c b/drivers/acpi/acpi_lpit.c
> index c5598b6d5db8..794962c5c88e 100644
> --- a/drivers/acpi/acpi_lpit.c
> +++ b/drivers/acpi/acpi_lpit.c
> @@ -105,7 +105,7 @@ static void lpit_update_residency(struct
> lpit_residency_info *info,
> return;
> info->frequency = lpit_native->counter_frequency ?
> - lpit_native->counter_frequency : tsc_khz * 1000;
> + lpit_native->counter_frequency : mul_u32_u32(tsc_khz, 1000U);
> if (!info->frequency)
> info->frequency = 1;
> -- 2.34.1
>
On Tue, Nov 21, 2023 at 8:56 PM Rafael J. Wysocki <[email protected]> wrote:
>
> On Thu, Nov 9, 2023 at 7:09 PM Nikita Kiryushin <[email protected]> wrote:
> >
> > In lpit_update_residency there is a possibility of overflow
> > in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
>
> That would be a TSC ticking at hundreds of millions of kHz if I'm not
> mistaken.
That should be "hundreds of thousands of kHz", so I was mistaken.
But anyway:
> Why is it really a concern?
>
> > Change multiplication to mul_u32_u32.
>
> So why is this better?
>
> > Found by Linux Verification Center (linuxtesting.org) with SVACE.
> >
> > Fixes: eeb2d80d502a ("ACPI / LPIT: Add Low Power Idle Table (LPIT) support")
> > Signed-off-by: Nikita Kiryushin <[email protected]>
> > ---
> > drivers/acpi/acpi_lpit.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/acpi_lpit.c b/drivers/acpi/acpi_lpit.c
> > index c5598b6d5db8..794962c5c88e 100644
> > --- a/drivers/acpi/acpi_lpit.c
> > +++ b/drivers/acpi/acpi_lpit.c
> > @@ -105,7 +105,7 @@ static void lpit_update_residency(struct
> > lpit_residency_info *info,
> > return;
> > info->frequency = lpit_native->counter_frequency ?
> > - lpit_native->counter_frequency : tsc_khz * 1000;
> > + lpit_native->counter_frequency : mul_u32_u32(tsc_khz, 1000U);
> > if (!info->frequency)
> > info->frequency = 1;
> > -- 2.34.1
> >
My reasoning was around something like:
1) tsc_khz is declared as unsigned int tsc_khz;
2) tsc_khz * 1000 would overflow, if the result is larger, than an
unsigned int could hold;
3) given tsc_khz * 1000 > UINT_MAX is bad, tsc_khz > UINT_MAX / 1000 is bad;
4) if UINT_MAX is 4294967295, than tsc_khz > 4294967.295 is bad, for
example 4294968 would lead to overflow;
5) 4294968 kHz is 4294.968 MHz, which seems realistically high to me.
For me, tsc: Refined TSC clocksource calibration: 3393.624 MHz
(seems like, it is derived from the same value,
pr_info("Refined TSC clocksource calibration: %lu.%03lu MHz\n",
(unsigned long)tsc_khz / 1000,
(unsigned long)tsc_khz % 1000);
)
Not sure about the math above, but it seemed reasonable enough to me to
switch to overflow-resilient arithmetic here.
On 11/21/23 23:14, Rafael J. Wysocki wrote:
> On Tue, Nov 21, 2023 at 8:56 PM Rafael J. Wysocki <[email protected]> wrote:
> That should be "hundreds of thousands of kHz", so I was mistaken.
>
> But anyway:
>
>> Why is it really a concern?
>>
On Wed, Nov 22, 2023 at 8:41 PM Nikita Kiryushin <[email protected]> wrote:
>
> My reasoning was around something like:
>
> 1) tsc_khz is declared as unsigned int tsc_khz;
>
> 2) tsc_khz * 1000 would overflow, if the result is larger, than an
> unsigned int could hold;
>
> 3) given tsc_khz * 1000 > UINT_MAX is bad, tsc_khz > UINT_MAX / 1000 is bad;
>
> 4) if UINT_MAX is 4294967295, than tsc_khz > 4294967.295 is bad, for
> example 4294968 would lead to overflow;
>
> 5) 4294968 kHz is 4294.968 MHz, which seems realistically high to me.
>
> For me, tsc: Refined TSC clocksource calibration: 3393.624 MHz
>
> (seems like, it is derived from the same value,
>
> pr_info("Refined TSC clocksource calibration: %lu.%03lu MHz\n",
> (unsigned long)tsc_khz / 1000,
> (unsigned long)tsc_khz % 1000);
>
> )
OK, fair enough.
> Not sure about the math above, but it seemed reasonable enough to me to
> switch to overflow-resilient arithmetic here.