a new syscalls table

Mike Meyer mwm-keyword-freebsdhackers2.e313df at mired.org
Fri Jan 25 15:55:34 PST 2008


On Fri, 25 Jan 2008 14:51:44 -0800 "Jerry Toung" <jrytoung at 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 at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.


More information about the freebsd-hackers mailing list