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: <7fad3782-daf5-654c-f89d-e4dfb92bbf8f@oracle.com>
Date:   Thu, 20 Oct 2022 10:22:17 -0400
From:   Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:     Juergen Gross <jgross@...e.com>, Jan Beulich <jbeulich@...e.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, xen-devel@...ts.xenproject.org,
        Dan Carpenter <dan.carpenter@...cle.com>,
        linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH] x86/xen: silence smatch warning in pmu_msr_chk_emulated()


On 10/20/22 9:34 AM, Juergen Gross wrote:
> On 20.10.22 15:16, Jan Beulich wrote:
>> On 20.10.2022 13:37, Juergen Gross wrote:
>>> Commit 8714f7bcd3c2 ("xen/pv: add fault recovery control to pmu msr
>>> accesses") introduced code resulting in a warning issued by the smatch
>>> static checker, claiming to use an uninitialized variable.
>>>
>>> This is a false positive, but work around the warning nevertheless.
>>
>> The risk of introducing a problem might be quite low here, but in general
>> it exists: With the adjustment you remove any chance of the compiler
>> spotting a missing initialization before use. And I'm not convinced using
>> 0 in such a case would actually be ending up sufficiently benign.
>
> Hmm, an alternative would be to initialize it to -1 and add a test for the
> index to be >= 0 before using it.
>
> Or to live with the smash warning with the chance, that a compiler might be
> warning for the same reason in the future.


Is smatch complaining about both variables or just index? There are two cases in is_intel_pmu_msr() where it returns true but index is not set so perhaps that's what bothers smatch? It shold not complain if is_intel_pmu_msr() returns false.


-boris

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ