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 < [EMAIL PROTECTED]> wrote: > On Fri, 25 Jan 2008 14:51:44 -0800 "Jerry Toung" <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"