linux-kernel - Re: [PATCH v2 00/20] Introduce common headers

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]

Message-ID: <b18c7ce1-0948-a9e2-2d7e-d019669a71e1@arm.com>
Date:   Mon, 9 Mar 2020 11:07:08 +0000
From:   Vincenzo Frascino <vincenzo.frascino@....com>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     linux-arch@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org,
        clang-built-linux@...glegroups.com, x86@...nel.org,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Arnd Bergmann <arnd@...db.de>,
        Russell King <linux@...linux.org.uk>,
        Paul Burton <paul.burton@...s.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Stephen Boyd <sboyd@...nel.org>,
        Mark Salyzyn <salyzyn@...roid.com>,
        Kees Cook <keescook@...omium.org>,
        Peter Collingbourne <pcc@...gle.com>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Andrei Vagin <avagin@...nvz.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH v2 00/20] Introduce common headers

Hi Andy,

On 3/6/20 4:04 PM, Andy Lutomirski wrote:

[...]

>>
>> To solve the problem, I decided to use the approach below:
>>  * Extract from include/linux/ the vDSO required kernel interface
>>    and place it in include/common/
> 
> I really like the approach, but I’m wondering if “common” is the right name. This directory is headers that aren’t stable ABI like uapi but are shared between the kernel and the vDSO. Regular user code should *not* include these, right?
> 
> Would “vdso” or perhaps “private-abi” be clearer?
> 

Thanks! These headers are definitely not "uapi" like and they are meant to
evolve in future like any other kernel header. We have just to make sure that
the evolution does not break what we are trying to achieve with this series.

I have to admit that I spent quite some time in choosing the name and I am not
completely satisfied with "common" either. The reason why I ended up with this
is that the headers are common in between the kernel and the vdso (userspace)
but I agree that it does not make completely self explanatory.

Using "vdso" would mean according to me that those are vdso only headers,
probably "private-abi" is the best choice here. If there is enough consensus, I
am happy to rework my patches accordingly. What do you think?

>>  * Make sure that where meaningful the kernel includes "common"
>>  * Limit the vDSO library to include headers coming only from UAPI
>>    and "common" (with 2 exceptions compiler.h for barriers and
>>    param.h for HZ).
>>  * Adapt all the architectures that support the unified vDSO library
>>    to use "common" headers.
> 
[...]

-- 
Regards,
Vincenzo