linux-kernel - Re: [PATCH] ACPI: OSL: Initialize output value

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

Message-ID: <17bad2c5-e401-45cc-8351-cc28e461257c@ancud.ru>
Date: Tue, 5 Mar 2024 14:25:52 +0300
From: Nikita Kiryushin <kiryushin@...ud.ru>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Len Brown <lenb@...nel.org>, Bob Moore <robert.moore@...el.com>,
 linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
 lvc-project@...uxtesting.org
Subject: Re: [PATCH] ACPI: OSL: Initialize output value

On 11/21/23 23:05, Rafael J. Wysocki wrote:
> So wouldn't it be better to avoid modifying *value at all if
> raw_pci_read() returns an error?

Avoiding of modification of *value at all seems better idea to me than 
setting it to arbitrary initializing value, indeed.

In that case, buffer initialization can be ditched, and *value set only 
in case of success.

> And if it returns a success, why wouldn't it be trusted?
>
My concern is, that raw_pci_read() wraps platform-specific handlers, 
that should conform to the next rules:

1) in case of success, they must set value32 (or else, uninitialized 
data would leak to acpi_os_read_pci_configuration caller);

2) they should use passed &value32 only to set it (or else, 
uninitialized data would be used/passed somewhere, is it safe?);

Is there any way to be sure, that all the existing and future 
platform-specific pci-read handlers conform?