From: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>
To: Thiago Jung Bauermann <bauerman@linux.ibm.com>,
"x86@kernel.org" <x86@kernel.org>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Christoph Hellwig" <hch@lst.de>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>, "Ram Pai" <linuxram@us.ibm.com>
Subject: Re: [PATCH 2/2] x86/kvmclock: set_memory_decrypted() takes number of pages
Date: Tue, 22 Jan 2019 21:43:39 +0000 [thread overview]
Message-ID: <d40ab37e-ae46-dce8-21f9-b62c062cab84@amd.com> (raw)
In-Reply-To: <20190122211758.8317-2-bauerman@linux.ibm.com>
On 1/22/19 3:17 PM, Thiago Jung Bauermann wrote:
> From: Ram Pai <linuxram@us.ibm.com>
>
> set_memory_decrypted() expects the number of PAGE_SIZE pages to decrypt.
> kvmclock_init_mem() instead passes number of bytes. This decrypts a huge
> number of pages resulting in data corruption.
Same comment as patch 1/2 in this series. This is not correct. See
comments below.
>
> Fixed it.
>
> [ bauermann: Slightly reworded commit message and added Fixes: tag. ]
> Fixes: 6a1cac56f41f ("x86/kvm: Use __bss_decrypted attribute in shared variables")
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> ---
> arch/x86/kernel/kvmclock.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> Note: Found by code inspection. I don't have a way to test.
>
> diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> index e811d4d1c824..b5c867dd2c8d 100644
> --- a/arch/x86/kernel/kvmclock.c
> +++ b/arch/x86/kernel/kvmclock.c
> @@ -251,8 +251,7 @@ static void __init kvmclock_init_mem(void)
> * be mapped decrypted.
> */
> if (sev_active()) {
> - r = set_memory_decrypted((unsigned long) hvclock_mem,
> - 1UL << order);
> + r = set_memory_decrypted((unsigned long) hvclock_mem, 1);
Again, not correct. A number of pages were allocated based on the order.
That number is calculated using the shift in the call. Hardcoding this to
1 is wrong.
Thanks,
Tom
> if (r) {
> __free_pages(p, order);
> hvclock_mem = NULL;
>
next prev parent reply other threads:[~2019-01-22 21:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-22 21:17 [PATCH 1/2] dma-direct: set_memory_{en,de}crypted() take number of pages Thiago Jung Bauermann
2019-01-22 21:17 ` [PATCH 2/2] x86/kvmclock: set_memory_decrypted() takes " Thiago Jung Bauermann
2019-01-22 21:43 ` Lendacky, Thomas [this message]
2019-01-22 21:40 ` [PATCH 1/2] dma-direct: set_memory_{en,de}crypted() take " Lendacky, Thomas
2019-01-22 22:38 ` Thiago Jung Bauermann
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=d40ab37e-ae46-dce8-21f9-b62c062cab84@amd.com \
--to=thomas.lendacky@amd.com \
--cc=bauerman@linux.ibm.com \
--cc=bp@alien8.de \
--cc=hch@lst.de \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=m.szyprowski@samsung.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=robin.murphy@arm.com \
--cc=tglx@linutronix.de \
--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