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
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
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.
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
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
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
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
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