a new syscalls table

[Jerry Toung]

Thank you for the feedback Mike.
Points well taken. I'll look into the NetBSD thing.
Jerry

On Jan 25, 2008 3:55 PM, Mike Meyer <
mwm-keyword-freebsdhackers2.e313df at mired.org> wrote:

> 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.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>