public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, libc-ports@sourceware.org
Subject: Re: [PATCH][BZ #15054] MIPS: Fix syscall wrappers for syscall restart support
Date: Wed, 23 Jan 2013 18:13:00 -0000	[thread overview]
Message-ID: <201301231317.34359.vapier@gentoo.org> (raw)
In-Reply-To: <alpine.DEB.1.10.1301230518180.4834@tp.orcam.me.uk>

[-- Attachment #1: Type: Text/Plain, Size: 1592 bytes --]

On Wednesday 23 January 2013 00:40:24 Maciej W. Rozycki wrote:
> On Wed, 23 Jan 2013, Mike Frysinger wrote:
> > >  We have an issue with the INTERNAL_SYSCALL_NCS wrapper in that it does
> > > not respect the kernel's syscall restart convention.
> > > 
> > >  That convention requires the instruction immediately preceding SYSCALL
> > > to initialize $v0 with the syscall number.  Then if a restart triggers,
> > > $v0 will have been clobbered by the syscall interrupted, and needs to
> > > be reinititalized.  The kernel will decrement the PC by 4 before
> > > switching back to the user mode so that $v0 has been reloaded before
> > > SYSCALL is executed again.  This implies the place $v0 is loaded from
> > > must be preserved across a syscall, e.g. an immediate, static
> > > register, stack slot, etc.
> > 
> > naïvely, but why can't the mips kernel paths take care of the reload
> > itself ? other arches have scratch space in their pt_regs for doing just
> > this (a bunch of arches use the orig_<reg> convention).
> 
>  I agree it would be the most reasonable approach if designing from
> scratch; unfortunately what we have is how the ABI has been set back in
> 1994.  You won't be able to patch up all the kernel binaries out there,
> sigh...

sure, you won't be able to retroactively fixing kernels.  but you'll be able to 
make future kernels more robust against shady userlands.  as you've pointed 
out, this is an extremely subtle bug that can easily go unnoticed for a long 
time which simply injects random flakiness into the runtime system.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2013-01-23 18:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-23  3:09 Maciej W. Rozycki
2013-01-23  5:05 ` Mike Frysinger
2013-01-23  5:40   ` Maciej W. Rozycki
2013-01-23 18:13     ` Mike Frysinger [this message]
2013-01-29 18:12       ` Maciej W. Rozycki
2013-01-29 19:04         ` Ralf Baechle
2013-01-29 19:12           ` Maciej W. Rozycki
2013-01-30  1:26             ` Ralf Baechle
2013-01-30  6:50               ` Mike Frysinger
2013-01-23 17:06 ` Joseph S. Myers
2013-01-24 12:47   ` Maciej W. Rozycki
2013-01-24 16:31     ` Joseph S. Myers
2013-01-29 18:10       ` Maciej W. Rozycki
2013-01-29 23:59         ` Joseph S. Myers
2013-02-05 15:26           ` Maciej W. Rozycki

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=201301231317.34359.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=libc-ports@sourceware.org \
    --cc=macro@codesourcery.com \
    --cc=ralf@linux-mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).