From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 25 23:55:34 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E7B316A421 for ; Fri, 25 Jan 2008 23:55:34 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (bhuda.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 150A613C448 for ; Fri, 25 Jan 2008 23:55:33 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 41783 invoked by uid 1001); 25 Jan 2008 23:55:28 -0000 Received: from bhuda.mired.org (localhost.localdomain [127.0.0.1]) by bhuda.mired.org (tmda-ofmipd) with ESMTP; Fri, 25 Jan 2008 18:55:27 -0500 Date: Fri, 25 Jan 2008 18:55:27 -0500 To: freebsd-hackers@freebsd.org Message-ID: <20080125185527.639f62b1@bhuda.mired.org> In-Reply-To: <86068e730801251451n650b7abcyf3d008fddec2c33f@mail.gmail.com> References: <86068e730801251451n650b7abcyf3d008fddec2c33f@mail.gmail.com> Organization: Meyer Consulting X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.12; amd64-portbld-freebsd6.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) From: Mike Meyer Subject: Re: a new syscalls table X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2008 23:55:34 -0000 On Fri, 25 Jan 2008 14:51:44 -0800 "Jerry Toung" wrote: > Hello list, > I am trying to create an environment where you can't run my binaries on your > box and I can't run > your binaries on my system (x86 platform). > For that, I have modified the system calls table (i.e everything is offset > by 5). [...] > When it comes back, it panics in kern/kern_exit.c with > "Going nowhere without my init!" > > How can I make this work? Treat it like a cross-platform build, and install to a different partition on your disk, then boot that partition. > Is my initial objective even possible? > I think the correct approach would be to have a cpu that no else in the > world has, > any in between solution.? Depends on what you mean by "correct approach". Basically, it's a security issue. So you almost certainly can't make it mathematically impossible, but you can raise the cost of people running your binaries on their box - and vice versa - pretty much as high as you want, providing you're willing to pay for it. I'm not sure how well fabbing custom silicon would work; it's certainly at the high end of the cost scale, but it can be reverse engineered, and then your custom CPU could be emulated in software for a lot less than it cost you to design the silicon. Of course, you could take that approach yourself to save money. On the other hand, once you realize that it's a security issue, you can start using security tools for this. For instance, the NetBSD executable verification feature does half the job - it won't run their executables on your system. By tweaking it a bit - encrypting as well as signing, for instance - you'd do both halves, with better performance than emulating a new CPU, and a lot less work. Personally, I think that'd also be more useful to the rest of the community than an offset syscall table as well. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.