linux-kernel - [PATCH v2 0/2] mm: unexpected behavior of __ioremap

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]

Message-Id: <20210611042147.80744-1-yaohuiwang@linux.alibaba.com>
Date:   Fri, 11 Jun 2021 12:21:45 +0800
From:   Yaohui Wang <yaohuiwang@...ux.alibaba.com>
To:     dave.hansen@...ux.intel.com
Cc:     luto@...nel.org, peterz@...radead.org, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH v2 0/2] mm: unexpected behavior of __ioremap_caller

Due to some boundary calculation & boundary judgment issues,
__ioremap_caller may not work as expected. This may raise the risk of
misusing ioremap_xxx functions, and further, incur terrible performance
issues.

For example, suppose [phys_addr ~ phys_addr + PAGE_SIZE] is normal RAM.
Calling ioremap(phys_addr, PAGE_SIZE-1) will succeed (but it should not).
This will set the cache flag of the phys_addr's directing mapping pte to
be PCD. What's worse, iounmap won't revert this cache flag in the
directing mapping. So the pte in the directing mapping keeps polluted
until we use workarounds (calling ioremap_cache on phys_addr) to fix the
cache bit. If there is important data/code in the polluted page, which is
accessed frequently, then the performance of the machine will drop
terribly.

Here are two patches addressing this issue. The first address the boundary
calculation issue and the second one addresses the boundary judgment
issue.

Yahui Wang (2):
  mm: fix pfn calculation mistake in __ioremap_check_ram
  mm: fix boundary judgement issues

 arch/x86/mm/ioremap.c | 4 ++--
 kernel/resource.c     | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.25.1