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:   Tue, 06 Jun 2023 16:08:34 -0700
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        "Li, Xin3" <xin3.li@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>
CC:     "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "jiangshanlai@...il.com" <jiangshanlai@...il.com>,
        "Kang, Shan" <shan.kang@...el.com>
Subject: RE: [PATCH v8 30/33] x86/fred: allow dynamic stack frame size

On June 6, 2023 6:27:25 AM PDT, Thomas Gleixner <tglx@...utronix.de> wrote:
>On Tue, Jun 06 2023 at 06:18, Xin3 Li wrote:
>>> > A FRED stack frame could contain different amount of information for
>>> > This approach also works for IDT, thus we unify the code.
>>> 
>>> And thereby remove the useful comment and replace it with an undocumented
>>> macro mess.
>>> 
>>> I'm simply refusing to review this. It's not my job to understand this
>>> undocumented hackery.
>>> 
>>
>> I believe it's a nice idea to allow dynamic stack frame size, at least for
>> FRED.
>
>Believe belongs in the realm of religion. What we need here are proper
>facts, explanations and justifications. Nice ideas are not helpful when
>they are not having a value.
>
>> It's totally my bad that I didn't make it meet the minimum standards,
>> I will rewrite the commit message and add better comments.
>>
>> After a second thought, I probably should only apply the change to FRED for
>> 2 reasons, the change seems problematic with ESPFIX (which FRED
>> doesn't need),
>
>Indeed. Making this FRED only is going to need even more justification.
>
>> and such corner cases are hard to test (self-tests needed?)
>
>There is a test. It's not that hard to find:
>
># git grep -li ESPFIX tools/testing/selftests/
>tools/testing/selftests/x86/sigreturn.c
>
>Thanks,
>
>        tglx

For what it is worth, I am working on a FRED forward compatibly document at the moment.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ