Date: Fri, 25 Jan 2008 18:55:27 -0500 From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> To: freebsd-hackers@freebsd.org Subject: Re: a new syscalls table Message-ID: <20080125185527.639f62b1@bhuda.mired.org> In-Reply-To: <86068e730801251451n650b7abcyf3d008fddec2c33f@mail.gmail.com> References: <86068e730801251451n650b7abcyf3d008fddec2c33f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Jan 2008 14:51:44 -0800 "Jerry Toung" <jrytoung@gmail.com> 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.
<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080125185527.639f62b1>