Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAHk-=wjhQkZ=mUxPog4+kU1y5BRKw2DpbFXsEP=31fgX4KfBZQ@mail.gmail.com>
 <BFAB82E3-267B-4CF5-B6F2-8E6A2A3DB42B@amacapital.net> <CAP045Aq7PNQyhkT0S5GBzSRUTY4-SGsjs47Z0cCxoPeE-Od_+A@mail.gmail.com>
In-Reply-To: <CAP045Aq7PNQyhkT0S5GBzSRUTY4-SGsjs47Z0cCxoPeE-Od_+A@mail.gmail.com>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Sun, 31 Jan 2021 15:40:41 -0800
Message-ID: <CALCETrVZp6-1Rg_DEKggUqZAzQ_iXXMd4d690ByPGb8B9F6dzQ@mail.gmail.com>
Subject: Re: [REGRESSION] x86/entry: TIF_SINGLESTEP handling is still broken
To:     Kyle Huey <me@kylehuey.com>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andy Lutomirski <luto@kernel.org>,
        Gabriel Krisman Bertazi <krisman@collabora.com>,
        open list <linux-kernel@vger.kernel.org>,
        "Robert O'Callahan" <rocallahan@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sun, Jan 31, 2021 at 3:39 PM Kyle Huey <me@kylehuey.com> wrote:
>
> On Sun, Jan 31, 2021 at 3:36 PM Andy Lutomirski <luto@amacapital.net> wro=
te:
> > > The odd system call tracing part I have no idea who depends on it
> > > (apparently "rr", which I assume is some replay thing), and I suspect
> > > our semantics for it has been basically random historical one, and
> > > it's apparently what changed.
> > >
> > > That's the one that we _really_ should have a test-case for, along
> > > with some documentation and code comment what the actual semantics
> > > need to be so that we don't break it again.
> >
> > This rr thing may be tangled up with the nonsense semantics of SYSRET. =
 I=E2=80=99ll muck around with Kyle=E2=80=99s test and try to figure out wh=
at broke.
> >
> > I=E2=80=99m guessing the issue is that we are correctly setting TF in t=
he EFLAGS image, but IRET helpfully only traps after the first user insn ex=
ecutes, which isn=E2=80=99t what the tracer is expects.
>
> The state of TF shouldn't really matter here. There should be no user
> space code execution in the example I gave. This behavior all happens
> in the kernel and not on the silicon.
>

I admit that PTRACE_SINGLESTEP seems like an odd way to spell "advance
to the end of the syscall", but you're right, it should work.