linux-kernel - Re: [PATCH] x86/tdx: Support vmalloc() for tdx_enc_status

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: <20240709110656.GEZo0Z0EoI4xmHDx9b@fat_crate.local>
Date: Tue, 9 Jul 2024 13:06:56 +0200
From: Borislav Petkov <bp@...en8.de>
To: Dexuan Cui <decui@...rosoft.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"open list:X86 TRUST DOMAIN EXTENSIONS (TDX)" <linux-coco@...ts.linux.dev>,
	"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <linux-kernel@...r.kernel.org>,
	Michael Kelley <mikelley@...rosoft.com>,
	Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>,
	Rick Edgecombe <rick.p.edgecombe@...el.com>,
	Kai Huang <kai.huang@...el.com>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] x86/tdx: Support vmalloc() for tdx_enc_status_changed()

On Mon, Jul 08, 2024 at 09:45:24PM +0000, Dexuan Cui wrote:
> x86/tdx: Fix set_memory_decrypted() for vmalloc() buffers
> 
> When a TD mode Linux TDX VM runs on Hyper-V, the Linux hv_netvsc driver
> needs to share a vmalloc()'d  buffer with the host OS: see
> netvsc_init_buf() -> vmbus_establish_gpadl() -> ... ->
> __vmbus_establish_gpadl() -> set_memory_decrypted().
> 
> Currently set_memory_decrypted() doesn't work for a vmalloc()'d  buffer
> because tdx_enc_status_changed() uses __pa(vaddr), i.e., it assumes that
> the 'vaddr' can't be from vmalloc(), and consequently hv_netvsc fails
> to load.
> 
> Fix this by handling the pages one by one.
> 
> hv_netvsc is the first user of vmalloc() + set_memory_decrypted(), which
> is why nobody noticed this until now.
> 
> v6.6 is a longterm kernel, which is used by some distros, so I hope
> this patch can be in v6.6.y and newer, so it won't be carried out of tree.

So this is a corner-case thing. I guess CC:stable is ok, we have packported
similar "fixes" in the past.

> I think the patch (without Kirill's kexec fix)  has been well tested, e.g.,
> it has been in Ubuntu's linux-azure kernel for about 2 years. Kirill's 
> kexec fix works in my testing and it looks safe to me. 

You seem to think that a patch which has been tested in some out-of-tree
kernel,

- gets modified
- gets applied to the upstream kernel
- it *breaks* a use case,

and then it can still be considered tested.

Are you seriously claiming that?!

> I hope this can be in 6.11-rc1 if you see no high risks. 
> It's also fine to me if you decide to queue the patch after 6.11-rc1.

Yes, it will be after -rc1 because what you consider "tested" and what I do
consider "tested" can just as well be from two different planets.

> > > Co-developed-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> https://lwn.net/ml/linux-kernel/20230412151937.pxfyralfichwzyv6@box/

Since you'd go the length to quote the mail messages which gave you the tags
but you will not read what I point you to, lemme read it for you:

"Both Tested-by and Reviewed-by tags, once received on mailing list from
tester or reviewer, should be added by author to the applicable patches when
sending next versions.  However if the patch has changed substantially in
following version, these tags might not be applicable anymore and thus should
be removed.  Usually removal of someone's Tested-by or Reviewed-by tags should
be mentioned in the patch changelog (after the '---' separator)."

>From Documentation/process/submitting-patches.rst

Again, if you want to keep sending patches to the kernel, I'd strongly urge
you to read that document!

> This is not really a newly submitted patch :-)

If you still think that and you want to keep your tags, all I can give you is
a big fat NAK until you read and understand how the process works.

Your decision.

-- 
Regards/Gruss,
    Boris.

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