[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8887d182-a3e3-f62a-8b8f-36db1da75b19@linux.intel.com>
Date: Mon, 31 Oct 2022 12:27:19 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>,
Dave Hansen <dave.hansen@...el.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
luto@...nel.org, peterz@...radead.org,
sathyanarayanan.kuppuswamy@...ux.intel.com,
dan.j.williams@...el.com, david@...hat.com, hpa@...or.com,
seanjc@...gle.com, thomas.lendacky@....com,
elena.reshetova@...el.com, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] x86/tdx: Extract GET_INFO call from get_cc_mask()
sted-by's would be appreciated.
> One thing that I must bring up is that it seems that there's no way to get
> the panic message to user. I tried to convinced myself that it is qemu
> misconfiguration on my part or some race, but no: it is just too early for
> earlyprintk.
>
> We only get earlyprintk working after parse_early_options() which happens
> well after tdx_early_init().
>
> Moving panic() after earlyprintk working is not good idea as it exposes
> kernel more: by the time we already have full #VE handler.
It should be fine to move since there is no user land at this point (the
attack requires user land)
>
> We can move it earlier into decompresser which has different earlyprintk
> implementation. Not sure if it worth this. What do you think?
That would make uncompressed kernels unsafe.
-Andi
Powered by blists - more mailing lists