From: Joerg Roedel
Introduce a helper to check whether an exception came from the syscall
gap and use it in the SEV-ES code. Extend the check to also cover the
compatibility SYSCALL entry path.
Fixes: 315562c9af3d5 ("x86/sev-es: Adjust #VC IST Stack on entering NMI
handler"
From: Joerg Roedel
Reorganize the code and improve the comments to make the function more
readable and easier to understand.
Signed-off-by: Joerg Roedel
---
arch/x86/kernel/sev-es.c | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/arch
From: Joerg Roedel
Call irqentry_nmi_enter()/irqentry_nmi_exit() in the #VC handler to
correctly track the IRQ state during its execution.
Reported-by: Andy Lutomirski
Fixes: 0786138c78e79 ("x86/sev-es: Add a Runtime #VC Exception Handler")
Cc: sta...@vger.kernel.org # v5.10+
> No functional changes.
>
> Signed-off-by: Borislav Petkov
Reviewed-by: Joerg Roedel
> ---
> arch/x86/kernel/sev-es.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/sev-es.c b/arch/x86/kernel/sev-es.c
> index 84c1821819a
BTM optional for SVA
iommu/arm-smmu-v3: Add support for VHE
Joerg Roedel (2):
Merge tag 'arm-smmu-updates' of git://git.kernel.org/.../will/linux into
arm/smmu
Merge branches 'arm/renesas', 'arm/smmu', 'x86/amd', 'x86/vt-d' and
'core' into next
John Garry (7):
iova: Make
On Thu, Feb 18, 2021 at 04:28:36PM -0800, Andy Lutomirski wrote:
> On Thu, Feb 18, 2021 at 11:21 AM Joerg Roedel wrote:
> Can you give me an example, even artificial, in which the linked-list
> logic is useful?
So here we go, its of course artificial, but still:
1. #V
On Thu, Feb 18, 2021 at 09:49:06AM -0800, Andy Lutomirski wrote:
> I don't understand what this means. The whole entry mechanism on x86
> is structured so that we call a C function *and return from that C
> function without longjmp-like magic* with the sole exception of
> unwind_stack_do_exit().
Hi Andy,
On Wed, Feb 17, 2021 at 10:09:46AM -0800, Andy Lutomirski wrote:
> Can you get rid of the linked list hack while you're at it? This code
> is unnecessarily convoluted right now, and it seems to be just asking
> for weird bugs. Just stash the old value in a local variable, please.
From: Joerg Roedel
The code in the NMI handler to adjust the #VC handler IST stack is
needed in case an NMI hits when the #VC handler is still using its IST
stack.
But the check for this condition also needs to look if the regs->sp
value is trusted, meaning it was not set by user-space. Ext
From: Joerg Roedel
Better explain why this code is necessary and what it is doing.
Signed-off-by: Joerg Roedel
---
arch/x86/kernel/sev-es.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/sev-es.c b/arch/x86/kernel/sev-es.c
index
From: Joerg Roedel
Introduce a helper to check whether an exception came from the syscall
gap and use it in the SEV-ES code
Fixes: 315562c9af3d5 ("x86/sev-es: Adjust #VC IST Stack on entering NMI
handler")
Cc: sta...@vger.kernel.org # 5.10+
Signed-off-by: Joerg Roedel
---
arch/x
From: Joerg Roedel
Hi,
here are some changes to the Linux SEV-ES code to check whether the
value in regs->sp can be trusted, before checking whether it points to
the #VC IST stack.
Andy Lutomirski reported that it is entirely possible to reach this
function with a regs->sp value which w
On Tue, Feb 09, 2021 at 06:06:20PM +0530, Sai Prakash Ranjan wrote:
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 5e7fe519430a..6064187d9bb6 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -87,6 +87,7 @@ struct iommu_domain {
> void
On Mon, Feb 08, 2021 at 06:27:12AM -0600, Suravee Suthikulpanit wrote:
> drivers/iommu/amd/init.c | 45 ++--
> 1 file changed, 34 insertions(+), 11 deletions(-)
Applied, thanks.
On Wed, Feb 10, 2021 at 08:25:11AM -0800, Dave Hansen wrote:
> This is all very cute. But, if this fails, it means that the .data
> section is now garbage, right?. I guess failing here is less
> entertaining than trying to run the kernel with random garbage in .data,
> but it doesn't make it
On Wed, Feb 10, 2021 at 10:19:38AM -0500, Konrad Rzeszutek Wilk wrote:
> I think I am missing something obvious here - but why would you want
> EFI support disabled?
I don't want EFI support disabled, this is just a way to trigger this
boot-path. In real life it is triggered by 32-bit GRUB EFI
Hi Konrad,
On Wed, Feb 10, 2021 at 09:58:35AM -0500, Konrad Rzeszutek Wilk wrote:
> What GRUB versions are we talking about (CC-ing Daniel Kiper, who owns
> GRUB).
I think this was about 32-bit GRUB builds used by distributions. I
personally tested it with a kernel which has EFI support
From: Joerg Roedel
Exception handling in the startup_32 boot path requires the CS
selector to be correctly set up. Reload it from the current GDT.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/head_64.S | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git
From: Joerg Roedel
Disable the exception handling before booting the kernel to make sure
any exceptions that happen during early kernel boot are not directed to
the pre-decompression code.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/idt_64.c | 14 ++
arch/x86/boot
From: Joerg Roedel
Hi,
these patches add support for the 32-bit boot in the decompressor
code. This is needed to boot an SEV-ES guest on some firmware and grub
versions. The patches also add the necessary CPUID sanity checks and a
32-bit version of the C-bit check.
Other updates included here
From: Joerg Roedel
Add a #VC exception handler which is used when the kernel still executes
in protected mode. This boot-path already uses CPUID, which will cause #VC
exceptions in an SEV-ES guest.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/head_64.S | 6 ++
arch/x86/boot
From: Joerg Roedel
There are a few places left in the SEV-ES C code where hlt loops and/or
terminate requests are implemented. Replace them all with calls to
sev_es_terminate().
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/sev-es.c | 12 +++-
arch/x86/kernel/sev-es
From: Joerg Roedel
Check whether the hypervisor reported the correct C-bit when running as
an SEV guest. Using a wrong C-bit position could be used to leak
sensitive data from the guest to the hypervisor.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/head_64.S | 80
From: Joerg Roedel
The 32-bit #VC handler has no GHCB and can only handle CPUID exit codes.
It is needed by the early boot code to handle #VC exceptions raised in
verify_cpu() and to get the position of the C bit.
But the CPUID information comes from the hypervisor, which is untrusted
and might
From: Joerg Roedel
This boot path needs exception handling when it is used with SEV-ES.
Setup an IDT and provide a helper function to write IDT entries for
use in 32-bit protected mode.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/head_64.S | 73 +-
1
On Mon, Feb 08, 2021 at 02:35:25PM +0800, Yong Wu wrote:
> On Mon, 2021-02-08 at 07:10 +0100, Lukas Bulwahn wrote:
> > Commit 6af4873852c4 ("MAINTAINERS: Add entry for MediaTek IOMMU") mentions
> > the pattern 'drivers/iommu/mtk-iommu*', but the files are actually named
> > with an underscore, not
On Fri, Feb 05, 2021 at 03:46:17PM +0300, Dan Carpenter wrote:
> drivers/iommu/mtk_iommu.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Applied, thanks.
all.
----
Joerg Roedel (1):
iommu: Check dev->iommu in dev_iommu_priv_get() before dereferencing it
include/linux/iommu.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Please pull.
Thanks,
Joerg
On Thu, Feb 04, 2021 at 03:00:01PM +, Colin King wrote:
> drivers/iommu/mtk_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
Wei Liu
Acked-by: Joerg Roedel
> ---
> v6:
> 1. Simplify code due to changes in a previous patch.
> ---
> arch/x86/hyperv/irqdomain.c | 25 +
> arch/x86/include/asm/mshyperv.h | 4 +
> drivers/iommu/hyperv-iommu.c| 177 +++-
>
On Thu, Feb 04, 2021 at 09:25:58AM +, Will Deacon wrote:
> On Wed, Feb 03, 2021 at 01:59:36PM +, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently the check for domid < 0 is always false because domid
> > is unsigned. Fix this by making it signed.
> >
> > Addresses-CoverityL
Hi Baolu,
On Tue, Feb 02, 2021 at 12:40:55PM +0800, Lu Baolu wrote:
> @@ -514,7 +514,8 @@ enum acpi_dmar_type {
> ACPI_DMAR_TYPE_ROOT_ATS = 2,
> ACPI_DMAR_TYPE_HARDWARE_AFFINITY = 3,
> ACPI_DMAR_TYPE_NAMESPACE = 4,
> - ACPI_DMAR_TYPE_RESERVED = 5 /* 5 and greater are
On Tue, Feb 02, 2021 at 12:40:56PM +0800, Lu Baolu wrote:
> + case ACPI_DMAR_TYPE_SATC:
> + satc = container_of(header, struct acpi_dmar_satc, header);
> + pr_info("SATC flags: 0x%x\n", satc->flags);
> + break;
Did the pr_info() slip through or is there a
On Tue, Feb 02, 2021 at 12:40:57PM +0800, Lu Baolu wrote:
> + list_for_each_entry_rcu(satcu, _satc_units, list) {
> + satc = container_of(satcu->hdr, struct acpi_dmar_satc, header);
> + if (satc->segment == pci_domain_nr(dev->bus) &&
> satcu->atc_required) {
You can
On Mon, Feb 01, 2021 at 05:06:23PM -0800, Douglas Anderson wrote:
> drivers/iommu/iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
On Tue, Feb 02, 2021 at 06:42:57PM +0800, Chunyan Zhang wrote:
> From: Chunyan Zhang
>
> This iommu module can be used by Unisoc's multimedia devices, such as
> display, Image codec(jpeg) and a few signal processors, including
> VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel
On Tue, Feb 02, 2021 at 06:42:57PM +0800, Chunyan Zhang wrote:
> +static phys_addr_t sprd_iommu_iova_to_phys(struct iommu_domain *domain,
> +dma_addr_t iova)
> +{
> + struct sprd_iommu_domain *dom = to_sprd_domain(domain);
> + unsigned long flags;
>
From: Joerg Roedel
The dev_iommu_priv_get() needs a similar check to
dev_iommu_fwspec_get() to make sure no NULL-ptr is dereferenced.
Fixes: 05a0542b456e1 ("iommu/amd: Store dev_data as device iommu private data")
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=2112
On Tue, Feb 02, 2021 at 02:34:34PM +, Robin Murphy wrote:
> Nope, I believe if Arm Ltd. had any involvement in this I'd know about it :)
Okay, got confused by thinking of ARM as the CPU architecture, not the
company :)
But given the intel/ and amd/ subdirectories refer to company names as
On Tue, Feb 02, 2021 at 01:53:41PM +, Will Deacon wrote:
> On Tue, Feb 02, 2021 at 02:34:56PM +0100, Joerg Roedel wrote:
> > On Mon, Feb 01, 2021 at 03:46:33PM +, Will Deacon wrote:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
> >
On Sat, Jan 30, 2021 at 11:19:07PM +0800, Lu Baolu wrote:
> drivers/iommu/intel/Makefile | 2 +-
> drivers/iommu/intel/iommu.c| 1 -
> include/trace/events/intel_iommu.h | 2 --
> 3 files changed, 1 insertion(+), 4 deletions(-)
Applied, thanks.
On Mon, Feb 01, 2021 at 03:46:33PM +, Will Deacon wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
> tags/arm-smmu-updates
Pulled, thanks Will.
Hi Linus,
The following changes since commit 6ee1d745b7c9fd573fba142a2efdad76a9f1cb04:
Linux 5.11-rc5 (2021-01-24 16:47:14 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.11-rc5
for you to fetch changes up to
Hello Lai,
On Sun, Jan 24, 2021 at 10:11:14PM +0800, Lai Jiangshan wrote:
> > +
> > + /*
> > +* No need to switch back to the IST stack. The current stack is
> > either
> > +* identical to the stack in the IRET frame or the VC fall-back
> > stack,
> > +* so it is
On Tue, Jan 26, 2021 at 01:06:29PM +, Shameer Kolothum wrote:
> The device iommu probe/attach might have failed leaving dev->iommu
> to NULL and device drivers may still invoke these functions resulting
> a crash in iommu vendor driver code. Hence make sure we check that.
>
> Signed-off-by:
On Tue, Jan 26, 2021 at 07:53:35PM +0800, Lianbo Jiang wrote:
> Lianbo Jiang (2):
> dma-iommu: use static-key to minimize the impact in the fast-path
> iommu: use the __iommu_attach_device() directly for deferred attach
>
> drivers/iommu/dma-iommu.c | 29 +++--
>
On Tue, Jan 19, 2021 at 12:35:00PM +0800, Lu Baolu wrote:
> An incorrect address mask is being used in the qi_flush_dev_iotlb_pasid()
> to check the address alignment. This leads to a lot of spurious kernel
> warnings:
>
> [ 485.837093] DMAR: Invalidate non-aligned address 7f76f47f9000, order 0
On Tue, Jan 19, 2021 at 07:16:14PM +0800, Lianbo Jiang wrote:
> Lianbo Jiang (2):
> dma-iommu: use static-key to minimize the impact in the fast-path
> iommu: use the __iommu_attach_device() directly for deferred attach
>
> drivers/iommu/dma-iommu.c | 29 +++--
>
On Fri, Jan 15, 2021 at 08:42:02AM +0800, Lu Baolu wrote:
> The Access/Dirty bits in the first level page table entry will be set
> whenever a page table entry was used for address translation or write
> permission was successfully translated. This is always true when using
> the first-level page
On Thu, Jan 14, 2021 at 05:04:00PM +0800, Lu Baolu wrote:
> This adds a new trace event to track the submissions of requests to the
> invalidation queue. This event will provide the information like:
> - IOMMU name
> - Invalidation type
> - Descriptor raw data
>
> A sample output like:
> |
On Thu, Jan 14, 2021 at 04:50:21PM +0800, Lu Baolu wrote:
> The pasid based IOTLB and devTLB invalidation code is duplicate in
> several places. Consolidate them by using the common helpers.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/pasid.c | 18 ++--
>
Hi Suravee,
On Tue, Dec 15, 2020 at 01:36:52AM -0600, Suravee Suthikulpanit wrote:
> Suravee Suthikulpanit (13):
> iommu/amd: Re-define amd_iommu_domain_encode_pgtable as inline
> iommu/amd: Prepare for generic IO page table framework
> iommu/amd: Move pt_root to struct amd_io_pgtable
>
On Tue, Dec 15, 2020 at 01:30:21PM -0800, t...@redhat.com wrote:
> drivers/iommu/amd/init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
On Mon, Dec 28, 2020 at 09:51:12PM +0800, Zheng Yongjun wrote:
> spinlock can be initialized automatically with DEFINE_SPINLOCK()
> rather than explicitly calling spin_lock_init().
>
> Signed-off-by: Zheng Yongjun
> ---
> drivers/iommu/amd/iommu_v2.c | 4 +---
> 1 file changed, 1 insertion(+),
On Wed, Jan 06, 2021 at 09:35:05PM +0800, John Garry wrote:
> Just some tidy-up to IOVA and core code.
>
> Based on v5.11-rc2
>
> Differences to v1:
> - Add core IOMMU patches
>
> John Garry (6):
> iova: Make has_iova_flush_queue() private
> iova: Delete copy_reserved_iova()
> iova: Stop
On Mon, Dec 14, 2020 at 09:44:38PM +0800, Zheng Yongjun wrote:
> Replace a comma between expression statements by a semicolon.
>
> Signed-off-by: Zheng Yongjun
> ---
> drivers/iommu/amd/init.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
What tree is this against? This code does
On Tue, Nov 17, 2020 at 11:09:53AM +0100, Joerg Roedel wrote:
> Hi,
>
> last week I spent in the hospital and had an unplanned surgery from
> which I am recovering now. The recovery will take a few weeks, which
> unfortunatly does not allow me to fulfill my IOMMU maintainer dut
Hi,
last week I spent in the hospital and had an unplanned surgery from
which I am recovering now. The recovery will take a few weeks, which
unfortunatly does not allow me to fulfill my IOMMU maintainer duties or
do any other serious work in front of a computer.
Luckily Will Deacon volunteered
Hi Linus,
The following changes since commit 3cea11cd5e3b00d91caf0b4730194039b45c5891:
Linux 5.10-rc2 (2020-11-01 14:43:51 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.10-rc2
for you to fetch changes up to
On Fri, Oct 30, 2020 at 10:37:22AM +0800, Yi Sun wrote:
> We found a few issues about PRQ. So, two patches are cooked to
> fix them. Please have a review. Thanks!
>
> Changes from v1:
>
> - Modify subject of patch 1 to make it more accurate.
> - Move get_domain_info() up to the
Hi Suravee,
On Wed, Oct 28, 2020 at 11:18:24PM +, Suravee Suthikulpanit wrote:
> AMD IOMMU requires 4k-aligned pages for the event log, the PPR log,
> and the completion wait write-back regions. However, when allocating
> the pages, they could be part of large mapping (e.g. 2M) page.
> This
On Wed, Oct 28, 2020 at 03:07:25PM +0800, Lu Baolu wrote:
> Fixes: e2726daea583d ("iommu/vt-d: debugfs: Add support to show page table
> internals")
> Cc: sta...@vger.kernel.org#v5.6+
> Reported-and-tested-by: Xu Pengfei
> Signed-off-by: Lu Baolu
Applied for v5.10, thanks.
Hi Baolu,
On Mon, Oct 26, 2020 at 02:30:08PM +0800, Lu Baolu wrote:
> @@ -264,7 +266,8 @@ int iommu_probe_device(struct device *dev)
>*/
> iommu_alloc_default_domain(group, dev);
>
> - if (group->default_domain)
> + if (group->default_domain &&
> +
On Thu, Oct 15, 2020 at 02:50:02AM +, Suravee Suthikulpanit wrote:
> Certain device drivers allocate IO queues on a per-cpu basis.
> On AMD EPYC platform, which can support up-to 256 cpu threads,
> this can exceed the current MAX_IRQ_PER_TABLE limit of 256,
> and result in the error message:
>
Hi,
On Tue, Nov 03, 2020 at 11:58:26AM +0200, Joonas Lahtinen wrote:
> Would that work for you? We intend to send the feature pull requests
> to DRM for 5.11 in the upcoming weeks.
For the IOMMU side it is best to include the workaround for now. When
the DRM fixes are merged into v5.11-rc1
On Wed, Oct 28, 2020 at 11:03:05AM -0700, Erdem Aktas wrote:
> I might be missing something here but I think what you say is only
> correct for the kvm_hypercall4 cases. All other functions use a
> smaller number of registers. #VC blindly assumes that all those
> registers are used in the vmcall
The following commit has been merged into the x86/seves branch of tip:
Commit-ID: c9f09539e16e281f92a27760fdfae71e8af036f6
Gitweb:
https://git.kernel.org/tip/c9f09539e16e281f92a27760fdfae71e8af036f6
Author:Joerg Roedel
AuthorDate:Wed, 28 Oct 2020 17:46:58 +01:00
Committer
The following commit has been merged into the x86/seves branch of tip:
Commit-ID: 2411cd82112397bfb9d8f0f19cd46c3d71e0ce67
Gitweb:
https://git.kernel.org/tip/2411cd82112397bfb9d8f0f19cd46c3d71e0ce67
Author:Joerg Roedel
AuthorDate:Wed, 28 Oct 2020 17:46:59 +01:00
Committer
The following commit has been merged into the x86/seves branch of tip:
Commit-ID: ed7b895f3efb5df184722f5a30f8164fcaffceb1
Gitweb:
https://git.kernel.org/tip/ed7b895f3efb5df184722f5a30f8164fcaffceb1
Author:Joerg Roedel
AuthorDate:Wed, 28 Oct 2020 17:46:56 +01:00
Committer
The following commit has been merged into the x86/seves branch of tip:
Commit-ID: 86ce43f7dde81562f58b24b426cef068bd9f7595
Gitweb:
https://git.kernel.org/tip/86ce43f7dde81562f58b24b426cef068bd9f7595
Author:Joerg Roedel
AuthorDate:Wed, 28 Oct 2020 17:46:57 +01:00
Committer
The following commit has been merged into the x86/seves branch of tip:
Commit-ID: 3ad84246a4097010f3ae3d6944120c0be00e9e7a
Gitweb:
https://git.kernel.org/tip/3ad84246a4097010f3ae3d6944120c0be00e9e7a
Author:Joerg Roedel
AuthorDate:Wed, 28 Oct 2020 17:46:55 +01:00
Committer
On Wed, Oct 28, 2020 at 12:50:07PM -0400, Arvind Sankar wrote:
> On Wed, Oct 28, 2020 at 09:23:52AM +0100, Joerg Roedel wrote:
> > On Mon, Oct 26, 2020 at 07:27:06PM +0100, Borislav Petkov wrote:
> > > A couple of lines above you call get_sev_encryption_bit() which a
From: Joerg Roedel
The early #VC handler which doesn't have a GHCB can only handle CPUID
exit codes. It is needed by the early boot code to handle #VC
exceptions raised in verify_cpu() and to get the position of the C
bit.
But the CPUID information comes from the hypervisor, which is untrusted
From: Joerg Roedel
Hi,
here are some enhancements to the SEV(-ES) code in the Linux kernel to
self-protect it against some newly detected hypervisor attacks. There are 3
attacks addressed here:
1) Hypervisor does not present the SEV-enabled bit via CPUID
2) The Hypervisor
From: Joerg Roedel
MMIO memory is usually not mapped encrypted, so there is no reason to
support emulated MMIO when it is mapped encrypted.
Prevent a possible hypervisor attack where a RAM page is mapped as
an MMIO page in the nested page-table, so that any guest access to it
will trigger a #VC
On Tue, Oct 27, 2020 at 12:08:12PM +0100, Borislav Petkov wrote:
> On Wed, Oct 21, 2020 at 02:39:36PM +0200, Joerg Roedel wrote:
> > diff --git a/arch/x86/kernel/sev_verify_cbit.S
> > b/arch/x86/kernel/sev_verify_cbit.S
> > new file mode 100644
> > index
From: Joerg Roedel
Check whether the hypervisor reported the correct C-bit when running as
an SEV guest. Using a wrong C-bit position could be used to leak
sensitive data from the guest to the hypervisor.
The check function is in arch/x86/kernel/sev_verify_cbit.S so that it
can be re-used
From: Joerg Roedel
When SEV is enabled the kernel requests the C-Bit position again from
the hypervisor to built its own page-table. Since the hypervisor is an
untrusted source the C-bit position needs to be verified before the
kernel page-table is used.
Call the sev_verify_cbit() function
From: Joerg Roedel
Introduce sev_status and initialize it together with sme_me_mask to have
an indicator which SEV features are enabled.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/mem_encrypt.S | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git
On Tue, Oct 27, 2020 at 04:19:45PM -0700, Erdem Aktas wrote:
> Looking at the VMWARE_VMCALL(cmd, eax, ebx, ecx, edx) definition, it
> seems to me only 4 registers are required to be shared with
> hypervisor. I don't know much about vmware but is not
> vmware_sev_es_hcall_prepare expose more
On Mon, Oct 26, 2020 at 07:27:06PM +0100, Borislav Petkov wrote:
> A couple of lines above you call get_sev_encryption_bit() which already
> reads MSR_AMD64_SEV. Why not set sev_status there too instead of reading
> that MSR again here?
>
> It can read that MSR once and use sev_status(%rip) from
On Tue, Oct 27, 2020 at 11:38:46AM +0100, Borislav Petkov wrote:
> So why are we doing those checks here at all then? I mean, the HV
> can tell us whatever it wants, i.e., make sure those checks pass but
> still report the C-bit at the wrong position. Which means that those
> checks are simply
80 ("x86/mm/ident_map: Add 5-level paging support")
> ---
> arch/x86/mm/ident_map.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Reviewed-by: Joerg Roedel
On Tue, Oct 27, 2020 at 04:14:15PM -0700, Erdem Aktas wrote:
> It seems to me that the kvm_sev_es_hcall_prepare is leaking more
> information than it is needed. Is this an expected behavior?
What exactly is leaked? The kvm hypercall uses RAX, RBX, RCX, RDX and
RSI for parameters.
Regards,
On Tue, Oct 27, 2020 at 03:40:07PM +0300, Kirill A. Shutemov wrote:
> BTW, what happens if we underestimate BOOT_PGT_SIZE? Do we overwrite
> something?
The boot code will print an error and stop the machine when allocating a
page-table page fails.
I also think that bumping BOOT_PGT_SIZE up to
On Tue, Oct 20, 2020 at 12:04:28PM -0400, Arvind Sankar wrote:
> This is called from both assembly and C, but anyway, you're already
> assuming r10 and r11 can be clobbered safely, and you just took out the
> save/restores in set_sev_encryption_mask, which is actually called only
> from assembly.
From: Joerg Roedel
When SEV is enabled the kernel requests the C-Bit position again from
the hypervisor to built its own page-table. Since the hypervisor is an
untrusted source the C-bit position needs to be verified before the
kernel page-table is used.
Call the sev_verify_cbit() function
From: Joerg Roedel
Introduce sev_status and initialize it together with sme_me_mask to have
an indicator which SEV features are enabled.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/mem_encrypt.S | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch
From: Joerg Roedel
The early #VC handler which doesn't have a GHCB can only handle CPUID
exit codes. It is needed by the early boot code to handle #VC
exceptions raised in verify_cpu() and to get the position of the C
bit.
But the CPUID information comes from the hypervisor, which is untrusted
From: Joerg Roedel
Check whether the hypervisor reported the correct C-bit when running as
an SEV guest. Using a wrong C-bit position could be used to leak
sensitive data from the guest to the hypervisor.
The check function is in arch/x86/kernel/sev_verify_cbit.S so that it
can be re-used
From: Joerg Roedel
MMIO memory is usually not mapped encrypted, so there is no reason to
support emulated MMIO when it is mapped encrypted.
This prevents a possible hypervisor attack where it maps a RAM page as
an MMIO page in the nested page-table, so that any guest access to it
will trigger
From: Joerg Roedel
Hi,
here are some enhancements to the SEV(-ES) code in the Linux kernel to
self-protect it against some newly detected hypervisor attacks. There
are 3 attacks addressed here:
1) Hypervisor does not present the SEV-enabled bit via CPUID
2) The Hypervisor
On Tue, Oct 20, 2020 at 10:12:59AM -0400, Arvind Sankar wrote:
> On Tue, Oct 20, 2020 at 02:18:54PM +0200, Joerg Roedel wrote:
> Why use r10-r12 rather than the caller-save registers? Even for the head
> code where you need to perserve the cr3 value you can just return it in
> rax?
I
On Tue, Oct 20, 2020 at 10:33:12AM -0400, Arvind Sankar wrote:
> That doesn't feel like a big loss: if a malicious hypervisor wanted to
> induce completely random code execution, it can do that anyway by just
> messing with the guest-to-host translation, no?
Yes, but relying on defined behavior
From: Joerg Roedel
The early #VC handler which doesn't have a GHCB can only handle CPUID
exit codes. It is needed by the early boot code to handle #VC
exceptions raised in verify_cpu() and to get the position of the C
bit.
But the CPUID information comes from the hypervisor, which is untrusted
From: Joerg Roedel
Check whether the hypervisor reported the correct C-bit when running as
an SEV guest. Using a wrong C-bit position could be used to leak
sensitive data from the guest to the hypervisor.
The check function is in arch/x86/kernel/sev_verify_cbit.S so that it
can be re-used
From: Joerg Roedel
MMIO memory is usually not mapped encrypted, so there is no reason to
support emulated MMIO when it is mapped encrypted.
This prevents a possible hypervisor attack where it maps a RAM page as
an MMIO page in the nested page-table, so that any guest access to it
will trigger
From: Joerg Roedel
Hi,
here are some enhancements to the SEV(-ES) code in the Linux kernel to
self-protect it against some newly detected hypervisor attacks. There
are 3 attacks addressed here:
1) Hypervisor does not present the SEV-enabled bit via CPUID
2) The Hypervisor
From: Joerg Roedel
Introduce sev_status and initialize it together with sme_me_mask to have
an indicator which SEV features are enabled.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/mem_encrypt.S | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch
From: Joerg Roedel
When SEV is enabled the kernel requests the C-Bit position again from
the hypervisor to built its own page-table. Since the hypervisor is an
untrusted source the C-bit position needs to be verified before the
kernel page-table is used.
Call the sev_verify_cbit() function
101 - 200 of 6605 matches
Mail list logo
