> From: Andy Lutomirski
>
> On Tue, Jan 12, 2021 at 9:02 AM Metzger, Markus T
> wrote:
> >
> > > [ 26.990644] getreg: gs_base = 0xf7f8e000
> > > [ 26.991694] getreg: GS=0x63, GSBASE=0xf7f8e000
> > > [ 26.993117] PTRACE_SETREGS
> > > [ 26.993813] putreg: change gsbase from 0xf7f8e000 to 0
On Tue, Jan 12, 2021 at 9:02 AM Metzger, Markus T
wrote:
>
> > [ 26.990644] getreg: gs_base = 0xf7f8e000
> > [ 26.991694] getreg: GS=0x63, GSBASE=0xf7f8e000
> > [ 26.993117] PTRACE_SETREGS
> > [ 26.993813] putreg: change gsbase from 0xf7f8e000 to 0x0
> > [ 26.995134] putreg: write GS=0x6
> [ 26.990644] getreg: gs_base = 0xf7f8e000
> [ 26.991694] getreg: GS=0x63, GSBASE=0xf7f8e000
> [ 26.993117] PTRACE_SETREGS
> [ 26.993813] putreg: change gsbase from 0xf7f8e000 to 0x0
> [ 26.995134] putreg: write GS=0x63; old GSBASE=0x0
> [ 26.996235] PTRACE_SETREGS done
>
> That's gdb
On Tue, Jan 12, 2021 at 3:39 AM Metzger, Markus T
wrote:
>
> > The GDB behavior looks to be different between the two cases -- with vs
> > without gdb server, when I checked the GS/GSBASE values on the ptrace front.
>
> 64-bit GDB doesn't support FSGSBASE for 32-bit inferiors and it looks like
>
> The GDB behavior looks to be different between the two cases -- with vs
> without gdb server, when I checked the GS/GSBASE values on the ptrace front.
64-bit GDB doesn't support FSGSBASE for 32-bit inferiors and it looks like
gdbserver
might not support FSGSBASE, at all.
I had added support fo
On 1/12/21 4:31 AM, Andy Lutomirski wrote:
> On Mon, Jan 11, 2021 at 3:52 PM Tom de Vries wrote:
>>
>> On 1/12/21 12:40 AM, Andy Lutomirski wrote:
>>> On Mon, Jan 11, 2021 at 1:06 PM Andy Lutomirski wrote:
> On Jan 11, 2021, at 12:00 PM, Borislav Petkov wrote:
>
>
> On Jan 11, 2021, at 13:06, Andy Lutomirski wrote:
>
>> On Jan 11, 2021, at 12:00 PM, Borislav Petkov wrote:
>>
>> Or do you mean I should add "unsafe_fsgsbase" to grub cmdline and bisect
>> with fsgsbase enabled in all test kernels?
>
> Yes. But I can also look myself in a bit.
I was able
On Mon, Jan 11, 2021 at 3:52 PM Tom de Vries wrote:
>
> On 1/12/21 12:40 AM, Andy Lutomirski wrote:
> > On Mon, Jan 11, 2021 at 1:06 PM Andy Lutomirski wrote:
> >>
> >>
> >>> On Jan 11, 2021, at 12:00 PM, Borislav Petkov wrote:
> >>>
> >>
> >>
> >>> Or do you mean I should add "unsafe_fsgsbase"
On Mon, Jan 11, 2021 at 1:06 PM Andy Lutomirski wrote:
>
>
> > On Jan 11, 2021, at 12:00 PM, Borislav Petkov wrote:
> >
>
>
> > Or do you mean I should add "unsafe_fsgsbase" to grub cmdline and bisect
> > with fsgsbase enabled in all test kernels?
>
> Yes. But I can also look myself in a bit.
>
On 1/12/21 12:40 AM, Andy Lutomirski wrote:
> On Mon, Jan 11, 2021 at 1:06 PM Andy Lutomirski wrote:
>>
>>
>>> On Jan 11, 2021, at 12:00 PM, Borislav Petkov wrote:
>>>
>>
>>
>>> Or do you mean I should add "unsafe_fsgsbase" to grub cmdline and bisect
>>> with fsgsbase enabled in all test kernels?
> On Jan 11, 2021, at 12:00 PM, Borislav Petkov wrote:
>
> Or do you mean I should add "unsafe_fsgsbase" to grub cmdline and bisect
> with fsgsbase enabled in all test kernels?
Yes. But I can also look myself in a bit.
On Mon, Jan 11, 2021 at 11:27:38AM -0800, Andy Lutomirski wrote:
> Hmm. Can you try booting with unsafe_fsgsbase and bisecting further?
Well, that bisection ended in that patch:
# first bad commit: [b745cfba44c152c34363eea9e052367b6b1d652b] x86/cpu: Enable
FSGSBASE on 64bit by default and add a
On Mon, Jan 11, 2021 at 10:15 AM Borislav Petkov wrote:
>
> Hi,
>
> so there's a breakage of a use case with gdbserver on fsgsbase machines,
> see
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=26804
>
> Tom has an even simpler reproducer:
>
> $ cat test.c
> int
> main (void)
> {
> return 0
13 matches
Mail list logo