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
On Sun, Jan 14, 2018 at 4:52 AM, H.J. Lu wrote:
> 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_j
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_
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
30 matches
Mail list logo
