linux-kernel - Re: [PATCHv2 2/2] x86/mm: Make memremap(MEMREMAP

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: <20241121114952.GCZz8eYEVa3yubYQzO@fat_crate.local>
Date: Thu, 21 Nov 2024 12:49:52 +0100
From: Borislav Petkov <bp@...en8.de>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>,
	Albert Ou <aou@...s.berkeley.edu>,
	Alexei Starovoitov <ast@...nel.org>,
	Andrea Parri <parri.andrea@...il.com>,
	Arnd Bergmann <arnd@...db.de>,
	Daniel Borkmann <daniel@...earbox.net>,
	Eric Chan <ericchancf@...gle.com>, Jason Gunthorpe <jgg@...pe.ca>,
	Kai Huang <kai.huang@...el.com>,
	Kefeng Wang <wangkefeng.wang@...wei.com>,
	Kent Overstreet <kent.overstreet@...ux.dev>,
	Palmer Dabbelt <palmer@...osinc.com>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Russell King <linux@...linux.org.uk>,
	Samuel Holland <samuel.holland@...ive.com>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Yuntao Wang <ytcoode@...il.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-riscv@...ts.infradead.org,
	Tom Lendacky <thomas.lendacky@....com>,
	Ashish Kalra <ashish.kalra@....com>,
	"Maciej W. Rozycki" <macro@...am.me.uk>
Subject: Re: [PATCHv2 2/2] x86/mm: Make memremap(MEMREMAP_WB) map memory as
 encrypted by default

On Tue, Nov 19, 2024 at 10:21:05AM +0200, Kirill A. Shutemov wrote:
> Sure, we can workaround every place that touches such ranges.

Every place? Which every place? I thought this is only an EISA issue?

Then clearly your changelogs need to expand considerably more what we're
*really* addressing here.

> Or we can address problem at the root and make creating decrypted/shared
> mappings explicit.

What is the problem? That KVM implicitly converts memory to shared? Why does
KVM do that an can it be fixed not to?

Doesn't sound like the guest's problem.

Or maybe this needs a lot more explanation what we're fixing here.

> Such mappings have both functional (as we see here) and security
> implications (VMM can manipulate the guest memory range). We should not
> create decrypted mappings by default on legacy interfaces.

So we're getting closer.

The changes themselves are fine but your text is missing a lot about what
we're fixing here. When I asked, I barely scratched the surface. So can we
elaborate here pls?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette