From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "petr@tesarici.cz" <petr@tesarici.cz>
Cc: "Lutomirski, Andy" <luto@kernel.org>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"Reshetova, Elena" <elena.reshetova@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>, "Christopherson,,
Sean" <seanjc@google.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"Yamahata, Isaku" <isaku.yamahata@intel.com>,
"Cui, Dexuan" <decui@microsoft.com>,
"mikelley@microsoft.com" <mikelley@microsoft.com>,
"m.szyprowski@samsung.com" <m.szyprowski@samsung.com>,
"hch@lst.de" <hch@lst.de>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"bp@alien8.de" <bp@alien8.de>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"sathyanarayanan.kuppuswamy@linux.intel.com"
<sathyanarayanan.kuppuswamy@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH 04/10] swiotlb: Use free_decrypted_pages()
Date: Tue, 31 Oct 2023 17:29:25 +0000 [thread overview]
Message-ID: <3903bbaade7ba9577da88d053b67b8bfdf0d3582.camel@intel.com> (raw)
In-Reply-To: <20231031181340.30233c17@meshulam.tesarici.cz>
On Tue, 2023-10-31 at 18:13 +0100, Petr Tesařík wrote:
> Thank you for the explanation. So, after set_memory_decrypted()
> fails,
> the pages become Schroedinger-crypted, but since its true state
> cannot
> be observed by the guest kernel, it stays as such forever.
>
> Sweet.
>
Yes... The untrusted host (the part of the VMM TDX is defending
against) gets to specify the return code of these operations (success
or failure). But the coco(a general term for TDX and similar from other
vendors) threat model doesn't include DOS. So the guest should trust
the return code as far as trying to not crash, but not trust it in
regards to the potential to leak data.
It's a bit to ask of the callers, but the other solution we discussed
was to panic the guest if any weirdness is observed by the VMM, in
which case the callers would never see the error. And of course
panicing the kernel is Bad. So that is how we arrived at this request
of the callers. Appreciate the effort to handle it on that side.
> Hm, should I incorporate this knowledge into a v2 of my patch and
> address both issues?
That sounds good to me! Feel free to CC me if you would like, and I can
scrutinize it for this particular issue.
next prev parent reply other threads:[~2023-10-31 17:29 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-17 20:24 [PATCH 00/10] Handle set_memory_XXcrypted() errors Rick Edgecombe
2023-10-17 20:24 ` [PATCH 01/10] mm: Add helper for freeing decrypted memory Rick Edgecombe
2023-10-17 20:24 ` [PATCH 02/10] x86/mm/cpa: Reject incorrect encryption change requests Rick Edgecombe
2023-10-18 8:44 ` Ingo Molnar
2023-10-18 15:53 ` Edgecombe, Rick P
2023-10-17 20:24 ` [PATCH 03/10] kvmclock: Use free_decrypted_pages() Rick Edgecombe
2023-10-18 5:20 ` Kuppuswamy Sathyanarayanan
2023-10-18 15:57 ` Edgecombe, Rick P
2023-10-17 20:24 ` [PATCH 04/10] swiotlb: " Rick Edgecombe
2023-10-18 4:43 ` Christoph Hellwig
2023-10-18 15:55 ` Edgecombe, Rick P
2023-10-31 10:43 ` Petr Tesařík
2023-10-31 15:54 ` Edgecombe, Rick P
2023-10-31 17:13 ` Petr Tesařík
2023-10-31 17:29 ` Edgecombe, Rick P [this message]
2023-11-01 6:27 ` Petr Tesařík
2023-11-01 14:40 ` Edgecombe, Rick P
2023-10-17 20:25 ` [PATCH 05/10] ptp: " Rick Edgecombe
2023-10-17 20:25 ` [PATCH 06/10] dma: " Rick Edgecombe
2023-10-18 6:24 ` Christoph Hellwig
2023-10-18 17:09 ` Edgecombe, Rick P
2023-10-18 17:42 ` Robin Murphy
2023-10-23 16:46 ` Edgecombe, Rick P
2023-10-23 17:22 ` Robin Murphy
2023-10-23 17:27 ` Edgecombe, Rick P
2023-10-17 20:25 ` [RFC 07/10] hv: " Rick Edgecombe
2023-10-17 20:25 ` [RFC 08/10] hv: Track decrypted status in vmbus_gpadl Rick Edgecombe
2023-10-17 20:25 ` [RFC 09/10] hv_nstvsc: Don't free decrypted memory Rick Edgecombe
2023-10-17 20:25 ` [RFC 10/10] uio_hv_generic: " Rick Edgecombe
2023-10-19 17:05 ` [PATCH 00/10] Handle set_memory_XXcrypted() errors Michael Kelley (LINUX)
2023-10-19 19:13 ` Dave Hansen
2023-10-23 16:47 ` Michael Kelley (LINUX)
2023-10-23 16:57 ` Dave Hansen
2023-10-23 17:01 ` Edgecombe, Rick P
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3903bbaade7ba9577da88d053b67b8bfdf0d3582.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=elena.reshetova@intel.com \
--cc=hch@lst.de \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux.dev \
--cc=isaku.yamahata@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=luto@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mikelley@microsoft.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=petr@tesarici.cz \
--cc=robin.murphy@arm.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox