> > ... > > Hope it helps. > > Thanks for the information. > However I would like still know how to recompile the > kernel: > I don't trust binary files. I know some kernel > programming unter Linux. I would like to use > OpenSolaris on a production system, and I would be > able to fix the kernel if there is a problem. Maybe I > would pay someone to do this for me. But I would like > to know if its easy, like in Linux and BSD*?
Don't trust binary files all you like. That's maybe not a bad idea. But it's no guarantee, either. Even if you compile everything, including the compiler, someone tricky enough could still sneak something in on you. See http://cm.bell-labs.com/who/ken/trust.html So I think you're just about as safe trusting Sun distros (Solaris, SXCE, OpenSolaris yyyy.mm). The Solaris (as opposed to OpenSolaris) distro is proprietary, given that it has more closed-source stuff in it (there's still a handful of binary only modules needed to build OpenSolaris, but they're kept to a minimum and there's a page listing the status of those somewhere); however, for Solaris (but not OpenSolaris distros, AFAIK) there's a fingerprint database with MD5s or somesuch for every version of every binary file that's been released for quite some time. So even with a binary-only distro, one could check these things. For Solaris (but not OpenSolaris anymore, I think) there's a tool called "aset", which can tighten permissions to one of various levels and also verify checksums against a database (sort of like tripwire); that can also be done for any non-volatile and non-editable files in SVR4 packages (since checksums are recorded); I don't know enough about IPS to know whether/how it can do that sort of checks. So there's a lot that can be done even with a binary distro to keep it just about as secure as you likely could with source. And as long as your header files match the binaries, and you stick to published interfaces rather than calling random kernel functions, you can write your own loadable drivers without compiling (or even looking at, unless you want to) the rest of the kernel source. Traditionally, even way back in v7 days, end users didn't recompile Unix; at most, they'd recompile a few files with the help of a configuration program, and link those with a bunch of static libraries or something to produce a new kernel. Back then, even if one had full source, it just took too darn long to recompile everything. Of course, universities that were doing kernel development of features beyond plain drivers still did, but those were research systems, not production systems or desktops where there was an expectation of very high uptime. So a full recompile was never made particularly easy; the makefiles are set up for the workflow of the primary developers, and are not particularly understandable, made even more complicated since most of it should compile with either Sun's compilers or gcc now. Since the makefiles are so intertwined, it's not really meant to let you build one program or module without building everything, nor even update (although I suppose with a small change, most of the time would be spent rediscovering that most targets were already current). I suppose there's an advantage to that, although It's a pain and appears at first glance to waste a lot of time: inconsistencies get caught a lot sooner than they would otherwise, which means less in the way of seemingly unrelated new regressions or bugs. So yes, it can be done. There is enough documentation to do it, although I wouldn't say it's quite as clean as a single complete checklist. Presumably the independent distros (at least the ones before OpenSolaris the distro, as opposed to OpenSolaris the codebase) did just that, since the other Sun distro based on OpenSolaris (SXCE, and in the past, SXDE) was itself not redistributable. But it's frustrating enough that a number of people here haven't. I certainly read the code, and understand a fair bit of it (since I've seen various versions of Unix code: v7, System III, SVR2, SVR3, SVR4.0 SPARC reference port, and a couple of others) at one time or another. But I have yet to have the patience to attempt recompiling everything (although for some simple user-land programs, I've just copied their source directory and made my own standalone makefile, so I could fool with them a bit). And I suspect I'm not the only one not to undertake a frustrating and time-consuming process without more reason than just sort of wanting to, esp. since there have been so few things I wanted to do that couldn't be done any other way. I love source code access. It may let me understand better what I can do with a debugger or DTrace, or do smarter troubleshooting and bug reports, or even propose simple patches. But I'd probably not _implement_ those myself, nor even want to (lest I have binaries that no longer match the distro checksums). So unless I want to do some heavy development (not just an extra library function or command option or such), I can't see why I'd want to immerse myself to the point of recompiling, esp. since quite a bit can be tuned and tweaked and even modified without doing that. See for example http://www.roqe.org/papillon/ which does quite a bit without requiring a kernel recompile (although because of that, it breaks a lot of rules, so I only mention it as an example of what's possible, and not as one to follow). I've done vaguely similar things myself on some older Unix versions that I didn't have any matching source for other than the header files. Last but not least, a lot of the internals are quite different from Linux. The expectations for contributed code are probably also quite different; certainly the _process_ of contributing is different. None of which should discourage you from going there, if you know you have a really good reason; the more that learn to, the better. But it's probably more effort for less situations where it's necessary, so I don't know that I'd suggest going there just for curiosity or the notion that source is more trustworthy than verifiably unaltered binaries from someone with a good reputation. PS: there are supposed to be test servers available, for which anyone can sign up for an LDOM (SPARC) or presumably virtual instance under xen (x86). I don't know if those come with the current source, compiler, build tools, etc already installed (so that one had a full build environment ready to go); if they did, that might well take away enough of the difficulties to make one's first attempts to build everything a lot less frustrating. If it turns out they do, I'll probably go that route the first time I have a reason to do a full build, rather than doing it on my own boxes (which I don't necessarily want to be constantly updating to stay at a version that's appropriate for building the code I'm looking at). In other words, why mess up your own system, unless you've truly got an otherwise unused spare. On x86, I guess it's no big if a virtual environment does the job, since that's really just one big file to the host. But for SPARC, I'm still waiting for the price of a working used T1000 to drop below US $1,000. :-) -- This message posted from opensolaris.org
