Re: [PATCH 0/8] use struct pt_regs based syscall calling for x86-64

[Ingo Molnar <mingo@kernel.org>]

* Dominik Brodowski <linux@dominikbrodowski.net> wrote:

> On Thu, Apr 05, 2018 at 05:19:33PM +0200, Ingo Molnar wrote:
> > Ok, this series looks mostly good to me, but AFAICS this breaks the UML build:
> > 
> >  make[2]: *** No rule to make target 'archheaders'.  Stop.
> >  arch/um/Makefile:119: recipe for target 'archheaders' failed
> >  make[1]: *** [archheaders] Error 2
> >  make[1]: *** Waiting for unfinished jobs....
> 
> Ah, that's caused by patch 8/8 which I did and do not like all that much
> anyway: UML re-uses syscall_64.tbl which now has x86-specific entries like
> __sys_x86_pread64, but expects the generic syscall stub sys_pread64
> referenced there. Fixup patch below; could be folded with patch 8/8. Or
> patch 8/8 could simply be dropped from the series altogether...

I still like the 'truth in advertising' aspect. For example if I see this in the 
syscall table:

 10      common  mprotect                __sys_x86_mprotect

I can immediately find the _real_ syscall entry point:

ffffffff81180a10 <__sys_x86_mprotect>:
ffffffff81180a10:       48 8b 57 60             mov    0x60(%rdi),%rdx
ffffffff81180a14:       48 8b 77 68             mov    0x68(%rdi),%rsi
ffffffff81180a18:       b9 ff ff ff ff          mov    $0xffffffff,%ecx
ffffffff81180a1d:       48 8b 7f 70             mov    0x70(%rdi),%rdi
ffffffff81180a21:       e8 fa fc ff ff          callq  ffffffff81180720 <do_mprotect_pkey>
ffffffff81180a26:       48 98                   cltq   
ffffffff81180a28:       c3                      retq   
ffffffff81180a29:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)

If, on the other hand, I see this entry:

 10     common  mprotect                sys_mprotect

Then, as a first step, no symbol anywhere matches with this:

 triton:~/tip> grep sys_mprotect System.map 
 triton:~/tip> 

"sys_mprotect" does not exist in any easily discoverable sense. You have to *know* 
to replace the sys_ prefix with __sys_x86_ to find it.

Now arguably we could use a __sys_ prefix instead of the grep-barrier __sys_x86 
prefix - but that too would be somewhat confusing I think.

I mean, the fact that we are passing in a ptregs pointer is a complexity of the 
x86 kernel that *exists*, why hide it and make it harder to discover what's 
happening, for something as important as system calls?

In terms of UML breakage, UML arguably is tightly coupled to its host 
architecture:

> Subject: [PATCH] syscalls/x86: fix UML syscall table

Even with your patch applied I still see build failures:

  $ make ARCH=um defconfig
  $ make ARCH=um linux
  ...
  arch/um/os-Linux/signal.c: In function ‘hard_handler’:
  arch/um/os-Linux/signal.c:163:22: error: dereferencing pointer to incomplete type 
  ‘struct ucontext’
    mcontext_t *mc = &uc->uc_mcontext;
                        ^~
  scripts/Makefile.build:324: recipe for target 'arch/um/os-Linux/signal.o' failed
  make[1]: *** [arch/um/os-Linux/signal.o] Error 1

Thanks,

	Ingo