August 2012 - kernelnewbies@kernelnewbies.org

Issue with ps -l command "Unknown HZ value! (744514) Assume 100."
by KARTHIK SEKURU Aug. 30, 2012

Aug. 30, 2012

Hi All, I am working on porting linux kernel 3.4 to an arm926-ejs based fpga board. After the kernel bootup, in the command prompt when i am using the command "ps -l "..i am getting the following *sh-4.2# ps -l* *Unknown HZ value! (744514) Assume 100.* * * * * *F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD* *0 S 0 51 1 0 80 0 - 443 wait ttySAC0 00:00:12 sh* *0 R 0 56 51 0 80 0 - 297 - ttySAC0 00:00:04 ps* * * * * The issue i am facing is *"I configured the jiffies for 25Hz,still it is assuming 100hz."* Is this problem related to the filesystem i am using. I am using ".ext2" filesystem build from buildroot. The option set in buildroot for creating filesystem are as mentioned below: *(3.4) linux version * *uClibc C library Version (uClibc 0.9.33.x)* *Binutils Version (binutils 2.21.1)* *GCC compiler Version (gcc 4.7.x)* Will this issue be fixed If i use glibc nstead of uclibc in buildroot ? Thanks, Karthik.

2 1

mmap_min_addr info
by swair shah Aug. 28, 2012

Aug. 28, 2012

quoting the debian wiki for mmap_min_add. "Allowing processes to map low values increases the security implications of a class of defects known as "kernel NULL pointer dereference" defects... The downside to preventing applications from mmap'ing low virtual memory addresses is that certain applications depend on this functionality. dosemu, qemu and wine are three such applications that exist in Debian" I don't understand the use of the mmap_min_add. What's the point of preventing applications from mapping to low memory values. Also why would applications mentioned here would need to map to low memory addresses? A little descriptive explanation would be very helpful!

2 1

Wiki access to kernelnewbies.org
by Sarah Sharp Aug. 27, 2012

Aug. 27, 2012

Greetings, I'd like to update the kernelnewbies.org wiki, but it looks like I need Editor Group permissions: http://kernelnewbies.org/EditorsGroup Can someone from that group add my username (SarahSharp) to the Editor Group? Thanks, Sarah Sharp Linux USB Kernel Developer Open Source Technology Center Intel Corp.

2 2

Re: Wiki access to kernelnewbies.org
by Sarah Sharp Aug. 27, 2012

Aug. 27, 2012

On Mon, Aug 27, 2012 at 01:34:31PM -0700, Greg KH wrote: > On Mon, Aug 27, 2012 at 01:27:49PM -0700, Sarah Sharp wrote: > > Greetings, > > > > I'd like to update the kernelnewbies.org wiki, but it looks like I need > > Editor Group permissions: > > > > http://kernelnewbies.org/EditorsGroup > > > > Can someone from that group add my username (SarahSharp) to the Editor > > Group? > > I just looked, and I don't think I have any account on kernelnewbies.org > at all, so I can't provide this, sorry. > > Sarah, where do you see my name as an editor on the site? I see "GregKH" on that EditorsGroup page. Sarah Sharp

1 0

MAX_ORDER in mmzone.h
by J.Hwan Kim Aug. 27, 2012

Aug. 27, 2012

Hi, everyone I wish to expand the limit for allocating contiguous memory in kernel. So, if I change the value CONFIG_FORCE_MAX_ZONEORDER or MAX_ORDER value in /include/linux/mmzone.h, will it cause any problem or side effect in x86_64 sysem? Thanks in advance. Best Regards, J.Hwan Kim

2 1

*must* a kset have an associated uevent_ops field?
by Robert P. J. Day Aug. 25, 2012

Aug. 25, 2012

perusing kobject event code in lib/kobject_uevent.c and something puzzles me. early in kobject_uevent_env(), code guarantees that we find an ancestor kobject that has a valid kset: /* search the kset we belong to */ top_kobj = kobj; while (!top_kobj->kset && top_kobj->parent) top_kobj = top_kobj->parent; if (!top_kobj->kset) { pr_debug("kobject: '%s' (%p): %s: attempted to send uevent " "without kset!\n", kobject_name(kobj), kobj, __func__); return -EINVAL; } kset = top_kobj->kset; uevent_ops = kset->uevent_ops; so, as i read it, at that point, we're *guaranteed* to have found the closest kobject ancestor with a kset, and we save the relevant values in "kset" and "uevent_ops". so far, so good. but is there any guarantee that "uevent_ops" is non-null? a little below that, we read: if (uevent_ops && uevent_ops->filter) if (!uevent_ops->filter(kset, kobj)) { pr_debug("kobject: '%s' (%p): %s: filter function " "caused the event to drop!\n", kobject_name(kobj), kobj, __func__); return 0; } which clearly first tests if "uevent_ops" is non-null. so does that mean it might be? and the same check occurs twice more in that routine: ... /* originating subsystem */ if (uevent_ops && uevent_ops->name) subsystem = uevent_ops->name(kset, kobj); ... /* let the kset specific function add its stuff */ if (uevent_ops && uevent_ops->uevent) { ... is it really necessary to keep making that test? is there no way to simplify the code so that that test is done early, and reduces the subsequent code? just curious. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

RFC: Enforcing process hierarchies (`prctl` related)
by Ciprian Dorin Craciun Aug. 25, 2012

Aug. 25, 2012

Hello all! I'm about to write quite a long-ish email, but I provide a small summary first for the "busy". :) == Quick summary The context is simple: * the developer wants to write a C application (call it a "controller") that spawns other child processes, which in their turn spawn other processes and so on; * some of these spawned processes might double fork (i.e. they daemonize); * these child processes are not written by the developer in question; (thus we can't "fix" them...) * the controller will run with no special privileges (i.e. non-root, no capabilities, etc.); * (for purely practical reasons, thus let's not start a flame war) we can assume a Linux-only environment, thus portability is not an issue; (the developer is also not scared in applying patches to the kernel...) The problem I try to find a solution to is again quite simple, how can the developer write the "controller" application such that the following happens: (A) any orphaned child of a sub-process (i.e. double forking ones, ones whose parent has exited, etc.) are reparented to the controller; (this is already solved in 3.4;) (B) the controller should be able to kill all its subprocesses (and their subprocesses, recursively); (C) if the controller dies (segfault, killed, etc.) all its subprocesses are terminated (and recursively so); Thus, what "magic" :) should one invoke to obtain the above? == Use cases To better put the problem into a context, the previous features would allow one to implement something like: * "personal" service control systems (like `systemd`, `runit`, `daemon-tools`, etc.); * constrain badly written `sh` scripts that if terminated leak processes; or build systems (like `make`), or SSH sessions, or cron jobs, etc.; * a building block in a PaaS underlaying; But certainly NOT for "security" purposes... == Existing primitives I've really tried thinking about this for the last year or so, and I've not managed to get a "good" enough solution... But I've found the following partial solutions, but all of them have issues... (1) `clone (CLONE_NEWPID)` -> solves all the problems, but has major drawbacks: * it requires special rights (root or capability); * it creates an alternative process namespace thus will confuse the hell out of scripts assuming PID equivalence... (2) `prctl (PR_SET_CHILD_SUBREAPER)` -> solves the issue (A) (reparenting), but that's it. (3) `prctl (PR_SET_PDEATHSIG)` -> solves the issue (C) (forced termination), but it has the following issues: * it works only for the first level of sub-processes, as it must be explicitly set after each `fork`; * thus it is not "inheritable" by new children; * it doesn't work for `setuid` processes (due to possible security issue); (4) `killpg (group)` -> solves the issue (B), but: * any child could choose to change its process group; * if the controller uses its own group it kills itself; Have I missed something? == Brainstorming It would have been nice if either of the following would happen (in order of preference): (a) maybe an additional `PR_SET_CHILD_SUBREAPER`-like flag that would make the controller process really behave like a sub-init, that is on its termination terminate all its children recursively; (b) `PR_SET_PDEATHSIG` would be inheritable at least for non `setuid` processes; (maybe even better if the signal is `SIGKILL` keep it even for `setuid` processes as I don't see too much harm there...) (c) have some way to send a signal to all a process children; (d) (last resort solution we have today) iterate through `/proc/$PID` and find all the controller children, SIGKILL them, and continue until no process is found, then die; but it doesn't solve (C)... Something else? Hope I find some solution to this... (If this is not the mailing list to send it to, please point me in the right direction.) Thanks in advance for feedback, Ciprian.

2 2

Re: RFC: Enforcing process hierarchies (`prctl` related)
by Ciprian Dorin Craciun Aug. 24, 2012

Aug. 24, 2012

On Fri, Aug 24, 2012 at 9:19 PM, Irina Stanescu <ironmissy(a)gmail.com> wrote: > Hi! > > Search for process groups [1] and the setsid/getgid functions [2]. Having > processes in the same process group will allow you to kill them based on > their process group ids with killpg [3]. Hope this helps. I know about this functionality -- I've pointed to them myself in the "Existing primitives" section -- but unfortunately they don't fit the bill because they aren't "enforceable", they are kind of "informative", as any process could easily just change it's group and thus escape control. I'm trying to reach a solution where a "normal" process wouldn't be able to escape such a supervision. By "normal" process I mean one that doesn't use a vulnerability in the operating system or has elevated privileges. But if you mentioned the process group functionality, maybe there is a workaround to "enforce" the `setpgid` usage, that is by using the latest `seccomp` filtering solution, one idea is that the controller process to start a new process group and then forbid it's children from using the `setpgid` (and friends) syscall.

1 0

Porting my BSP to higher Kernel Versions
by Ramya Desai Aug. 24, 2012

Aug. 24, 2012

Dear Experts, I have a working BSP which runs on Kernel 2.6.10. Now I wanted to upgrade my BSP to higher versions like, 2.6.24. Is there any documentation/steps available to do so? Regards, Ramya

3 2

How to know default gcc flags ?
by Pritam Bankar Aug. 24, 2012

Aug. 24, 2012

How to know default flags used in specific gcc version ? I am looking for difference between 3.4.3 and 4.1.1 These two have some difference regarding -nosse option but how can I find this ? -- Pritam Bankar

3 2