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: <20220428104612.GA14515@willie-the-truck>
Date:   Thu, 28 Apr 2022 11:46:12 +0100
From:   Will Deacon <will@...nel.org>
To:     Kefeng Wang <wangkefeng.wang@...wei.com>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCH 0/4] arm64: Cleanup ioremap() and support ioremap_prot()

On Wed, Apr 27, 2022 at 08:14:09PM +0800, Kefeng Wang wrote:
> Let's arm64 use GENERIC_IOREMAP to cleanup code, and
> support ioremap_prot()/HAVE_IOREMAP_PROT, which could
> enable generic_access_phys().
> 
> Kefeng Wang (4):
>   mm: ioremap: Setup phys_addr of struct vm_struct
>   mm: ioremap: Add arch_ioremap/iounmap_check()
>   arm64: mm: Convert to GENERIC_IOREMAP
>   arm64: Add HAVE_IOREMAP_PROT support
> 
>  .../features/vm/ioremap_prot/arch-support.txt |  2 +-
>  arch/arm64/Kconfig                            |  2 +
>  arch/arm64/include/asm/io.h                   | 14 +--
>  arch/arm64/include/asm/pgtable.h              | 10 +++
>  arch/arm64/kernel/acpi.c                      |  2 +-
>  arch/arm64/mm/hugetlbpage.c                   | 10 ---
>  arch/arm64/mm/ioremap.c                       | 86 +++----------------
>  include/asm-generic/io.h                      |  3 +
>  mm/ioremap.c                                  | 21 ++++-
>  9 files changed, 56 insertions(+), 94 deletions(-)

That's not a massively compelling diffstat for a cleanup, in all honesty.
I looked at generic_access_phys() to try to figure out why we would want
that on arm64, but it seems like it's related to mmap() of devices in
userspace. Bearing in mind that CONFIG_STRICT_DEVMEM=y by default, please
can you justify why this is something worth doing?

Will

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ