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-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 12 Dec 2022 08:37:09 -0800
From:   Sathyanarayanan Kuppuswamy 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>
To:     Dave Hansen <dave.hansen@...el.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Elena Reshetova <elena.reshetova@...el.com>, x86@...nel.org,
        linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] x86/tdx: Use ReportFatalError to report missing
 SEPT_VE_DISABLE



On 12/12/22 8:10 AM, Dave Hansen wrote:
> On 12/9/22 12:51, Sathyanarayanan Kuppuswamy wrote:
>>>>> +	while (1) {
>>>>> +		__tdx_hypercall(&args, 0);
>>>>> +	}
>>>> Instead of an infinite loop, I'm wondering if the guest should panic after
>>>> retrying for few times.
>>> Hm. What difference would it make?
>> IIUC, the goal of this patch is to report the fatal error to VMM and panic.
>> But, if VMM does not terminate the guest as we expect, rather than trying 
>> continuously, isn't it better to panic ourselves? That way the behavior
>> will be similar to what we have currently.
> 
> What does "panic ourselves" mean exactly?  What is the current behavior
> which that would match?

I meant directly calling panic(). Before this patch, if the SEPT VE DISABLE
attribute was not set, we would call panic(). In this patch, we try to report
the error to VMM and wait for it to terminate the guest in the same case.
But after reporting the error, if VMM does not terminate the guest as expected,
I thought instead of retrying continuously, we can call panic() directly after
some retries. 


> 

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

Powered by blists - more mailing lists