public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Levon <moz@compsoc.man.ac.uk>
To: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@caldera.de>
Subject: Re: [PATCH] syscall exports - against 2.4.14-pre3
Date: Tue, 30 Oct 2001 15:15:07 +0000	[thread overview]
Message-ID: <20011030151505.B7294@compsoc.man.ac.uk> (raw)
In-Reply-To: <20011029173711.B24272@caldera.de> <3BDE7D22.8000006@purplet.demon.co.uk> <20011030113731.A14808@caldera.de>
In-Reply-To: <20011030113731.A14808@caldera.de>

On Tue, Oct 30, 2001 at 11:37:31AM +0100, Christoph Hellwig wrote:

> This is not only racy (no locking!) but also a loophole for binary
> modules to do all kinds of crap (see http://www.sysinternals.com/linux/
> utilities/filemon.shtml for details).  In early 2.5 I will submit a patch
> to remove the export, let's see wether it will be accepted.

This means that "funky" modules that do overload system calls will break
irredeemably. Yes, it's ugly, and dangerous, but is definitely useful in
a small number of situations.

What would nice is a "transparent" binfmt a module could add, that always is
first on the binfmt chain and lets things pass through, 
plus some method to intercept syscalls nicely.

A transparent binfmt could be ref-counted also, avoiding the SMP module unload
races in these types of modules.

Before you ask, yes I tried the user-space methods of tracing syscall behaviour.
It was not only unreliable and racy, but slow as hell.

regards
john

-- 
"If the software that a company produces isn't reliable, adding a bunch of
'Mother, may I' rules to the language and the code won't fix it."
	- Pete Becker

      parent reply	other threads:[~2001-10-30 15:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-29 16:37 [PATCH] syscall exports - against 2.4.14-pre3 Christoph Hellwig
2001-10-30 10:12 ` Mike Jagdis
2001-10-30 10:37   ` Christoph Hellwig
2001-10-30 10:44     ` Arjan van de Ven
2001-10-30 15:15     ` John Levon [this message]

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=20011030151505.B7294@compsoc.man.ac.uk \
    --to=moz@compsoc.man.ac.uk \
    --cc=hch@caldera.de \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox