linux-kernel - Re: [PATCH v18 24/25] x86/cet/shstk: Add arch

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: <179fe87e-8fd1-9a26-e4f6-a508b45a54d4@intel.com>
Date:   Fri, 29 Jan 2021 11:15:12 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Yu, Yu-cheng" <yu-cheng.yu@...el.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-mm@...ck.org,
        linux-arch@...r.kernel.org, linux-api@...r.kernel.org,
        Arnd Bergmann <arnd@...db.de>,
        Andy Lutomirski <luto@...nel.org>,
        Balbir Singh <bsingharora@...il.com>,
        Borislav Petkov <bp@...en8.de>,
        Cyrill Gorcunov <gorcunov@...il.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Eugene Syromiatnikov <esyr@...hat.com>,
        Florian Weimer <fweimer@...hat.com>,
        "H.J. Lu" <hjl.tools@...il.com>, Jann Horn <jannh@...gle.com>,
        Jonathan Corbet <corbet@....net>,
        Kees Cook <keescook@...omium.org>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Nadav Amit <nadav.amit@...il.com>,
        Oleg Nesterov <oleg@...hat.com>, Pavel Machek <pavel@....cz>,
        Peter Zijlstra <peterz@...radead.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        Vedvyas Shanbhogue <vedvyas.shanbhogue@...el.com>,
        Dave Martin <Dave.Martin@....com>,
        Weijiang Yang <weijiang.yang@...el.com>,
        Pengfei Xu <pengfei.xu@...el.com>
Subject: Re: [PATCH v18 24/25] x86/cet/shstk: Add arch_prctl functions for
 shadow stack

On 1/29/21 10:56 AM, Yu, Yu-cheng wrote:
> On 1/29/2021 9:07 AM, Dave Hansen wrote:
>> On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
>>> +    u64 buf[3] = {0, 0, 0};

Doesn't the compiler zero these if you initialize it to anything?  In
other words, doesn't this work?

	u64 buf[3] = {};

>>> +    if (cet->shstk_size) {
>>> +        buf[0] |= GNU_PROPERTY_X86_FEATURE_1_SHSTK;
>>> +        buf[1] = (u64)cet->shstk_base;
>>> +        buf[2] = (u64)cet->shstk_size;
>>
>> What's the casting for?
> 
> cet->shstk_base and cet->shstk_size are both 'unsigned long', not u64,
> so the cast.

Sure, but we don't put explicit casts at every implicit type conversion
in the kernel.  What function does this casting serve?

>>> +    cet = &current->thread.cet;
>>> +
>>> +    if (option == ARCH_X86_CET_STATUS)
>>> +        return copy_status_to_user(cet, arg2);
>>
>> What's the point of doing copy_status_to_user() if the processor doesn't
>> support CET?  In other words, shouldn't this be below the CPU feature
>> check?
> 
> The thought was to tell the difference between the kernel itself does
> not support CET and the system does not have CET.  And, if the kernel
> supports it, show CET status of the thread.

Why would that matter to userspace?

If they want to know if the processor has CET support there are existing
ways to do it.  I don't think this should be part of the ABI.