28.08.2015 Views

The Design and Implementation of the Anykernel and Rump Kernels

1F3KDce

1F3KDce

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

176<br />

stdin/stdout, <strong>the</strong> new file descriptor numbers always signify <strong>the</strong> host kernel. To<br />

solve this conflict, we maintain a file descriptor aliasing table which keeps track <strong>of</strong><br />

cross-kernel dup2’s. <strong>The</strong>re are a number <strong>of</strong> details involved, such as making sure that<br />

closing <strong>the</strong> original fd does not close <strong>the</strong> dup2’d fd in <strong>the</strong> different kernel namespace,<br />

<strong>and</strong> making sure we do not return a host descriptor with a value duplicate to one in<br />

<strong>the</strong> dup2 space. In fact, a large portion <strong>of</strong> <strong>the</strong> code in <strong>the</strong> hijack library exists solely<br />

to deal with complexities related to dup2. All <strong>of</strong> <strong>the</strong> complexity is fully contained<br />

within <strong>the</strong> hijack <strong>and</strong> rumpclient libraries <strong>and</strong> it is not visible to applications using<br />

<strong>the</strong> libraries.<br />

Ano<strong>the</strong>r issue we must address is protecting <strong>the</strong> file descriptors used by rumpclient.<br />

Currently <strong>the</strong>y include <strong>the</strong> communication socket file descriptor <strong>and</strong> <strong>the</strong> kqueue<br />

descriptor which rumpclient uses for I/O multiplexing. Recall, <strong>the</strong> socket connection<br />

between <strong>the</strong> remote client <strong>and</strong> <strong>the</strong> rump kernel associates <strong>the</strong> remote client with a<br />

rump kernel process context, <strong>and</strong> if <strong>the</strong> connection is lost all process state such<br />

as file descriptors are lost with it. In some scenarios applications want to close file<br />

descriptors en masse. One example <strong>of</strong> such a scenario is when an application prepares<br />

to call exec(). <strong>The</strong>re are two approaches to mass closing: ei<strong>the</strong>r calling close() in a<br />

loop up to an arbitrary descriptor number or calling closefrom() (which essentially<br />

calls fcntl(F_DUPFD)). Since <strong>the</strong> application never sees <strong>the</strong> rumpclient internal file<br />

descriptors <strong>and</strong> hence should not close <strong>the</strong>m, we take precautions to prevent it from<br />

happening. <strong>The</strong> hijack library notifies rumpclient every time a descriptor is going<br />

to be closed. <strong>The</strong>re are two distinct cases:<br />

• A call closes an individual host descriptor. In addition to <strong>the</strong> obvious close()<br />

call, dup2() also belongs into this category. Here we inform rumpclient <strong>of</strong> a<br />

descriptor being closed <strong>and</strong> in case it is a rumpclient descriptor, it is dup’d<br />

to ano<strong>the</strong>r value, after which <strong>the</strong> hijack library can proceed to invalidate <strong>the</strong><br />

file descriptor by calling close or dup2.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!