Hi!
> > > > > I believe the kernel makes a questionable assumption on how clang
> > > > > uses registers (gs will not be used if stack protection is disabled).
> > > > > Both kernel and clang behaves unfortunate here.
> > > >
> > > > If the kernel is at fault here and this same thing happens with
On Tue, Sep 15, 2020 at 12:51:47PM -0700, Nick Desaulniers wrote:
> It would be much nicer if we had the flexibility to disable stack
> protectors per function, rather than per translation unit. I'm going
> to encourage you to encourage your favorite compile vendor ("write to
> your senator") to s
On Tue, Sep 15, 2020 at 02:49:40PM -0700, Nick Desaulniers wrote:
> 1. they don't pay me enough for that.
They probably should - you're doing it anyway and it's not like they
have a shortage of cash. :-P
> 2. even if they did, I wouldn't want that responsibility
Too late, my friend. :-)
> 3. I'
On Tue 2020-09-15 11:36:13, Roman Kiryanov wrote:
> On Tue, Sep 15, 2020 at 11:27 AM Borislav Petkov wrote:
> > > I believe the kernel makes a questionable assumption on how clang
> > > uses registers (gs will not be used if stack protection is disabled).
> > > Both kernel and clang behaves unfort
Hi!
> > Because I'm willing to
> > bet a lot of cash that no one runs bleeding egde 5.9-rcX in production
> > over there right now :-)
>
> I guess you're paying for beers then. "Android Common Kernels" run
> mainline. (They're a bit esoteric in terms of "production" but
> cuttlefish virtual dev
On Tue, Sep 15, 2020 at 10:46 AM Borislav Petkov wrote:
Hi Borislav, thank you for a quick response.
> Ok, google guys, pls make sure you Cc LKML too as this is where *all*
> patches and discussions are archived. Adding it now to Cc.
Thank you, I did not know this.
> Ok, so why is the kernel s
On Tue, Sep 15, 2020 at 10:26:58AM -0700, r...@google.com wrote:
> From: Haitao Shan
>
> This is a workaround which fixes triple fault
> in __restore_processor_state on clang when
> built with LTO.
>
> When load_TR_desc and load_mm_ldt are inlined into
> fix_processor_context due to LTO, they ca
On Tue, Sep 15, 2020 at 11:00:30AM -0700, Nick Desaulniers wrote:
> This is exactly the same code from __restore_processor_state.
No, this patch is adding
#ifdef __clang__
and I don't like the sprinkling around of those compiler-specific
workarounds which we have to carry forward forever or at
On Tue, Sep 15, 2020 at 10:57:16AM -0700, Roman Kiryanov wrote:
> I believe the kernel makes a questionable assumption on how clang
> uses registers (gs will not be used if stack protection is disabled).
> Both kernel and clang behaves unfortunate here.
If the kernel is at fault here and this same
On Tue, Sep 15, 2020 at 11:27 AM Borislav Petkov wrote:
> > I believe the kernel makes a questionable assumption on how clang
> > uses registers (gs will not be used if stack protection is disabled).
> > Both kernel and clang behaves unfortunate here.
>
> If the kernel is at fault here and this sa
On Tue, Sep 15, 2020 at 10:46 AM Borislav Petkov wrote:
>
> On Tue, Sep 15, 2020 at 10:26:58AM -0700, r...@google.com wrote:
> > From: Haitao Shan
> >
> > This is a workaround which fixes triple fault
> > in __restore_processor_state on clang when
> > built with LTO.
> >
> > When load_TR_desc and
On Tue, Sep 15, 2020 at 11:36:13AM -0700, Roman Kiryanov wrote:
> This is fair. Unfortunately I am not an x86 asm expert. I expect the proper
> fix should land into arch/x86/kernel/acpi/wakeup_64.S to init %gs
> (maybe some more registers) before "jmp restore_processor_state".
... because "LLVM ap
On Tue, Sep 15, 2020 at 11:52 AM Borislav Petkov wrote:
>
> On Tue, Sep 15, 2020 at 11:36:13AM -0700, Roman Kiryanov wrote:
> > This is fair. Unfortunately I am not an x86 asm expert. I expect the proper
> > fix should land into arch/x86/kernel/acpi/wakeup_64.S to init %gs
> > (maybe some more reg
On Tue, Sep 15, 2020 at 11:25 AM Borislav Petkov wrote:
>
> On Tue, Sep 15, 2020 at 11:00:30AM -0700, Nick Desaulniers wrote:
> > This is exactly the same code from __restore_processor_state.
>
> No, this patch is adding
>
> #ifdef __clang__
>
> and I don't like the sprinkling around of those comp
On Tue, Sep 15, 2020 at 11:00:30AM -0700, Nick Desaulniers wrote:
> On Tue, Sep 15, 2020 at 10:46 AM Borislav Petkov wrote:
> >
> > On Tue, Sep 15, 2020 at 10:26:58AM -0700, r...@google.com wrote:
> > > From: Haitao Shan
> > >
> > > This is a workaround which fixes triple fault
> > > in __restore
On Tue, Sep 15, 2020 at 1:20 PM Borislav Petkov wrote:
>
> On Tue, Sep 15, 2020 at 12:51:47PM -0700, Nick Desaulniers wrote:
> > I agree; I also would not have sent the patch though.
>
> Maybe google folks should run stuff by you before sending it up... :-)
Ha!
1. they don't pay me enough for th
On Tue, Sep 15, 2020 at 12:51:47PM -0700, Nick Desaulniers wrote:
> I agree; I also would not have sent the patch though.
Maybe google folks should run stuff by you before sending it up... :-)
> Until LTO has landed upstream, this is definitely somewhat self
> inflicted. This was only debugged la
On Fri, Sep 18, 2020 at 3:25 PM Pavel Machek wrote:
>
> On Tue 2020-09-15 11:36:13, Roman Kiryanov wrote:
> > On Tue, Sep 15, 2020 at 11:27 AM Borislav Petkov wrote:
> > > > I believe the kernel makes a questionable assumption on how clang
> > > > uses registers (gs will not be used if stack prot
18 matches
Mail list logo
