On Sun, 2018-01-14 at 12:06 +0100, Jan Hubicka wrote:
>
> Yes, according to my understanding we want both pause and lefence by default
> (it is expensive anyway) + command line option to control which one to use?
>
> Probably thus the first patch should default to both.
In the kernel we're going
/invoke.texi: Document -mindirect-branch= option.
>>> > > +
>>> > > + /* Pause . */
>>> > > + fprintf (asm_out_file, "\tpause\n");
>>> >
>>> > OK, but please prepare incremental patches to choose between pause and
>>
On Sun, Jan 14, 2018 at 3:06 AM, Jan Hubicka wrote:
>> On 2018.01.14 at 11:46 +0100, Jan Hubicka wrote:
>> > > gcc/
>> > >
>> > > * config/i386/i386-opts.h (indirect_branch): New.
>> > > * config/i386/i386-protos.h (ix86_output_indirect_jmp): Likewise.
>> > > * config/i386/i386.c (ix86_using
> On 2018.01.14 at 11:46 +0100, Jan Hubicka wrote:
> > > gcc/
> > >
> > > * config/i386/i386-opts.h (indirect_branch): New.
> > > * config/i386/i386-protos.h (ix86_output_indirect_jmp): Likewise.
> > > * config/i386/i386.c (ix86_using_red_zone): Disallow red-zone
> > > with local indirect j
On 2018.01.14 at 11:46 +0100, Jan Hubicka wrote:
> > gcc/
> >
> > * config/i386/i386-opts.h (indirect_branch): New.
> > * config/i386/i386-protos.h (ix86_output_indirect_jmp): Likewise.
> > * config/i386/i386.c (ix86_using_red_zone): Disallow red-zone
> > with local indirect jump wh
> gcc/
>
> * config/i386/i386-opts.h (indirect_branch): New.
> * config/i386/i386-protos.h (ix86_output_indirect_jmp): Likewise.
> * config/i386/i386.c (ix86_using_red_zone): Disallow red-zone
> with local indirect jump when converting indirect call and jump.
> (ix86_
Add -mindirect-branch= option to convert indirect call and jump to call
and return thunks. The default is 'keep', which keeps indirect call and
jump unmodified. 'thunk' converts indirect call and jump to call and
return thunk. 'thunk-inline' converts indirect call and jump to inlined
call and re
On Sat, 2018-01-13 at 09:17 -0700, Jeff Law wrote:
> On 01/13/2018 02:03 AM, David Woodhouse wrote:
> > On Fri, 2018-01-12 at 10:57 -0700, Jeff Law wrote:
> > As things stand with retpoline in the kernel, userspace processes
> > aren't protected from each other. The attack mode is complex and
> >
On 01/13/2018 02:03 AM, David Woodhouse wrote:
> On Fri, 2018-01-12 at 10:57 -0700, Jeff Law wrote:
>>
>> WRT text relocs, yea that sucks, but if we're going to have user space
>> mitigations, then we're likely going to need those relocs so that the
>> thunks can be patched out. I'm actually hopin
On Fri, 2018-01-12 at 10:57 -0700, Jeff Law wrote:
>
> WRT text relocs, yea that sucks, but if we're going to have user space
> mitigations, then we're likely going to need those relocs so that the
> thunks can be patched out. I'm actually hoping we're not going to need
> user space mitigations f
On Fri, Jan 12, 2018 at 10:57:08AM -0700, Jeff Law wrote:
> On 01/11/2018 04:07 PM, Jakub Jelinek wrote:
> > On Thu, Jan 11, 2018 at 03:46:51PM -0700, Jeff Law wrote:
> >> Note I'm expecting Uros to chime in. So please do not consider this
> >> ack'd until you hear from Uros.
> >>
> >> At a high l
On 01/11/2018 04:07 PM, Jakub Jelinek wrote:
> On Thu, Jan 11, 2018 at 03:46:51PM -0700, Jeff Law wrote:
>> Note I'm expecting Uros to chime in. So please do not consider this
>> ack'd until you hear from Uros.
>>
>> At a high level is there really that much value in having thunks in the
>> object
On Thu, Jan 11, 2018 at 03:46:51PM -0700, Jeff Law wrote:
> Note I'm expecting Uros to chime in. So please do not consider this
> ack'd until you hear from Uros.
>
> At a high level is there really that much value in having thunks in the
> object file? Why not put the full set of thunks into lib
On Thu, Jan 11, 2018 at 2:46 PM, Jeff Law wrote:
> On 01/07/2018 03:59 PM, H.J. Lu wrote:
>> Add -mindirect-branch= option to convert indirect call and jump to call
>> and return thunks. The default is 'keep', which keeps indirect call and
>> jump unmodified. 'thunk' converts indirect call and j
On 01/07/2018 03:59 PM, H.J. Lu wrote:
> Add -mindirect-branch= option to convert indirect call and jump to call
> and return thunks. The default is 'keep', which keeps indirect call and
> jump unmodified. 'thunk' converts indirect call and jump to call and
> return thunk. 'thunk-inline' convert
On Tue, Jan 9, 2018 at 10:55 AM, Jeff Law wrote:
> On 01/08/2018 03:10 AM, Martin Liška wrote:
>> On 01/07/2018 11:59 PM, H.J. Lu wrote:
>>> +static void
>>> +output_indirect_thunk_function (bool need_bnd_p, int regno)
>>> +{
>>> + char name[32];
>>> + tree decl;
>>> +
>>> + /* Create __x86_ind
On 01/08/2018 03:10 AM, Martin Liška wrote:
> On 01/07/2018 11:59 PM, H.J. Lu wrote:
>> +static void
>> +output_indirect_thunk_function (bool need_bnd_p, int regno)
>> +{
>> + char name[32];
>> + tree decl;
>> +
>> + /* Create __x86_indirect_thunk/__x86_indirect_thunk_bnd. */
>> + indirect_thu
On Tue, 2018-01-09 at 00:02 +0100, Michael Matz wrote:
> Hi,
>
> On Mon, 8 Jan 2018, Woodhouse, David wrote:
>
> >
> > >
> > > >
> > > > That can be done via asm aliases or direct assembler use; the kernel
> > > > doesn't absolutely have to access them via C compatible symbol names.
> > > >
>
Hi,
On Mon, 8 Jan 2018, Woodhouse, David wrote:
> > > That can be done via asm aliases or direct assembler use; the kernel
> > > doesn't absolutely have to access them via C compatible symbol names.
> > >
> > Hi David,
> >
> > Can you comment on this?
>
> It ends up being a real pain for the C
On Mon, 2018-01-08 at 14:27 -0800, Andi Kleen wrote:
> On Mon, Jan 08, 2018 at 09:35:26PM +, David Woodhouse wrote:
> > On Mon, 2018-01-08 at 13:32 -0800, H.J. Lu wrote:
> > > On Mon, Jan 8, 2018 at 8:46 AM, Andi Kleen wrote:
> > > >
> > > > "H.J. Lu" writes:
> > > > >
> > > > > >
> > > >
On Mon, Jan 08, 2018 at 09:35:26PM +, David Woodhouse wrote:
> On Mon, 2018-01-08 at 13:32 -0800, H.J. Lu wrote:
> > On Mon, Jan 8, 2018 at 8:46 AM, Andi Kleen wrote:
> > >
> > > "H.J. Lu" writes:
> > > >
> > > > >
> > > > >
> > > > > Talking about PIC thunks, those have I believe . chara
On Mon, 2018-01-08 at 13:32 -0800, H.J. Lu wrote:
> On Mon, Jan 8, 2018 at 8:46 AM, Andi Kleen wrote:
> >
> > "H.J. Lu" writes:
> > >
> > > >
> > > >
> > > > Talking about PIC thunks, those have I believe . character in their
> > > > symbols,
> > > > so that they can't be confused with user
On Mon, Jan 8, 2018 at 8:46 AM, Andi Kleen wrote:
> "H.J. Lu" writes:
>>>
>>> Talking about PIC thunks, those have I believe . character in their symbols,
>>> so that they can't be confused with user functions. Any reason these
>>> retpoline thunks aren't?
>>>
>>
>> They used to have '.'. It wa
"H.J. Lu" writes:
>>
>> Talking about PIC thunks, those have I believe . character in their symbols,
>> so that they can't be confused with user functions. Any reason these
>> retpoline thunks aren't?
>>
>
> They used to have '.'. It was changed at the last minute since kernel needs
> to
> expo
On Mon, 2018-01-08 at 09:25 -0800, H.J. Lu wrote:
> On Mon, Jan 8, 2018 at 9:18 AM, Michael Matz wrote:
> >
> > Hi,
> >
> > On Mon, 8 Jan 2018, H.J. Lu wrote:
> >
> > >
> > > On Mon, Jan 8, 2018 at 4:00 AM, Jakub Jelinek wrote:
> > > >
> > > > On Mon, Jan 08, 2018 at 03:55:52AM -0800, H.J. L
On Mon, Jan 8, 2018 at 9:18 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 8 Jan 2018, H.J. Lu wrote:
>
>> On Mon, Jan 8, 2018 at 4:00 AM, Jakub Jelinek wrote:
>> > On Mon, Jan 08, 2018 at 03:55:52AM -0800, H.J. Lu wrote:
>> >> > I'm wondering whether thunk creation can be a good target-independent
>
Hi,
On Mon, 8 Jan 2018, H.J. Lu wrote:
> On Mon, Jan 8, 2018 at 4:00 AM, Jakub Jelinek wrote:
> > On Mon, Jan 08, 2018 at 03:55:52AM -0800, H.J. Lu wrote:
> >> > I'm wondering whether thunk creation can be a good target-independent
> >> > generalization? I guess
> >> > we can emit the function
On Mon, Jan 8, 2018 at 4:00 AM, Jakub Jelinek wrote:
> On Mon, Jan 08, 2018 at 03:55:52AM -0800, H.J. Lu wrote:
>> > I'm wondering whether thunk creation can be a good target-independent
>> > generalization? I guess
>> > we can emit the function declaration without direct writes to
>> > asm_out_
On Mon, Jan 08, 2018 at 03:55:52AM -0800, H.J. Lu wrote:
> > I'm wondering whether thunk creation can be a good target-independent
> > generalization? I guess
> > we can emit the function declaration without direct writes to asm_out_file?
> > And the emission
> > of function body can be potential
On Mon, Jan 8, 2018 at 2:10 AM, Martin Liška wrote:
> On 01/07/2018 11:59 PM, H.J. Lu wrote:
>> +static void
>> +output_indirect_thunk_function (bool need_bnd_p, int regno)
>> +{
>> + char name[32];
>> + tree decl;
>> +
>> + /* Create __x86_indirect_thunk/__x86_indirect_thunk_bnd. */
>> + ind
On 01/07/2018 11:59 PM, H.J. Lu wrote:
> +static void
> +output_indirect_thunk_function (bool need_bnd_p, int regno)
> +{
> + char name[32];
> + tree decl;
> +
> + /* Create __x86_indirect_thunk/__x86_indirect_thunk_bnd. */
> + indirect_thunk_name (name, regno, need_bnd_p);
> + decl = build_d
Add -mindirect-branch= option to convert indirect call and jump to call
and return thunks. The default is 'keep', which keeps indirect call and
jump unmodified. 'thunk' converts indirect call and jump to call and
return thunk. 'thunk-inline' converts indirect call and jump to inlined
call and re
32 matches
Mail list logo
