Date: Fri, 25 Jan 2008 16:08:33 -0800 From: "Jerry Toung" <jrytoung@gmail.com> To: "Mike Meyer" <mwm-keyword-freebsdhackers2.e313df@mired.org> Cc: freebsd-hackers@freebsd.org Subject: Re: a new syscalls table Message-ID: <86068e730801251608w502edfc4ja58875f13336f461@mail.gmail.com> In-Reply-To: <20080125185527.639f62b1@bhuda.mired.org> References: <86068e730801251451n650b7abcyf3d008fddec2c33f@mail.gmail.com> <20080125185527.639f62b1@bhuda.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@mired.org> wrote: > 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. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86068e730801251608w502edfc4ja58875f13336f461>