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

11–20 of 38 posts

Re: Hacking the OS X Kernel for Fun and Profiles

#11

Post by lelf »

At least thanks apple for not stripping everything

  Betty:~ lelf$ dsymutil -s /mach_kernel |head
  ----------------------------------------------------------------------
  Symbol table for: '/mach_kernel' (x86_64)
  ----------------------------------------------------------------------
  Index    n_strx   n_type             n_sect n_desc n_value
  ======== -------- ------------------ ------ ------ ----------------
  [     0] 00000004 0f (     SECT EXT) 08     0000   ffffff800084e79c '.constructors_used'
  [     1] 00000017 0f (     SECT EXT) 08     0000   ffffff800084e7a4 '.destructors_used'
  [     2] 00000029 0f (     SECT EXT) 01     0000   ffffff80005241b0 '_AddFileExtent'
  [     3] 00000038 0f (     SECT EXT) 01     0000   ffffff800051ef40 '_AllocateNode'
  [     4] 00000046 0f (     SECT EXT) 01     0000   ffffff800021d510 '_Assert'

Re: Hacking the OS X Kernel for Fun and Profiles

#12

Post by tonyarkles »

endlessvoid94 wrote: post #3
f2f wrote: post #2

I'm afraid the title may scare people off the article. i assure you, "hacking" here is used in the canonical sense: "An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed."

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...

Re: Hacking the OS X Kernel for Fun and Profiles

#13

Post by klodolph »

> 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 the exec'd program won't need. The same thing is done on Linux with /proc/self/fd. The whole facility gets wrapped in a library function (not a standard library function, sadly) since there is a minor trick involved in getting this right.

The problem with close on exec is that libraries would have to be modified to ensure they mark descriptors as close-on-exec. The current system is admittedly arcane and non-portable, but it does work.

Re: Hacking the OS X Kernel for Fun and Profiles

#14

Post by janus »

mikeash wrote: post #10
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…

The patch fixes a bug with how the SIGPROF signal is delivered to a process, ensuring that it gets delivered to the proper thread rather than an arbitrary thread. It's unrelated to anything in the area of powersaving or clock speed throttling.

great, thanks for pointing it out.

Re: Hacking the OS X Kernel for Fun and Profiles

#15

Post by Someone »

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…

The patch? No, but the technique can be used to make any change to the kernel, as long as you don't need more bytes.

The change you want likely is such a change, as, to me, it looks like a 'replace an if by a NOP or a jump always' patch.

Re: Hacking the OS X Kernel for Fun and Profiles

#16

Post by mikeash »

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?

Re: Hacking the OS X Kernel for Fun and Profiles

#18

Post by klodolph »

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?

You can call functions that aren't async-signal-safe after a fork(). The standard library has prefork handlers that fire ensuring that you can e.g. opendir() safely after fork(), even if another thread was halfway through malloc() at the time of the fork.

Forking + threads is very messy, but it's not quite that pathological. I'd like to see an interface similar to posix_spawn() become the norm for spawning processes, with a fallback to fork()+exec() for more difficult use cases, but I don't think posix_spawn() is good enough.

Re: Hacking the OS X Kernel for Fun and Profiles

#19

Post by mikeash »

klodolph wrote: post #18
mikeash wrote: post #16

Earlier quoted context omitted.

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?

You can call functions that aren't async-signal-safe after a fork(). The standard library has prefork handlers that fire ensuring that you can e.g. opendir() safely after fork(), even if another thread was halfway through malloc() at the time of the fork. Forking + threads is very messy, but it's not quite that pathological. I'd like to see an interface similar to posix_spawn() become the norm for spawning processes,…

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 newly execed process what you really want to run. The new process can then do the /dev/fd listing in peace, then call exec again. Eww.

Re: Hacking the OS X Kernel for Fun and Profiles

#20

Post by klodolph »

mikeash wrote: post #19
klodolph wrote: post #18

Earlier quoted context omitted.

You can call functions that aren't async-signal-safe after a fork(). The standard library has prefork handlers that fire ensuring that you can e.g. opendir() safely after fork(), even if another thread was halfway through malloc() at the time of the fork. Forking + threads is very messy, but it's not quite that pathological. I'd like to see an interface similar to posix_spawn() become the norm for spawning processes,…

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.

Post reply on HN