Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262091AbVDRO7u (ORCPT ); Mon, 18 Apr 2005 10:59:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262093AbVDRO7u (ORCPT ); Mon, 18 Apr 2005 10:59:50 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:2006 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S262091AbVDRO7o (ORCPT ); Mon, 18 Apr 2005 10:59:44 -0400 Subject: Re: intercepting syscalls From: Arjan van de Ven To: Igor Shmukler Cc: Rik van Riel , Daniel Souza , linux-kernel@vger.kernel.org In-Reply-To: <6533c1c905041807487a872025@mail.gmail.com> References: <6533c1c905041511041b846967@mail.gmail.com> <1113588694.6694.75.camel@laptopd505.fenrus.org> <6533c1c905041512411ec2a8db@mail.gmail.com> <6533c1c905041512594bb7abb4@mail.gmail.com> <6533c1c905041807487a872025@mail.gmail.com> Content-Type: text/plain Date: Mon, 18 Apr 2005 16:59:37 +0200 Message-Id: <1113836378.6274.69.camel@laptopd505.fenrus.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Spam-Score: 3.7 (+++) X-Spam-Report: SpamAssassin version 2.63 on pentafluge.infradead.org summary: Content analysis details: (3.7 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.1 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org [] 2.5 RCVD_IN_DYNABLOCK RBL: Sent directly from dynamic IP address [80.57.133.107 listed in dnsbl.sorbs.net] 0.1 RCVD_IN_SORBS RBL: SORBS: sender is listed in SORBS [80.57.133.107 listed in dnsbl.sorbs.net] X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 930 Lines: 26 > Intercepting system call table is an elegant way to solve many > problems. I think I want to take offence to this. It's the worst possible way to solve many problems, especially since almost everyone who did this to get anything done until today got it wrong. It's about locking. Portability. Stability but also about doing things at the right layer. The syscall layer is almost NEVER the right layer. Can you explain exactly what you are trying to do (it's not a secret I assume, kernel modules are GPL and open source after all, esp such invasive ones) and I'll try to tell you why it's wrong to do it at the syscall intercept layer... deal ? Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/