lkml.org 
[lkml]   [2018]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode
From
Date
Dmitry Safonov <0x7f454c46@gmail.com> wrote:

> 2018-02-16 7:11 GMT+00:00 Cyrill Gorcunov <gorcunov@gmail.com>:
>> On Thu, Feb 15, 2018 at 11:29:42PM +0000, Andy Lutomirski wrote:
>> ...
>>>>>> +bool pti_handle_segment_not_present(long error_code)
>>>>>> +{
>>>>>> + if (!static_cpu_has(X86_FEATURE_PTI))
>>>>>> + return false;
>>>>>> +
>>>>>> + if ((unsigned short)error_code != GDT_ENTRY_DEFAULT_USER_CS << 3)
>>>>>> + return false;
>>>>>> +
>>>>>> + pti_reenable();
>>>>>> + return true;
>>>>>> +}
>>>>>
>>>>> Please don't. You're trying to emulate the old behavior here, but
>>>>> you're emulating it wrong. In particular, you won't trap on LAR.
>>>>
>>>> Yes, I thought I’ll manage to address LAR, but failed. I thought you said
>>>> this is not a “show-stopper”. I’ll adapt your approach of using prctl, although
>>>> it really limits the benefit of this mechanism.
>>>
>>> It's possible we could get away with adding the prctl but making the
>>> default be that only the bitness that matches the program being run is
>>> allowed. After all, it's possible that CRIU is literally the only
>>> program that switches bitness using the GDT. (DOSEMU2 definitely does
>>> cross-bitness stuff, but it uses the LDT as far as I know.) And I've
>>> never been entirely sure that CRIU fully counts toward the Linux
>>> "don't break ABI" guarantee.
>>>
>>> Linus, how would you feel about, by default, preventing 64-bit
>>> programs from long-jumping to __USER32_CS and vice versa? I think it
>>> has some value as a hardening measure. I've certainly engaged in some
>>> exploit shenanigans myself that took advantage of the ability to long
>>> jump/ret to change bitness at will. This wouldn't affect users of
>>> modify_ldt() -- 64-bit programs could still create and use their own
>>> private 32-bit segments with modify_ldt(), and seccomp can (and
>>> should!) prevent that in sandboxed programs.
>>>
>>> In general, I prefer an approach where everything is explicit to an
>>> approach where we almost, but not quite, emulate the weird historical
>>> behavior.
>>>
>>> Pavel and Cyrill, how annoying would it be if CRIU had to do an extra
>>> arch_prctl() to enable its cross-bitness shenanigans when
>>> checkpointing and restoring a 32-bit program?
>>
>> I think this should not be a problem for criu (CC'ing Dima, who has
>> been working on compat mode support in criu). As far as I remember
>> we initiate restoring of 32 bit tasks in native 64 bit mode (well,
>> ia32e to be precise :) mode and then, once everything is ready,
>> we changing the mode by doing a return to __USER32_CS descriptor.
>> So this won't be painful to add additional prctl call here.
>
> Yeah, restoring will still be easy..
> But checkpointing will be harder if we can't switch to 64-bit mode.
> ATM we have one 64-bit parasite binary, which does all seizing job
> for both 64 and 32 bit binaries.
> So, if you can't switch back to 64-bit from 32-bit mode, we'll need
> to keep two parasites.

I can allow to switch back and forth by dynamically enabling/disabling PTI.
Andy, Dave, do you think it makes it a viable option? Should I respin
another version of the patch-set?

\
 
 \ /
  Last update: 2018-02-16 23:12    [W:0.045 / U:1.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site