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  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:   Thu, 14 Oct 2021 01:19:23 +0200
From:   Thomas Gleixner <>
To:     Josh Poimboeuf <>,
        Borislav Petkov <>
Cc:     Kuppuswamy Sathyanarayanan 
        Ingo Molnar <>,,
        Paolo Bonzini <>,
        David Hildenbrand <>,
        Andrea Arcangeli <>,
        Juergen Gross <>, Deep Shah <>,
        VMware Inc <>,
        Vitaly Kuznetsov <>,
        Wanpeng Li <>,
        Jim Mattson <>,
        Joerg Roedel <>, Peter H Anvin <>,
        Dave Hansen <>,
        Tony Luck <>,
        Dan Williams <>,
        Andi Kleen <>,
        Kirill Shutemov <>,
        Sean Christopherson <>,
        Kuppuswamy Sathyanarayanan <>,
Subject: Re: [PATCH v10 03/11] x86/cpufeatures: Add TDX Guest CPU feature

On Wed, Oct 13 2021 at 12:42, Josh Poimboeuf wrote:
> On Wed, Oct 13, 2021 at 10:18:18AM +0200, Borislav Petkov wrote:
>> > +#include <asm/tdx.h>
>> > +
>> > +bool is_tdx_guest(void)
>> > +{
>> > +	static int tdx_guest = -1;
>> Put that one at the top of the file because such static variables do not
>> belong among the automatic function vars.
> I disagree, this prevents confusion and misuse by making it clear that
> the scope of the static variable is limited to this function.

I kinda agree under the assumption that a static variable is only used
in a particular context and there is a reasonable requirement to do so.

The above does not qualify as I pointed out in my other reply. Just
because it looks like strict local usage at the first glance does not
make an argument, really.

I'm amazed that it's so hard to see that this


pattern is broken to begin with.

So why are you arguing about the placement of this variable in the first
place instead of actually looking at the code, wondering about the
obscenity and then asking about the call ordering?

In case that I might miss something important here due to my lack of CS
education, please let me know.



Powered by blists - more mailing lists