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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220822162805.GD4098765@roeck-us.net>
Date:   Mon, 22 Aug 2022 09:28:05 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     "Farber, Eliav" <farbere@...zon.com>
Cc:     jdelvare@...e.com, robh+dt@...nel.org, mark.rutland@....com,
        linux-hwmon@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, talel@...zon.com, hhhawa@...zon.com,
        jonnyc@...zon.com, hanochu@...zon.com, ronenk@...zon.com,
        itamark@...zon.com, shellykz@...zon.com, shorer@...zon.com,
        amitlavi@...zon.com, almogbs@...zon.com, dwmw@...zon.co.uk,
        rtanwar@...linear.com
Subject: Re: [PATCH v2 16/16] hwmon: (mr75203) add debugfs to read and write
 temperature coefficients

On Mon, Aug 22, 2022 at 04:59:43PM +0300, Farber, Eliav wrote:
> On 8/19/2022 2:11 AM, Guenter Roeck wrote:
> > On Wed, Aug 17, 2022 at 05:43:21AM +0000, Eliav Farber wrote:
> > > This change adds debugfs to read and write TS coefficients - g, h, j and
> > > cal5.
> > > 
> > > The coefficients can vary between product and product, so to calibrate
> > > them it can be very useful to to be able to modify them on the fly.
> > > 
> > > e.g.
> > > 
> > > cat /sys/kernel/debug/940f23d0000.pvt/ts_coeff_cal5
> > > 4096
> > > 
> > > echo 83000 > sys/kernel/debug/940f23d0000.pvt/ts_coeff_g
> > > 
> > 
> > What happens if you write 0 into all those attributes, or 0xffffffff ?
> The driver equation is:
> T = G + H * (n / cal5 - 0.5) + J * F
> So I added protection for cal5 not being 0.
> Besides that there is no limitation on what these values can be.
> I can't really think of any other logical limitation I can apply.
> 
There needs to be an overflow protection. I am quite sure that 0xffffffff
would result in overflows and thus in quite random reported values.

Thanks,
Guenter

> --
> Regards, Eliav

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ