Re: [PATCH v10 01/26] Documentation/x86: Add CET description

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/12/20 4:20 PM, Yu-cheng Yu wrote:
> On Wed, 2020-04-29 at 16:02 -0700, Yu-cheng Yu wrote:
>> On Wed, 2020-04-29 at 15:53 -0700, Dave Hansen wrote:
>>> On 4/29/20 3:07 PM, Yu-cheng Yu wrote:
>>>> +Note:
>>>> +  There is no CET-enabling arch_prctl function.  By design, CET is enabled
>>>> +  automatically if the binary and the system can support it.
>>>
>>> I think Andy and I danced around this last time.  Let me try to say it
>>> more explicitly.
>>>
>>> I want CET kernel enabling to able to be disconnected from the on-disk
>>> binary.  I want a binary compiled with CET to be able to disable it, and
>>> I want a binary not compiled with CET to be able to enable it.  I want
>>> different threads in a process to be able to each have different CET status.
>>
>> The kernel patches we have now can be modified to support this model.  If after
>> discussion this is favorable, I will modify code accordingly.
> 
> To turn on/off and to lock CET are application-level decisions.  The kernel does
> not prevent any of those.  Should there be a need to provide an arch_prctl() to
> turn on CET, it can be added without any conflict to this series.

I spelled out what I wanted pretty clearly.  On your next post, could
you please directly address each of the things I asked for?  Please
directly answer the following questions in your next post with respect
to the code you post:

Can a binary compiled with CET run without CET?
Can a binary compiled without CET run CET-enabled code?
Can different threads in a process have different CET enabling state?

>>> Which JITs was this tested with?  I think as a bare minimum we need to
>>> know that this design can accommodate _a_ modern JIT.  It would be
>>> horrible if the browser javascript engines couldn't use this design, for
>>> instance.
>>
>> JIT work is still in progress.  When that is available I will test it.
> 
> I found CET has been enabled in LLVM JIT, Mesa JIT as well as sljit which is
> used by jit.  So the current model works with JIT.

Great!  I'm glad the model works.  That's not what I asked, though.

Does this *code* work?  Could you please indicate which JITs have been
enabled to use the code in this series?  How much of the new ABI is in use?

Where are the selftests/ for this new ABI?  Were you planning on
submitting any with this series?





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux