Re: CVE-2024-35802: x86/sev: Fix position dependent variable references in startup code

Re: CVE-2024-35802: x86/sev: Fix position dependent variable references in startup code

[Nikolay Borisov]

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

Re: CVE-2024-35802: x86/sev: Fix position dependent variable references in startup code

[Greg Kroah-Hartman]

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

Re: CVE-2024-35802: x86/sev: Fix position dependent variable references in startup code

[Nikolay Borisov]

On 23.05.24 г. 14:21 ч., Greg Kroah-Hartman wrote:
> 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.

But availability has never been one of the tenets of CoCo, in fact in 
sev-snp/tdx the VMM is explicitly considered outside of the TCB so 
availability cannot be guaranteed.

Re: CVE-2024-35802: x86/sev: Fix position dependent variable references in startup code

[Greg Kroah-Hartman]

On Thu, May 23, 2024 at 03:01:56PM +0300, Nikolay Borisov wrote:
> 
> 
> On 23.05.24 г. 14:21 ч., Greg Kroah-Hartman wrote:
> > 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.
> 
> But availability has never been one of the tenets of CoCo, in fact in
> sev-snp/tdx the VMM is explicitly considered outside of the TCB so
> availability cannot be guaranteed.

This has nothing to do with CoCo (but really, ability of the host to
crash the guest seems like it should be as I would assume that CoCo
guests would want to be able to be run...)

Official CVE definition of vulnerability from cve.org:
	An instance of one or more weaknesses in a Product that can be
	exploited, causing a negative impact to confidentiality, integrity, or
	availability; a set of conditions or behaviors that allows the
	violation of an explicit or implicit security policy.

I think "able to crash SEV guests" is a direct weakness that has to do
with availability here which is why I marked it as such (as did other
reviewers.)  Now if CoCo wants to claim it as part of their security
implicit or explicit security policy, all the better :)

thanks,

greg k-h

Re: CVE-2024-35802: x86/sev: Fix position dependent variable references in startup code

[Nikolay Borisov]

On 23.05.24 г. 15:17 ч., Greg Kroah-Hartman wrote:
> On Thu, May 23, 2024 at 03:01:56PM +0300, Nikolay Borisov wrote:
>>
>>
>> On 23.05.24 г. 14:21 ч., Greg Kroah-Hartman wrote:
>>> 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.
>>
>> But availability has never been one of the tenets of CoCo, in fact in
>> sev-snp/tdx the VMM is explicitly considered outside of the TCB so
>> availability cannot be guaranteed.
> 
> This has nothing to do with CoCo (but really, ability of the host to
> crash the guest seems like it should be as I would assume that CoCo
> guests would want to be able to be run...)
> 
> Official CVE definition of vulnerability from cve.org:
> 	An instance of one or more weaknesses in a Product that can be
> 	exploited, causing a negative impact to confidentiality, integrity, or

I don't see how this is exactly "explotaible" i.e if a guest is run and 
it crashes during bootup it simply won't run. Can this be considered 
active exploitation of an issue?

> 	availability; a set of conditions or behaviors that allows the
> 	violation of an explicit or implicit security policy.
> 
> I think "able to crash SEV guests" is a direct weakness that has to do
> with availability here which is why I marked it as such (as did other
> reviewers.)  Now if CoCo wants to claim it as part of their security
> implicit or explicit security policy, all the better :)
> 
> thanks,
> 
> greg k-h

Re: CVE-2024-35802: x86/sev: Fix position dependent variable references in startup code

[Greg Kroah-Hartman]

On Thu, May 23, 2024 at 03:21:05PM +0300, Nikolay Borisov wrote:
> 
> 
> On 23.05.24 г. 15:17 ч., Greg Kroah-Hartman wrote:
> > On Thu, May 23, 2024 at 03:01:56PM +0300, Nikolay Borisov wrote:
> > > 
> > > 
> > > On 23.05.24 г. 14:21 ч., Greg Kroah-Hartman wrote:
> > > > 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.
> > > 
> > > But availability has never been one of the tenets of CoCo, in fact in
> > > sev-snp/tdx the VMM is explicitly considered outside of the TCB so
> > > availability cannot be guaranteed.
> > 
> > This has nothing to do with CoCo (but really, ability of the host to
> > crash the guest seems like it should be as I would assume that CoCo
> > guests would want to be able to be run...)
> > 
> > Official CVE definition of vulnerability from cve.org:
> > 	An instance of one or more weaknesses in a Product that can be
> > 	exploited, causing a negative impact to confidentiality, integrity, or
> 
> I don't see how this is exactly "explotaible" i.e if a guest is run and it
> crashes during bootup it simply won't run. Can this be considered active
> exploitation of an issue?

Isn't preventing a guest from running something that causes a lack of
avaiability?  Again, that's why we picked this commit, it keeps the
system from working properly as expected.

thanks,

greg k-h

Re: CVE-2024-35802: x86/sev: Fix position dependent variable references in startup code

[Michal Hocko]

On Thu 23-05-24 14:14:57, Nikolay Borisov wrote:
[...]
> 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.

Let me add analysis by Joerg here:
: This is not a security issue. The patch works around clangs compiler behavior
: where it inserts absolute references to kernel addresses. This breaks kernel
: boot because at the time this code runs the kernel still runs direct-mapped and
: needs to rely on RIP-relative addressing only.
: 
: Any breakage there would be detected at early boot of the kernel by a fatal
: crash, which can not be exploited. Also, our kernels are not compiled with
: clang, so from that perspective this is also not an issue for us either.

So this is a functional fix for clang builds.
-- 
Michal Hocko
SUSE Labs

Re: CVE-2024-35802: x86/sev: Fix position dependent variable references in startup code

[Greg Kroah-Hartman]

On Tue, May 28, 2024 at 10:51:52AM +0200, Michal Hocko wrote:
> On Thu 23-05-24 14:14:57, Nikolay Borisov wrote:
> [...]
> > 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.
> 
> Let me add analysis by Joerg here:
> : This is not a security issue. The patch works around clangs compiler behavior
> : where it inserts absolute references to kernel addresses. This breaks kernel
> : boot because at the time this code runs the kernel still runs direct-mapped and
> : needs to rely on RIP-relative addressing only.
> : 
> : Any breakage there would be detected at early boot of the kernel by a fatal
> : crash, which can not be exploited. Also, our kernels are not compiled with
> : clang, so from that perspective this is also not an issue for us either.
> 
> So this is a functional fix for clang builds.

Thanks for the review, now rejected.

greg k-h