linux-kernel - [Regression v5.19-rc1] crash kexec fails to boot the 2nd kernel (Re: [PATCH v12 38/46] x86/sev: Add SEV-SNP feature detection/setup)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <TYCPR01MB694815CD815E98945F63C99183B49@TYCPR01MB6948.jpnprd01.prod.outlook.com>
Date:   Fri, 24 Jun 2022 00:44:52 +0000
From:   NOMURA JUNICHI(野村　淳一) 
        <junichi.nomura@....com>
To:     "brijesh.singh@....com" <brijesh.singh@....com>
CC:     LKML <linux-kernel@...r.kernel.org>,
        "michael.roth@....com" <michael.roth@....com>,
        "x86@...nel.org" <x86@...nel.org>, "bp@...e.de" <bp@...e.de>
Subject: [Regression v5.19-rc1] crash kexec fails to boot the 2nd kernel (Re:
 [PATCH v12 38/46] x86/sev: Add SEV-SNP feature detection/setup)

I found crash kexec fails to boot the 2nd kernel since v5.19-rc1 and
git bisect points to this as a bad commit:

  commit b190a043c49af4587f5e157053f909192820522a
  Author: Michael Roth <michael.roth@....com>
  Date:   Thu Feb 24 10:56:18 2022 -0600

    x86/sev: Add SEV-SNP feature detection/setup

    Initial/preliminary detection of SEV-SNP is done via the Confidential
    Computing blob. Check for it prior to the normal SEV/SME feature
    initialization, and add some sanity checks to confirm it agrees with
    SEV-SNP CPUID/MSR bits.

The problem seems to occur when find_cc_blob_setup_data() walks setup_data
chain.  If the code is modified to do nothing in find_cc_blob_setup_data(),
the 2nd kernel boots fine.

On my system, the chain of setup_data looks like following on regular boot:
  setup_data: type=0x3 addr=0x9e9e5018 next=0x9e9dc018
  setup_data: type=0x3 addr=0x9e9dc018 next=0x9e9d2018
  setup_data: type=0x3 addr=0x9e9d2018 next=0x8a27b018
  setup_data: type=0x3 addr=0x8a27b018 next=0x8a218018
  setup_data: type=0x3 addr=0x8a218018 next=0x9e9a0018
  setup_data: type=0x3 addr=0x9e9a0018 next=0x8a1e6018
  setup_data: type=0x3 addr=0x8a1e6018 next=0x8a1b4018
  setup_data: type=0x3 addr=0x8a1b4018 next=0x8a182018
  setup_data: type=0x3 addr=0x8a182018 next=0x8a056018
  setup_data: type=0x3 addr=0x8a056018 next=0x8a020018
  setup_data: type=0x3 addr=0x8a020018 next=0x89fea018
  setup_data: type=0x3 addr=0x89fea018 next=0x0

OTOH, it looks like following on crash kexec boot:
  setup_data: type=0x4 addr=0x2e000000 next=0x0

Other places that parses setup_data uses early_memremap() before
accessing the data (e.g. parse_setup_data()).  I wonder if the lack of
remapping causes the problem but find_cc_blob is too early in the
boot process for early_memremap to work.

-- 
Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.


Download attachment "smime.p7s" of type "application/pkcs7-signature" (5766 bytes)