Received-SPF: pass (google.com: domain of linux-kernel+bounces-187388-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <b3a6ea47-8628-4edc-aee5-e5051955124a@suse.com>
Date: Thu, 23 May 2024 14:14:57 +0300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: CVE-2024-35802: x86/sev: Fix position dependent variable
 references in startup code
To: cve@kernel.org, linux-kernel@vger.kernel.org,
 linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
References: <2024051738-CVE-2024-35802-959d@gregkh>
Content-Language: en-US
From: Nikolay Borisov <nik.borisov@suse.com>
In-Reply-To: <2024051738-CVE-2024-35802-959d@gregkh>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 17.05.24 г. 16:23 ч., Greg Kroah-Hartman wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> x86/sev: Fix position dependent variable references in startup code
> 
> The early startup code executes from a 1:1 mapping of memory, which
> differs from the mapping that the code was linked and/or relocated to
> run at. The latter mapping is not active yet at this point, and so
> symbol references that rely on it will fault.
> 
> Given that the core kernel is built without -fPIC, symbol references are
> typically emitted as absolute, and so any such references occuring in
> the early startup code will therefore crash the kernel.
> 
> While an attempt was made to work around this for the early SEV/SME
> startup code, by forcing RIP-relative addressing for certain global
> SEV/SME variables via inline assembly (see snp_cpuid_get_table() for
> example), RIP-relative addressing must be pervasively enforced for
> SEV/SME global variables when accessed prior to page table fixups.
> 
> __startup_64() already handles this issue for select non-SEV/SME global
> variables using fixup_pointer(), which adjusts the pointer relative to a
> `physaddr` argument. To avoid having to pass around this `physaddr`
> argument across all functions needing to apply pointer fixups, introduce
> a macro RIP_RELATIVE_REF() which generates a RIP-relative reference to
> a given global variable. It is used where necessary to force
> RIP-relative accesses to global variables.
> 
> For backporting purposes, this patch makes no attempt at cleaning up
> other occurrences of this pattern, involving either inline asm or
> fixup_pointer(). Those will be addressed later.
> 
>    [ bp: Call it "rip_rel_ref" everywhere like other code shortens
>      "rIP-relative reference" and make the asm wrapper __always_inline. ]
> 
> The Linux kernel CVE team has assigned CVE-2024-35802 to this issue.


I'd like to dispute this CVE since it doesn't constitute a security 
related bug. Sure, it might crash a SEV guest during boot but it doesn't 
constitute a security issue per-se.


> 
> 
> Affected and fixed versions
> ===========================
> 
> 	Fixed in 6.1.84 with commit fe272b61506b
> 	Fixed in 6.6.24 with commit 0982fd6bf0b8
> 	Fixed in 6.7.12 with commit 66fa3fcb474b
> 	Fixed in 6.8.3 with commit 954a4a878144
> 	Fixed in 6.9 with commit 1c811d403afd
> 
> Please see https://www.kernel.org for a full list of currently supported
> kernel versions by the kernel community.
> 
> Unaffected versions might change over time as fixes are backported to
> older supported kernel versions.  The official CVE entry at
> 	https://cve.org/CVERecord/?id=CVE-2024-35802
> will be updated if fixes are backported, please check that for the most
> up to date information about this issue.
> 
> 
> Affected files
> ==============
> 
> The file(s) affected by this issue are:
> 	arch/x86/coco/core.c
> 	arch/x86/include/asm/asm.h
> 	arch/x86/include/asm/coco.h
> 	arch/x86/include/asm/mem_encrypt.h
> 	arch/x86/kernel/sev-shared.c
> 	arch/x86/kernel/sev.c
> 	arch/x86/mm/mem_encrypt_identity.c
> 
> 
> Mitigation
> ==========
> 
> The Linux kernel CVE team recommends that you update to the latest
> stable kernel version for this, and many other bugfixes.  Individual
> changes are never tested alone, but rather are part of a larger kernel
> release.  Cherry-picking individual commits is not recommended or
> supported by the Linux kernel community at all.  If however, updating to
> the latest release is impossible, the individual changes to resolve this
> issue can be found at these commits:
> 	https://git.kernel.org/stable/c/fe272b61506bb1534922ef07aa165fd3c37a6a90
> 	https://git.kernel.org/stable/c/0982fd6bf0b822876f2e93ec782c4c28a3f85535
> 	https://git.kernel.org/stable/c/66fa3fcb474b2b892fe42d455a6f7ec5aaa98fb9
> 	https://git.kernel.org/stable/c/954a4a87814465ad61cc97c1cd3de1525baaaf07
> 	https://git.kernel.org/stable/c/1c811d403afd73f04bde82b83b24c754011bd0e8