Re: [PATCH v6 1/3] x86_64: Set the syscall register right before doing the syscall.

[Joe Simmons-Talbott <josimmon@redhat.com>]

On Wed, May 31, 2023 at 01:23:44PM -0500, Noah Goldstein wrote:
> On Tue, May 30, 2023 at 5:13 AM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * Noah Goldstein:
> >
> > > On Fri, May 26, 2023 at 5:59 AM Joe Simmons-Talbott <josimmon@redhat.com> wrote:
> > >>
> > >> On Fri, May 26, 2023 at 09:04:06AM +0200, Florian Weimer wrote:
> > >> > * Noah Goldstein via Libc-alpha:
> > >> >
> > >> > > I'm minorly opposed to this patch. Even if GLIBC guarantees all
> > >> > > syscalls will set the number the instruction before, that's no guarantee
> > >> > > for the entire program. Furthermore in the event of:
> > >> > >    `movl $VAL, %eax; syscall`
> > >> > > It's still not safe to *always* assume that `VAL` correspond to the
> > >> > > syscall number as a jump (direct or indirect) could still go between
> > >> > > the instructions (i.e there is no guarantee in the assembly that the
> > >> > > `mov` dominates the `syscall).
> > >> > > So at the end of the day, we are bloating the library without, AFAICT,
> > >> > > providing any real guarantee. Maybe I'm missing something?
> > >> >
> > >> > Joe, is there a size change to libc.so.6 as the result of this change?
> > >>
> > >> No, the size is the same with and with out this patchset on x86_64.
> > >>
> > > There aren't many syscalls so it's only a minor cost (hence the only
> > > minor opposition), but I don't see the value this provides given that it
> > > still won't be safe to assume the syscall number is always set the
> > > instruction beforehand for any robust purpose. So it still feels like
> > > why take any cost at all?
> >
> > I think there is any run-time cost at all, only the increased source
> > complexity.
> >
> > It's much easier to change glibc than to add full register tracking to a
> > the static analysis tool that discovers system calls in the disassembly.
> >
> 
> Is the aim only to verify libc.so or to verify arbitrary binaries? If the
> former then sure I guess we know we only use the syscall wrapper
> so this may help (more on that), but if it's arbitrary binaries there
> is no guarantee they are using the GLIBC syscall wrapper for their
> syscalls.
> 
> If it really is just GLIBC then this change seems unnecessary. Even
> if there can be separation between setting rax and the syscall, the
> way we have the wrappers setup we know there will always be a
> dominating write to rax with the syscall number so would rather see
> the case where that isn't trivial to find as a motivator first. Or we could
> just do source code level analysis as we will always have the
> syscall number in macro invocation.
> 

Right now we are only concerned with libc.so.  Here's an example case
from my installed libc.so.

000000000003ec70 <__GI___arc4random_buf.part.0>:
   3ec70:       55                      push   %rbp
   3ec71:       41 b8 3e 01 00 00       mov    $0x13e,%r8d
   3ec77:       48 89 e5                mov    %rsp,%rbp
   3ec7a:       41 56                   push   %r14
   3ec7c:       41 55                   push   %r13
   3ec7e:       41 54                   push   %r12
   3ec80:       49 89 fc                mov    %rdi,%r12
   3ec83:       53                      push   %rbx
   3ec84:       48 89 f3                mov    %rsi,%rbx
   3ec87:       48 83 ec 10             sub    $0x10,%rsp
   3ec8b:       64 48 8b 04 25 28 00    mov    %fs:0x28,%rax
   3ec92:       00 00 
   3ec94:       48 89 45 d8             mov    %rax,-0x28(%rbp)
   3ec98:       31 c0                   xor    %eax,%eax
   3ec9a:       31 d2                   xor    %edx,%edx
   3ec9c:       48 89 de                mov    %rbx,%rsi
   3ec9f:       4c 89 e7                mov    %r12,%rdi
   3eca2:       44 89 c0                mov    %r8d,%eax
   3eca5:       0f 05                   syscall

And with my patchset:

0000000000039480 <__GI___arc4random_buf.part.0>:
   39480:       41 55                   push   %r13
   39482:       41 54                   push   %r12
   39484:       55                      push   %rbp
   39485:       48 89 fd                mov    %rdi,%rbp
   39488:       53                      push   %rbx
   39489:       48 89 f3                mov    %rsi,%rbx
   3948c:       48 83 ec 18             sub    $0x18,%rsp
   39490:       31 d2                   xor    %edx,%edx
   39492:       48 89 de                mov    %rbx,%rsi
   39495:       48 89 ef                mov    %rbp,%rdi
   39498:       b8 3e 01 00 00          mov    $0x13e,%eax
   3949d:       0f 05                   syscall 


Thanks,
Joe