linux-kernel - Re: [PATCH v3 2/3] Fix undefined operation fault that can hang a cpu on crash or panic

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1593986823.58943274@apps.rackspace.com>
Date:   Sun, 5 Jul 2020 18:07:03 -0400 (EDT)
From:   "David P. Reed" <dpreed@...pplum.com>
To:     "Andy Lutomirski" <luto@...nel.org>
Cc:     "Andy Lutomirski" <luto@...nel.org>,
        "Sean Christopherson" <sean.j.christopherson@...el.com>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "Ingo Molnar" <mingo@...hat.com>, "Borislav Petkov" <bp@...en8.de>,
        "X86 ML" <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
        "Allison Randal" <allison@...utok.net>,
        "Enrico Weigelt" <info@...ux.net>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        "Kate Stewart" <kstewart@...uxfoundation.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        "Randy Dunlap" <rdunlap@...radead.org>,
        "Martin Molnar" <martin.molnar.programming@...il.com>,
        "Alexandre Chartre" <alexandre.chartre@...cle.com>,
        "Jann Horn" <jannh@...gle.com>,
        "Dave Hansen" <dave.hansen@...ux.intel.com>,
        "LKML" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/3] Fix undefined operation fault that can hang a cpu on crash or panic



On Sunday, July 5, 2020 4:55pm, "Andy Lutomirski" <luto@...nel.org> said:

> On Sun, Jul 5, 2020 at 12:52 PM David P. Reed <dpreed@...pplum.com> wrote:
>>
>> Thanks, will handle these. 2 questions below.
>>
>> On Sunday, July 5, 2020 2:22pm, "Andy Lutomirski" <luto@...nel.org> said:
>>
>> > On Sat, Jul 4, 2020 at 1:38 PM David P. Reed <dpreed@...pplum.com> wrote:
>> >>
>> >> Fix: Mask undefined operation fault during emergency VMXOFF that must be
>> >> attempted to force cpu exit from VMX root operation.
>> >> Explanation: When a cpu may be in VMX root operation (only possible when
>> >> CR4.VMXE is set), crash or panic reboot tries to exit VMX root operation
>> >> using VMXOFF. This is necessary, because any INIT will be masked while cpu
>> >> is in VMX root operation, but that state cannot be reliably
>> >> discerned by the state of the cpu.
>> >> VMXOFF faults if the cpu is not actually in VMX root operation, signalling
>> >> undefined operation.
>> >> Discovered while debugging an out-of-tree x-visor with a race. Can happen
>> >> due to certain kinds of bugs in KVM.
>> >
>> > Can you re-wrap lines to 68 characters?  Also, the Fix: and
>>
>> I used 'scripts/checkpatch.pl' and it had me wrap to 75 chars:
>> "WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per
>> line)"
>>
>> Should I submit a fix to checkpatch.pl to say 68?
> 
> 75 is probably fine too, but something is odd about your wrapping.
> You have long lines mostly alternating with short lines.  It's as if
> you wrote 120-ish character lines and then wrapped to 75 without
> reflowing.
My emacs settings tend to wrap at about 85 depending on file type (big screens). I did the shortening manually, aimed at breaking at meaningful points, not worrying too much about
line-length uniformity.

> 
>>
>> > Explanation: is probably unnecessary.  You could say:
>> >
>> > Ignore a potential #UD failut during emergency VMXOFF ...
>> >
>> > When a cpu may be in VMX ...
>> >
>> >>
>> >> Fixes: 208067 <https://bugzilla.kernel.org/show_bug.cgi?id=208067>
>> >> Reported-by: David P. Reed <dpreed@...pplum.com>
>> >
>> > It's not really necessary to say that you, the author, reported the
>> > problem, but I guess it's harmless.
>> >
>> >> Suggested-by: Thomas Gleixner <tglx@...utronix.de>
>> >> Suggested-by: Sean Christopherson <sean.j.christopherson@...el.com>
>> >> Suggested-by: Andy Lutomirski <luto@...nel.org>
>> >> Signed-off-by: David P. Reed <dpreed@...pplum.com>
>> >> ---
>> >>  arch/x86/include/asm/virtext.h | 20 ++++++++++++++------
>> >>  1 file changed, 14 insertions(+), 6 deletions(-)
>> >>
>> >> diff --git a/arch/x86/include/asm/virtext.h b/arch/x86/include/asm/virtext.h
>> >> index 0ede8d04535a..0e0900eacb9c 100644
>> >> --- a/arch/x86/include/asm/virtext.h
>> >> +++ b/arch/x86/include/asm/virtext.h
>> >> @@ -30,11 +30,11 @@ static inline int cpu_has_vmx(void)
>> >>  }
>> >>
>> >>
>> >> -/* Disable VMX on the current CPU
>> >> +/* Exit VMX root mode and isable VMX on the current CPU.
>> >
>> > s/isable/disable/
>> >
>> >
>> >>  /* Disable VMX if it is supported and enabled on the current CPU
>> >> --
>> >> 2.26.2
>> >>
>> >
>> > Other than that:
>> >
>> > Reviewed-by: Andy Lutomirski <luto@...nel.org>
>>
>> As a newbie, I have a process question - should I resend the patch with the
>> 'Reviewed-by' line, as well as correcting the other wording? Thanks!
> 
> Probably.  Sometimes a maintainer will apply the patch and make these
> types of cosmetic changes, but it's easier if you resubmit.  That
> being said, for non-urgent patches, it's usually considered polite to
> wait a day or two to give other people a chance to comment.

I'm not sure which maintainer will move the patches along. I am waiting for additional input, but will resubmit in a day or two.

> 
> --Andy
>