linux-kernel - Re: [PATCH 1/2] x86, mpx: explicitly disable 32-bit MPX support on 64-bit kernels

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrWuG6kDeGAqMmw7EuSrLBJvU8xWbzMn+A0kjB5eMfEBuA@mail.gmail.com>
Date:	Tue, 23 Dec 2014 10:48:50 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Dave Hansen <dave@...1.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>, X86 ML <x86@...nel.org>,
	Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH 1/2] x86, mpx: explicitly disable 32-bit MPX support on
 64-bit kernels

On Tue, Dec 23, 2014 at 1:19 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Andy Lutomirski <luto@...capital.net> wrote:
>
>> On Mon, Dec 22, 2014 at 12:21 PM, Dave Hansen <dave@...1.net> wrote:
>> > On 12/22/2014 12:17 PM, Andy Lutomirski wrote:
>> >>> >         /*
>> >>> > +        * 32-bit binaries on 64-bit kernels are currently
>> >>> > +        * unsupported.
>> >>> > +        */
>> >>> > +       if (IS_ENABLED(CONFIG_X86_64) && test_thread_flag(TIF_IA32))
>> >>> > +               return MPX_INVALID_BOUNDS_DIR;
>> >> Should this check mm->ia32_compat instead?
>> >
>> > set_personality_64bit/ia32() seem to make that and TIF_IA32 awfully
>> > equivalent.  Is there a specific reason for wanting it done this way?
>>
>> My general desire to remove various bogus TIF_IA32 references.
>> [...]
>
> So we generally want to use mm->context.ia32_compat instead of
> TIF_IA32, because in the end TIF_IA32 will go away altogether?
>
> Or do you just want to audit all TIF_IA32 places (because most of
> them are wrong), and using mm->context.ia32_compat where it's
> justified and eliminating TIF_IA32 use is a nice way to document
> that ongoing audit without breaking stuff and such?

TBH, I haven't gotten that far.  But of the uses I've looked at, most
seem to want TS_COMPAT instead (is_ia32_task, which is IMO terribly
named), some are so buggier than just using a strange flag, and I
suspect that the rest would make more sense using
mm->context.ia32_compat.

I was planning on sending some patches to incrementally improve the
situation and then seeing where we end up.

>
>> [...]  But this is only temporary, so I don't really care.
>
> New code that touches this area should better use new principles,
> so I have no problem with requiring this, as long as it's well
> explained and logical and desirable to everyone.
>

Given that this patch is a fix for 3.19, the code looks correct, and
the check will go away in 3.20, I see no reason to worry about this
particular patch.

--Andy

> Thanks,
>
>         Ingo



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/