linux-kernel - Re: Logging Behavior under arch/x86/kernel

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>] [day] [month] [year] [list]

Message-ID: <Yv/RHa3fCwVhDaIo@zn.tnic>
Date:   Fri, 19 Aug 2022 20:06:21 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Zhihao Lin <zh.lin@...l.utoronto.ca>
Cc:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Logging Behavior under arch/x86/kernel

Hi,

On Thu, Aug 18, 2022 at 03:08:44PM +0000, Zhihao Lin wrote:
> 2. At the end of wakeup_secondary_cpu_via_init, send_status is
> checked and given an error-level log message. However, according
> to the control flow analysis, it is unclear that which of
> safe_apic_wait_icr_idle (line 870 or line 918) is checked because
> the loop (which contains the third call) may or may not execute.

Well, does it matter which is checked?

AFAICT, it always checks the right one. :-)

> In this case, my tool alerts that this log statement doesn’t provide
> sufficient information for error diagnostic.

The pr_err() calls at the end of the function do catch the case when
either send_status or accept_status are != 0.

> pci_write_config_dword
> 
>   *   arch/x86/kernel/amd_nb.c

That has been probably overlooked during review. If we had to be
pedantic, we should check all those retvals. I guess not that
important...

HTH.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette