linux-kernel - Re: [PATCH 2/6] arch: x86: Wrap TIF

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: <878sf3j5cl.fsf@collabora.com>
Date:   Wed, 29 Jul 2020 00:46:34 -0400
From:   Gabriel Krisman Bertazi <krisman@...labora.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Christoph Hellwig <hch@....de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Kees Cook <keescook@...omium.org>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, kernel@...labora.com
Subject: Re: [PATCH 2/6] arch: x86: Wrap TIF_IA32 checks

Andy Lutomirski <luto@...nel.org> writes:

> On Tue, Jul 28, 2020 at 1:22 PM Gabriel Krisman Bertazi
> <krisman@...labora.com> wrote:
>>
>> In preparation to remove TIF_IA32, add wrapper that check the process
>> has IA32 ABI without using the flag directly.
>
> Thank you for doing this, but let's please do it right.  There is,
> fundamentally, no such thing as a "process with IA32 ABI".

Hi Andy,

Thanks a lot for your review.

As you can see, I'm learning my way here. Can you clarify "there is no
such a thing as a 'process with IA32 ABI'"?  I'm not sure if I confused
the terminology or if (more worrisome for me) I got the concepts wrong.

My understanding is that TIF_IA32 marks a thread that is running under
the 32-bit compat mode, which would be running a 32-bit process (as in
compiled with -m32, for instance), while TIF_X32 marks a process running
under the X32 ABI.  Each process would have only one of these
"personalities". This is what I meant by a process with IA32 ABI (which
is wrong in any case).  Is there more to it, or is the problem the
terminology I used?

I don't have any comments on the other things you mentioned, except that
I need to go through them and better understand your suggestions.  Would
you prefer me to rework this patch series with what you suggested or is
this something you want to take over and do yourself?  Both ways are
fine by me.

Thanks,

-- 
Gabriel Krisman Bertazi