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-next>] [day] [month] [year] [list]
Date:   Wed, 8 Dec 2021 12:43:00 +0100
From:   Lukas Bulwahn <lukas.bulwahn@...il.com>
To:     Daniel Silsby <dansilsby@...il.com>,
        Paul Cercueil <paul@...pouillou.net>,
        Paul Burton <paul.burton@...s.com>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Cc:     "open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: config CPU_SUPPORTS_HUGEPAGES refers to the non-existing symbol ARCH_PHYS_ADDR_T_64BIT

Dear Daniel, dear Paul, dear Thomas,

In commit d4a451d5fc84 ("arch: remove the ARCH_PHYS_ADDR_T_64BIT
config symbol") from April 2018, the config ARCH_PHYS_ADDR_T_64BIT was
removed and all instances of that config were refactored
appropriately. Since then, it is recommended to use the config
PHYS_ADDR_T_64BIT instead.

Then in June 2019, commit 171543e75272 ("MIPS: Disallow
CPU_SUPPORTS_HUGEPAGES for XPA,EVA") introduces the expression
"!(32BIT && (ARCH_PHYS_ADDR_T_64BIT || EVA))" for config
CPU_SUPPORTS_HUGEPAGES, which refers to the non-existing symbol
ARCH_PHYS_ADDR_T_64BIT.

In this expression, the symbol ARCH_PHYS_ADDR_T_64BIT always evaluates
to false. So, the expression is effectively "!(32BIT && EVA)" right
now.

Now, it is a bit unclear what is intended here, especially since it
was not noticed to be wrong for the last two years:

- The commit is buggy, but nobody noticed it so far. It was intended
to refer to PHYS_ADDR_T_64BIT. We need to provide a fix that changes
the semantics by referring to the intended Kconfig symbol.

- The commit is just a bit unclean and that is why nobody noticed. The
reference to ARCH_PHYS_ADDR_T_64BIT can be dropped. We can provide a
clean-up patch that preserves the current semantics.

Once the situation for that commit and its intention is clear, I am
happy to provide the suitable patch.

Best regards,

Lukas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ