linux-kernel - Re: [PATCH] arm: Extend the check for RAM in /dev/mem

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: <20190712085602.v2tncu5tsngtvbww@shell.armlinux.org.uk>
Date:   Fri, 12 Jul 2019 09:56:02 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     "Raslan, KarimAllah" <karahmed@...zon.de>
Cc:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "anshuman.khandual@....com" <anshuman.khandual@....com>,
        "yaojun8558363@...il.com" <yaojun8558363@...il.com>,
        "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "james.morse@....com" <james.morse@....com>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "info@...ux.net" <info@...ux.net>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "yuzhao@...gle.com" <yuzhao@...gle.com>,
        "rppt@...ux.ibm.com" <rppt@...ux.ibm.com>,
        "anders.roxell@...aro.org" <anders.roxell@...aro.org>,
        "will@...nel.org" <will@...nel.org>
Subject: Re: [PATCH] arm: Extend the check for RAM in /dev/mem

On Fri, Jul 12, 2019 at 02:58:18AM +0000, Raslan, KarimAllah wrote:
> On Fri, 2019-07-12 at 08:06 +0530, Anshuman Khandual wrote:
> > 
> > On 07/12/2019 03:51 AM, KarimAllah Ahmed wrote:
> > > 
> > > Some valid RAM can live outside kernel control (e.g. using mem= kernel
> > > command-line). For these regions, pfn_valid would return "false" causing
> > > system RAM to be mapped as uncached. Use memblock instead to identify RAM.
> > 
> > Once the remaining memory is outside of the kernel (as the admin would have
> > intended with mem= command line) what is the particular concern regarding
> > the way those get mapped (cached or not) ? It is not to be used any way.
> 
> They can be used by user-space which might lead to them being used by the 
> kernel. One use-case would be using them as guest memory for KVM as I detailed 
> here:
> 
> https://lwn.net/Articles/778240/

>From the 32-bit ARM point of view...

What if someone's already doing something similar with a non-coherent
DSP and is relying on the current behaviour?  This change is a user
visible behavioural change that could end up breaking userspace.

In other words, it isn't something we should rush into.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up