[colug-432] bedrock linux: how's it work? Re: November COLUG Meeting Announcement
danthau at bedrocklinux.org
Sat Nov 22 12:01:25 EST 2014
On Fri, Nov 21, 2014 at 03:12:43AM -0500, Jeff Frontz wrote:
> Is there any place that gives a description of how bedrock linux works?
> I've read what the benefits are, why you'd use it, etc., but what exactly
> is going on under the covers? After some googling, I saw some hint on
> slashdot and elsewhere that chroot and bind-mounting are employed -- but
> what else? Modifications to exec* (and other?) system calls?
How Bedrock Linux works changes substantially between releases. I
essentially gave up trying to maintain any up-to-date documentation on
how it works at a low level. I'd rather spend the time working on the
still unfinished project. I fully intend to document it in detail once
it hits 1.0 stable, at which time the regular churn will have
The hardest part of answering a question such as yours is that there is
a lot that Bedrock Linux has to do - there isn't just one thing to hook
into and have everything work that I could explain and be done with it.
While the specific details have changed since the over two year old
slashdot article, chroot() and bind-mounts are still used, as are shared
subtrees, pivot_root() (in the next release), multiple FUSE filesystems,
capabilities, various toying with $PATH-style variables, hooking into
the startup routines for login shells (e.g. /etc/profile), (ab)using
obscure nuances of how Linux implements things such as relative
filesystem path resolution. I'm probably forgetting other things - that
was just off the top of my head. Any and all of those may end up being
dropped later as the strategy evolves. There's also experimentation
with other things for possibly inclusion in future releases, such as
on-the-fly alteration of binary executables.
Bedrock Linux does not modify any system calls. This is for two
- Bedrock Linux lets the user get as much as is possible from other
distros (or compile themselves). This includes kernels. I can't
predict what crazy kernel an end-user will want - maybe they've
already done something weird to exec(). There's potential conflicts
there that would be best avoided. Bedrock Linux does impose some
requirements on the kernel - e.g. FUSE support - but they're all very
common. The only problem I've run into is grsec "securing" away
aspects of chroot() that Bedrock Linux relies on. Outside of that I
want to impose as little as possible. Let the user get their kernel
from whatever obscure distro they want, or build it however they
- It would require recompiling kernel modules every kernel change which
would be non-trivial to implement in an automated fashion (given
nuances of how Bedrock Linux works), and a giant pain if required to
be done manually.
Linux's hooks from the userland are surprisingly flexible and, thus far,
have been sufficient to get the job done. There's been discussion of
branching off another approach utilizing modules but I'm doubtful it
will be seriously pursued until 1.0 is done.
In general, if someone is very serious about potentially contributing to
a complicated part of the system, I'll be happy to take the time to walk
them through how it works. Otherwise, the choices largely boil down to
some combination of using the system and poking around, walking through
the code base to figure it out, following development discussions by
idling in the IRC room (especially during the monthly developer
meetings), or waiting until the planned write-up that should occur once
the churn dies down.
Daniel "paradigm" Thau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature
Url : http://lists.colug.net/pipermail/colug-432/attachments/20141122/85d61cad/attachment.bin
More information about the colug-432