lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 13 Oct 2021 05:23:11 +0700
From:   Ammar Faizi <ammar.faizi@...dents.amikom.ac.id>
To:     Willy Tarreau <w@....eu>, Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] tools/nolibc: x86: Remove `r8`, `r9` and `r10` from the clobber list

On Wed, Oct 13, 2021 at 4:51 AM Borislav Petkov <bp@...en8.de> wrote:
>
> On Tue, Oct 12, 2021 at 10:29:55PM +0200, Borislav Petkov wrote:
> > On Tue, Oct 12, 2021 at 11:06:38AM +0200, Willy Tarreau wrote:
> > > Let's indeed wait for any of the x86 maintainers to confirm your
> > > analysis.
> >
> > I guess the official doc you guys are looking for is the x86-64 ABI:
> >
> > https://gitlab.com/x86-psABIs/x86-64-ABI/
> >
> > and recent pdfs are here:
> >
> > https://gitlab.com/x86-psABIs/x86-64-ABI/-/wikis/x86-64-psABI
> >
> > and there you scroll to
> >
> > "A.2 AMD64 Linux Kernel Conventions
> >
> > ...
> >
> > A.2.1 Calling Conventions"
> >
> > and that section explains which regs go where.
>
> Ok, that didn't point to the exact answer - I realize now. I believe
> what you're looking for in that doc is "Figure 3.4: Register Usage"
> which has a column "callee saved" and says that the syscall arg
> registers are all not callee-saved.

No, you were right. A.2.1 was the part we are looking for, thanks for
pointed that. That's the exact answer.

"Figure 3.4: Register Usage" is not the answer, if it were, nolibc.h
would be broken as it is missing "rdi", "rsi", "rdx" in the clobber list.

More info:
I know for a fact that every "syscall" in the libc is wrapped with a
function call, hence those registers are not callee saved, thus clobbered.

However, that is not the case for nolibc.h, because we have a potential
to inline the "syscall" instruction (0f 05) to the user functions. Thus
A.2.1 applies, and "syscall" instruction is not a "call".

All syscalls in the nolibc.h are written as a static function with inline
ASM and are likely always inline if we use optimization flag, so this is
a profit not to have r8, r9 and r10 in the clobber list (currently we 
have them).

------------------------------------------------------------------

According to x86-64 ABI about syscall section A.2 AMD64 Linux Kernel
Conventions, A.2.1 Calling Conventions [1]:

1) User-level applications use as integer registers for passing the
   sequence %rdi, %rsi, %rdx, %rcx, %r8 and %r9. The kernel interface
   uses %rdi, %rsi, %rdx, %r10, %r8 and %r9.

2) A system-call is done via the syscall instruction. The kernel
   destroys registers %rcx and %r11.

3) The number of the syscall has to be passed in register %rax.

4) System-calls are limited to six arguments, no argument is passed
   directly on the stack.

5) Returning from the syscall, register %rax contains the result of
   the system-call. A value in the range between -4095 and -1
   indicates an error, it is -errno.

6) Only values of class INTEGER or class MEMORY are passed to the
   kernel.

>From (2), (5) and (6), we can conclude that Linux x86-64 syscall only
clobbers rax, rcx and r11 (and "memory").

  - rax for the return value.
  - rcx to save the return address.
  - r11 to save the rflags.

Other registers are preserved. Right?
Am I missing something?

>
> And I think that table is valid for the kernel too because the link
> to it says "The Linux AMD64 kernel uses internally the same calling
> conventions as user-level applications (see section 3.2.3 for details)."
>
> HTH.
>

-- 
Ammar Faizi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ