linux-kernel - Re: [PATCH 0/5] Remove s390 sw-emulated hugepages and cleanup

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: <20150602094640.4fedc046@BR9TG4T3.de.ibm.com>
Date:	Tue, 2 Jun 2015 09:46:40 +0200
From:	Dominik Dingel <dingel@...ux.vnet.ibm.com>
To:	Christian Borntraeger <borntraeger@...ibm.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>
Cc:	linux-kernel@...r.kernel.org,
	Russell King <linux@....linux.org.uk>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Tony Luck <tony.luck@...el.com>,
	Fenghua Yu <fenghua.yu@...el.com>,
	James Hogan <james.hogan@...tec.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>,
	Michael Ellerman <mpe@...erman.id.au>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	linux390@...ibm.com, "David S. Miller" <davem@...emloft.net>,
	Chris Metcalf <cmetcalf@...hip.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Zhang Zhen <zhenzhang.zhang@...wei.com>,
	David Rientjes <rientjes@...gle.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Nathan Lynch <nathan_lynch@...tor.com>,
	Andy Lutomirski <luto@...capital.net>,
	Michael Holzheu <holzheu@...ux.vnet.ibm.com>,
	Hugh Dickins <hughd@...gle.com>,
	Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	"Jason J. Herne" <jjherne@...ux.vnet.ibm.com>,
	Davidlohr Bueso <dave@...olabs.net>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Luiz Capitulino <lcapitulino@...hat.com>,
	Mike Kravetz <mike.kravetz@...cle.com>,
	linux-arm-kernel@...ts.infradead.org, linux-ia64@...r.kernel.org,
	linux-metag@...r.kernel.org, linux-mips@...ux-mips.org,
	linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
	linux-sh@...r.kernel.org, sparclinux@...r.kernel.org
Subject: Re: [PATCH 0/5] Remove s390 sw-emulated hugepages and cleanup

On Mon, 01 Jun 2015 09:35:57 +0200
Christian Borntraeger <borntraeger@...ibm.com> wrote:

> Am 28.05.2015 um 13:52 schrieb Dominik Dingel:
> > Hi everyone,
> > 
> > there is a potential bug with KVM and hugetlbfs if the hardware does not
> > support hugepages (EDAT1).
> > We fix this by making EDAT1 a hard requirement for hugepages and 
> > therefore removing and simplifying code.
> 
> The cleanup itself is nice and probably the right thing to do. 
> Emulating large pages makes the code more complex and asks for
> trouble (as outlined above)
> 
> The only downside that I see is that z/VM as of today does not
> announce EDAT1 for its guests so the "emulated" large pages for
> hugetlbfs would be useful in that case. The current code allocates
> the page table only once and shares it for all mappers - which is
> useful for some big databases that spawn hundreds of processes with
> shared mappings of several hundred GBs. In these cases we do save
> a decent amount of page table memory. 

To limit the damage done, we could always allocate page tables with pgstes for that case.
That would allow one guest manipulating another guests storage keys,
but at least would prevent random memory overwrites in the host.

Another thing we could do, make software emulated large pages a kernel config option
and only if KVM is not selected allow it, visa versa.

@Martin what do you think?

Thanks,
	Dominik

> Not sure if that case is actually important, though.
> 
> Christian
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/