Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacking the OS X Kernel for Fun and Profiles

research.swtch.com

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Hacking the OS X Kernel for Fun and Profiles

#21

Post by bdash »

klodolph wrote: post #20
mikeash wrote: post #19

Earlier quoted context omitted.

Well, the man page says otherwise, and I'd hate to rely on undocumented safety buried in the standard library. Edit: upon re-reading the man page, this bit caught my eye: "If you need to use these frameworks in the child process, you must exec. In this situation it is reasonable to exec yourself." So that would be one (highly painful) way to handle this safely. Fork, then self-exec, passing in arguments that tell the…

Seems like you're right. Whoops, time to go fix some of my code, which is why I really want a non-broken posix_spawn(). Another silly way to do things is to have the parent process send a list of fds to close over a pipe, which at least doesn't require a second call to exec(). I think the problem with close-on-exec is always going to be simple though: you have to make sure every library you use sets the flag.

OS X provides the POSIX_SPAWN_CLOEXEC_DEFAULT flag to posix_spawn, which results in it automatically closing all file descriptors that aren't described by the file actions passed to posix_spawn.

Re: Hacking the OS X Kernel for Fun and Profiles

#22

Post by endlessvoid94 »

tonyarkles wrote: post #12
endlessvoid94 wrote: post #3

Earlier quoted context omitted.

I think the "hacking X for fun and profit" is a pretty well-known trope.

For me, the origin of this was from "Smashing the stack for fun and profit (1996)"[1], which does actually refer to somewhat malicious purposes. Apparently it has existed in literature for a long time before that though[2]. [1] http://www.phrack.org/issues.html?id=14&issue=49 [2] http://english.stackexchange.com/questions/25205/what-is-the...

Hah, indeed. I had that Aleph One article printed out and stapled, and would carry it with my books in high school!

Re: Hacking the OS X Kernel for Fun and Profiles

#23

Post by [deleted] »

janus wrote: post #9

Can someone explain what this patch actually does? I have an old Macbook Air with a malfunctioning sensor that cause the CPU to always run in powersaving mode (capped at 800 mhz), so it's basically unusable under OS X. I have walked around this issue by installing Linux which allows me to tune the CPU governor manually, and it uncaps the artificial limit that the malfunctioning sensor puts. Would this patch allow me…

[deleted]

Re: Hacking the OS X Kernel for Fun and Profiles

#24

Post by mzs »

Cool, that was a bug, and not too difficult to fix and must have felt great when figured-out. But sometimes on darwin you run into stuff that just is so crufty in the BSD emulation, that it's better to use the mach stuff. In this case these class of routines:

  http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/task_sample.html

Re: Hacking the OS X Kernel for Fun and Profiles

#25

Post by Moto7451 »

janus wrote: post #9

Can someone explain what this patch actually does? I have an old Macbook Air with a malfunctioning sensor that cause the CPU to always run in powersaving mode (capped at 800 mhz), so it's basically unusable under OS X. I have walked around this issue by installing Linux which allows me to tune the CPU governor manually, and it uncaps the artificial limit that the malfunctioning sensor puts. Would this patch allow me…

You could try NullCPUPowerManagement.kext. It's used in the OS X x86 community to disable the built in Power management. If you don't mind getting your hands dirty you might be able to get it (or another related kext) to turn off frequency switching.

[1]http://www.osx86.net/downloads.php?do=file&id=16

Re: Hacking the OS X Kernel for Fun and Profiles

#26

Post by rsc »

mzs wrote: post #24

Cool, that was a bug, and not too difficult to fix and must have felt great when figured-out. But sometimes on darwin you run into stuff that just is so crufty in the BSD emulation, that it's better to use the mach stuff. In this case these class of routines: http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/task_sample.html

I don't think that has a way to get stacks. See http://research.swtch.com/pprof for why stacks are important.

Re: Hacking the OS X Kernel for Fun and Profiles

#27

Post by mzs »

rsc wrote: post #26
mzs wrote: post #24

Cool, that was a bug, and not too difficult to fix and must have felt great when figured-out. But sometimes on darwin you run into stuff that just is so crufty in the BSD emulation, that it's better to use the mach stuff. In this case these class of routines: http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/task_sample.html

I don't think that has a way to get stacks. See http://research.swtch.com/pprof for why stacks are important.

In that case another task using clock_alarm(), task_suspend(), task_resume(), and thread_get_state().

Re: Hacking the OS X Kernel for Fun and Profiles

#29

Post by asveikau »

klodolph wrote: post #13

> In order for the open file not to be inherited by the new program, we must introduce a new variant of open(2) that can open a file descriptor atomically marked "close on exec." This is incorrect, because you can prevent fds from getting inherited even without "close on exec". Simply list the files in /dev/fd and you'll see all the file descriptors your program has open, and then you can close all of the ones that t…

On some platforms there is a closefrom() call that will do this. (In *BSD it's a syscall, googling around it looks to be a library function on Solaris.) Best to use that if it's available, as hardcoding paths like /dev/fd or /proc/self/fd will not be portable. (Neither will closefrom() be really, but at least it's semantically clear what it does and you can bring-your-own one of those for platforms that lack it.)

Re: Hacking the OS X Kernel for Fun and Profiles

#30

Post by asveikau »

mikeash wrote: post #16
klodolph wrote: post #13

> In order for the open file not to be inherited by the new program, we must introduce a new variant of open(2) that can open a file descriptor atomically marked "close on exec." This is incorrect, because you can prevent fds from getting inherited even without "close on exec". Simply list the files in /dev/fd and you'll see all the file descriptors your program has open, and then you can close all of the ones that t…

Last time I checked on this, there was no safe way (i.e. using only async-signal-safe calls) to list the contents of /dev/fd post-fork. Did I miss something?

It's interesting that starting a new process in a signal handler is something you want to do. (I just searched and yes I understand fork() and exec() are spec'd by POSIX to be safe.) It seems like writing safe signal handlers is hard enough, making them multiprocess seems like a "now you have two problems" kind of thing.

I suppose if I am not mistaken you could go the pre-readdir() route and open a directory with open() and read it with read(). Probably a portability mess though.

Post reply on HN