Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     stsp <stsp2@yandex.ru>, linux-kernel@vger.kernel.org
Cc:     x86@kernel.org, luto@kernel.org,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: strange behavior with sigreturn() to 32bit
In-Reply-To: <85ca9ae1-d319-ee77-4a71-bc9c7874f2cb@yandex.ru>
References: <85ca9ae1-d319-ee77-4a71-bc9c7874f2cb@yandex.ru>
Date:   Tue, 13 Dec 2022 01:24:57 +0100
Message-ID: <87zgbsno9y.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Sat, Dec 10 2022 at 14:08, stsp wrote:

Can you please Cc LKML on such mails? x86_64@vger.kernel.org is not used
by any x86 maintainer as you can figure out from looking at the
MAINTAINERS file in the kernel.

> I am playing with 32bit compatibility segments, and I am observing
> something very strange.  To demonstrate the problem, I did the change
> to the kernel sigreturn test-case, and it is attached.  The change
> just moves the magic value to EAX and calls an interrupt that produces
> a SIGSEGV.  The SIGSEGV handler prints the needed regs.  This patch
> intentionally adds 0x100000000 to the RIP register, because AFAIK the
> high part or 64bit regs are irrelevant in compatibility mode.
>
> Now with high part of RIP non-zero, we see this:
> $ ./sigreturn_64
> err=0 trapno=d ax=0 ip=100000003

I just applied the patch and on a 6.1 kernel I get:

# ./sigreturn_64 
[OK]	set_thread_area refused 16-bit data
[OK]	set_thread_area refused 16-bit data
[RUN]	Valid sigreturn: 64-bit CS (33), 32-bit SS (2b, GDT)
[OK]	all registers okay
[RUN]	Valid sigreturn: 32-bit CS (23), 32-bit SS (2b, GDT)
[NOTE]	SP: 8badf00d5aadc0de -> 5aadc0de
[OK]	all registers okay
[RUN]	Valid sigreturn: 16-bit CS (37), 32-bit SS (2b, GDT)

  err=0 trapno=d ax=a5f3 ip=6

Let's look at the disassmbly:

0000000000403000 <int3>:
  403000:       8c d1                   mov    %ss,%ecx
  403002:       cc                      int3

0000000000403003 <int31>:
  403003:       b8 f3 a5 00 00          mov    $0xa5f3,%eax
  403008:       cd 31                   int    $0x31

which is expected and correct:

trapno = 0xd = 13 = #GP
ax     = the magic value
ip     = 6 (Offset to the 'int3:' label in the 16bit CS)
err    = 0

Both 'ip' and 'err' are completely correct here. Why?

The #GP's on 403006. Because in 16bit mode the CPU the disassmbly looks
like this:

  403003:       b8 f3 a5	        mov    $0xa5f3,%eax
  403006:	00 00                   add    %al, (%bx, %si)

so 403006 which is offset 6 into the 16bit CS translates to:

      bx[si] += al;

so in my case:

      bx=0x0 si=0x2903e6d0

which is clearly outside of the DS segment limit resulting in a #GP with
error code == 0.

Your observation that running this under GDB changes the behaviour of
the error is completely correct because BX/SI are subject to context. So
depending where the combo points to it results in random behaviour.

So nothing strange to see here, really. You got what you asked for:

> I am playing with ....

Thanks,

        tglx