Received-SPF: pass (google.com: domain of linux-kernel+bounces-187391-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Thu, 23 May 2024 13:21:12 +0200
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Nikolay Borisov <nik.borisov@suse.com>
Cc: cve@kernel.org, linux-kernel@vger.kernel.org,
	linux-cve-announce@vger.kernel.org
Subject: Re: CVE-2024-35802: x86/sev: Fix position dependent variable
 references in startup code
Message-ID: <2024052334-cable-serotonin-fa2b@gregkh>
References: <2024051738-CVE-2024-35802-959d@gregkh>
 <b3a6ea47-8628-4edc-aee5-e5051955124a@suse.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b3a6ea47-8628-4edc-aee5-e5051955124a@suse.com>

On Thu, May 23, 2024 at 02:14:57PM +0300, Nikolay Borisov wrote:
> 
> 
> 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.

Isn't crashing SEV guests a problem with "availability"?  That term
comes from the CVE definition of what we need to mark as a CVE, which is
why this one was picked.

thanks,

greg k-h