[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <2C6F783A-8337-48FE-86F3-5871BADF7BC2@amacapital.net>
Date: Mon, 19 Apr 2021 10:46:20 -0700
From: Andy Lutomirski <luto@...capital.net>
To: David Laight <David.Laight@...lab.com>
Cc: Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Kees Cook <keescook@...omium.org>,
Borislav Petkov <bp@...en8.de>,
Sami Tolvanen <samitolvanen@...gle.com>,
X86 ML <x86@...nel.org>, Josh Poimboeuf <jpoimboe@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Sedat Dilek <sedat.dilek@...il.com>,
linux-hardening@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>,
clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH 05/15] x86: Implement function_nocfi
> On Apr 19, 2021, at 8:26 AM, David Laight <David.Laight@...lab.com> wrote:
>
> From: Andy Lutomirski
>> Sent: 18 April 2021 01:12
> ..
>> Slightly more complicated:
>>
>> struct opaque_symbol;
>> extern struct opaque_symbol entry_SYSCALL_64;
>>
>> The opaque_symbol variant avoids any possible confusion over the weird
>> status of arrays in C, and it's hard to misuse, since struct
>> opaque_symbol is an incomplete type.
>
> Maybe:
>
> s/opaque_symbol/entry_SYSCALL_64/
>
Cute. OTOH, I’m not sure whether that has much benefit, and having a single type for all of this allows it to be declared just once. I suppose the magic could be wrapped in a macro, though.
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
Powered by blists - more mailing lists