similar to: kinit, fstabs and mountpoints on the command line

This patchset applies to klibc mainline. This patchset introduces the ability to kinit to execute scripts or executable files present in in the initramfs before switching over to the root filesystem. It is implemented by first implementing scandir() and alphasort() as present in POSIX.1-2008 in klibc itself, and then using that as the basis for iterating and executing files via a run_scripts()

For our platforms, we'd like to embed several different userland scripts / programs that are executed before we have mounted the root filesystem as part of the initramfs payload. Specifically, I'd like to have multiple scripts executed before do_mounts(), so I coded up this simple do_initscripts function that executes all executables found in /etc/init.d in alphabetically sorted order. I

Add support for scandir() and alphasort() as defined in POSIX.1-2008. Signed-off-by: Mike Waychison <mikew at google.com> --- usr/include/dirent.h | 7 +++++ usr/klibc/Kbuild | 2 + usr/klibc/scandir.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 84 insertions(+), 1 deletions(-) create mode 100644 usr/klibc/scandir.c diff --git

So, today, I'm using kinit from our initramfs to handle early boot up sequence. Our init is actually a shell script that does a some setup stuff (plugging values into appropriate proc files mostly), and the script currently passes on to kinit by finishing with "exec /kinit "$@"". I have a situation now though, where due to some ubuntu weirdness, I seem to need to do

This patchset applies to klibc mainline. This patchset introduces the ability to kinit to execute scripts or executable files present in in the initramfs before switching over to the root filesystem. This functionality is implemented in a newly introduced run_parts() call, which calls scandir() to iterate through files which in then executes in sequence. run_parts() is also available as a

This patchset applies to klibc mainline. As is it will probably collide with Maximilian's recent patch to rename run-init to switch_root posted last week. To boot an untrusted environment with certain capabilities locked out, we'd like to be able to drop the capabilities up front from early userspace, before we actually transition onto the root volume. This patchset implements this by

This patch adds the ability to kinit to allow the dropping of POSIX capabilities. kinit is modified by this change, such that it understands the new kernel command line "drop_capabilities=" that specifies a comma separated list of capability names that should be dropped before switching over to the next init in the boot strap (typically on the root disk). When processing capabilities

The following patchset implements 3 seperate series of changes. External Building ================= Patches 1 through 8 enable to use of klibc's build system while leaving the src tree pristine (and potentially read only). Specifically: - srctree=<Sources for klibc> - objtree=<Ouput directory for klibc> - KLIBCKERNELSRC=<Kernel sources> - KLIBCKERNELOBJ=<Kernel

The kernel header guard to ensure that headers aren't included from userland moved in commit 69c8f52b. This causes the following message to be emitted when building klibc (which is designed to use kernel headers explicitly): /usr/local/src/git/linux-2.6//include/linux/types.h:13:2: warning: #warning "Attempt to use kernel headers from user space, see

Hi Peter, I'm looking at using klibc for a small initramfs for our production servers as a way for us to change a bunch of sysctls at boot as well as handle root= logic. To make my life easier in our build environment, I'd like to build klibc outside of the linux tree and in an always clean source tree (potentially a read-only nfs share), so I'd like to extend the build to support

On Thu, Jul 14, 2011 at 5:48 PM, Mike Waychison <mikew at google.com> wrote: > On Thu, Jul 14, 2011 at 4:39 PM, Alan Cox <alan at lxorguk.ukuu.org.uk> wrote: >>> for stuff I probably should be disabling considering my goal of making >>> it difficult for root to compromise a system. ?And yes, modules are >>> disabled :) >> >> If you have

The following series applies to net-next. The following series changes the low memory paths in virtio_net to allow the driver to contribute to reclaim when memory is tight. It attempts to rectify some performance problems we've seen where the network performance drops significantly when memory is low. The working theory is that while the driver contributes to memory pressure when throughput

The following series applies to net-next. The following series changes the low memory paths in virtio_net to allow the driver to contribute to reclaim when memory is tight. It attempts to rectify some performance problems we've seen where the network performance drops significantly when memory is low. The working theory is that while the driver contributes to memory pressure when throughput

Building on the work in ff0a614bd724f6c4c6a5014a9955dc1bc028f336, this moves the capability code down into the run-init library, so that run-init can use it as well, via the new "-d" flag. Signed-off-by: Kees Cook <kees at outflux.net> --- usr/kinit/Kbuild | 3 +-- usr/kinit/capabilities.h | 10 ++++++++++ usr/kinit/kinit.c | 6 +++---

The "kinit" program distributed with klibc 0.153 still attempts to do a pivot_root. That doesn't work. The correct way of going into the main system is to mount --bind the root and chroot there, as done in the "run-init" program. Could you please copy that logic into "kinit"? And please fix the comment at the top - there is "/init", not

On Mon Jan 30 08:56:06 PST 2006, H. Peter Anvin wrote: > That being said, there is no reason that you can't run code before it; > to make that simpler, in fact, I'm trying to set it up so that the > default initramfs looks like: > > /dev/console > /dev/zero > /dev/null > /kinit > /init -> /kinit I would request we not put in symlinks. The problem is that

The following patch swaps the command line handling of kinit. It seems apparent that, if one were to call kinit like so: kinit root=/foo/bar They would be attempting to override the /proc/cmdline. As it stands, kinit parses the /proc/cmdline *first*, meaning the above does not work. Just for a simple use case: User A has an encrypted root device, root=/dev/hda3 Some init scripts detect this,

I just pushed out klibc-1.2.1; it actually has a working kinit. There are still pieces missing, but at least it works for ipconfig+nfsroot, which has been my test configuration. There is code to handle initrd already in kinit, but it hasn't been tested and so is almost certainly broken; I think the code to load a ramdisk from a floppy or other block device is not yet there. -hpa

- move the space needed by mountpoint mapping to an own function, outside of the checking loop - remove the minimum limit of 100M on partitions, since existing partitions that we check (e.g. /boot) may be smaller than that - in case /boot is not on a separate mountpoint, enforce the space check on the root mountpoint instead, since it is where /boot is in that case --- v2v/v2v.ml | 55

hello hpa, here my birthday submission :) please pull: git pull git://git.debian.org/users/maks/klibc.git maks Sam fixed a longstanding x86_32 build bug, thus it seems a good time to flush the queue of the piled up patches, the shortlog tells it: Aurelien Jarno (1): [klibc] sh4: syscalls fixes Benjamin Cama (1): [klibc] fstype: btrfs size endianness fix Mike Waychison (2):