All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Borislav Petkov <bp@alien8.de>, X86 ML <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: ia32_sysenter_target does not preserve EFLAGS
Date: Sat, 28 Mar 2015 10:46:33 +0100	[thread overview]
Message-ID: <20150328094633.GB9900@gmail.com> (raw)
In-Reply-To: <CAK1hOcNaecPc=0y6Z3LUGAFrB9_DfCmCx3Z1pLeZ5jTNviqGXA@mail.gmail.com>


* Denys Vlasenko <vda.linux@googlemail.com> wrote:

> On Fri, Mar 27, 2015 at 9:00 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Fri, Mar 27, 2015 at 7:25 AM, Denys Vlasenko <dvlasenk@redhat.com> wrote:
> >>
> >> Apparently, users *don't* depend on arithmetic flags
> >> to survive over syscall. They also okay with DF flag
> >> being cleared.
> >
> > Generally, users probably dont' care about many registers at all being
> > saved, but it's worth noting that the reason system calls save/restore
> > even caller-saved registers is at least partly in order to avoid any
> > kernel information leaks.
> >
> > I don't believe that user mode will ever reasonably care about the
> > arithmetic flags being changed, but at the same time I also don't it
> > is something we should ever consider a "feature" we should try to take
> > advantage of. Generally we should try to not mess with the flag state,
> > and I'd *much* rather make the rule be that all the system call return
> > paths restore flags as much as possible.
> 
> "We don't clobber anything" ABI has its appeal.
> OTOH, fulfilling ABI's promises has cost which hast to be paid
> on every syscall, regardless whether userspace needed it or not.
> 
> Example. This is the uclibc implementation of write():
> 
> 00000000004acfc4 <__libc_write>:
>   4acfc4:       53                      push   %rbx
>   4acfc5:       48 63 ff                movslq %edi,%rdi
>   4acfc8:       b8 01 00 00 00          mov    $0x1,%eax
>   4acfcd:       0f 05                   syscall
>   4acfcf:       48 89 c3                mov    %rax,%rbx
>   4acfd2:       48 81 fb 00 f0 ff ff    cmp    $0xfffffffffffff000,%rbx
>   4acfd9:       76 0f                   jbe    4acfea <__libc_write+0x26>
>   4acfdb:       e8 64 15 00 00          callq  4ae544 <__GI___errno_location>
>   4acfe0:       89 da                   mov    %ebx,%edx
>   4acfe2:       f7 da                   neg    %edx
>   4acfe4:       89 10                   mov    %edx,(%rax)
>   4acfe6:       48 83 c8 ff             or     $0xffffffffffffffff,%rax
>   4acfea:       5b                      pop    %rbx
>   4acfeb:       c3                      retq
> 
> This is a C function. [...]

Arguably that's a self-inflicted wound of uclibc: nothing keeps it 
from taking advantage of the syscall ABI and avoiding the double 
save/restores.

> [...] Therefore any its caller assumes that C-clobbered registers 
> can be, indeed, clobbered here, so if that caller uses any of them, 
> it saves/restores them.
> 
> All efforts by kernel code to save/restore C-clobbered registers, 
> eight of them, are in vain. It's just useless work. Userspace does 
> not benefit from that effort.

That's true only in this particular uclibc case, where user-space 
decided to not take advantage of the save/restore property of the 
kernel.

> If our syscall ABI would say that those regs are not preserved, we 
> could have a bit faster syscalls. Any userspace code which really 
> had to have those registers preserved across a particular syscall, 
> could push/pop them itself.

We'd at minimum have to zero out the registers to avoid the 
information leak and at that point it's in fact faster to just 
save/restore in the syscall and allow user-space to take advantage of 
that, if it wishes to.

We cannot do it the other way around.

Thanks,

	Ingo

  parent reply	other threads:[~2015-03-28  9:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-27 14:25 ia32_sysenter_target does not preserve EFLAGS Denys Vlasenko
2015-03-27 17:12 ` Borislav Petkov
2015-03-27 18:37 ` Andy Lutomirski
2015-03-27 20:09   ` Linus Torvalds
2015-03-27 20:16     ` Andy Lutomirski
2015-03-27 20:31       ` Linus Torvalds
2015-03-27 21:11         ` Andy Lutomirski
2015-03-28  9:42     ` Borislav Petkov
2015-03-27 20:53   ` Brian Gerst
2015-03-27 21:02     ` Linus Torvalds
2015-03-28  9:30       ` Ingo Molnar
2015-03-28  9:39       ` Ingo Molnar
2015-03-27 20:00 ` Linus Torvalds
2015-03-28  0:34   ` Denys Vlasenko
2015-03-28  9:28     ` Olivier Galibert
2015-03-28  9:46     ` Ingo Molnar [this message]
2015-03-28 11:17       ` Denys Vlasenko
2015-03-29 17:12         ` Andy Lutomirski
     [not found]     ` <CA+55aFxwNq6g+Oi-UhGBgEZuDQyNkeg6qZnkDY11PNhTN=fmzg@mail.gmail.com>
2015-03-28 11:01       ` Denys Vlasenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150328094633.GB9900@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=dvlasenk@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=torvalds@linux-foundation.org \
    --cc=vda.linux@googlemail.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.