Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Contributor: CovertBotNews - Removing All Syscall Invocations from Kernel Space
#1
Removing All Syscall Invocations from Kernel Space

<div data-history-node-id="1339900" class="layout layout--onecol">
<div class="layout__region layout__region--content">

<div class="field field--name-field-node-image field--type-image field--label-hidden field--item"> <img src="https://www.linuxjournal.com/sites/default/files/nodeimage/story/bigstock-Abstract-Vector-Technology-Equ-238938232.jpg" width="491" height="600" alt="""" typeof="foaf:Image" class="img-responsive" /></div>

<div class="field field--name-node-author field--type-ds field--label-hidden field--item">by <a title="View user profile." href="https://www.linuxjournal.com/users/zack-brown" lang="" about="https://www.linuxjournal.com/users/zack-brown" typeof="schemaTongueerson" property="schema:name" datatype="" xml:lang="">Zack Brown</a></div>

<div class="field field--name-body field--type-text-with-summary field--label-hidden field--item"><p>
There's an effort under way to reduce and ultimately remove all system call
invocations from within kernel space. <strong>Dominik Brodowski</strong> was leading this
effort, and he posted some patches to remove a lot of instances from the
kernel. Among other things, he said, these patches would make it easier to
clean up and optimize the <strong>syscall</strong> entry points, and also
easier to clean up the
parts of the kernel that still needed to pretend to be in userspace, just
so they could keep using syscalls.
</p>

<p>
The rationale behind these patches, as expressed by <strong>Andy
Lutomirski</strong>,
ultimately was to prevent user code from ever gaining access to kernel memory.
Sharing syscalls between kernel space and user space made that impossible
at the moment. Andy hoped the patches would go into the kernel quickly,
without needing to wait for further cleanup.
</p>

<p>
<strong>Linus Torvalds</strong> had absolutely no criticism of these patches,
and he indicated
that this was a well desired change. He offered to do a little extra
housekeeping himself with the kernel release schedule to make Dominik's
tasks easier. Linus also agreed with Andy that any cleanup effort could
wait—he didn't mind accepting ugly patches to update the syscall calling
conventions first, and then accept the cleanup patches later.
</p>

<p>
<strong>Ingo Molnar</strong> predicted that with Dominik's changes, the size of the compiled
kernel would decrease—always a good thing. But Dominik said no, and in
fact
he ran some quick numbers for Ingo and found that with his patches, the
compiled kernel was actually a few bytes larger. Ingo was surprised but not
mortified, saying the slight size increase would not be a showstopper.
</p>

<p>
This project is similar—although maybe smaller in scope—to the effort
to get rid of the <strong>big kernel lock</strong> (BKL). In the case of the BKL, no one
could figure out for years even how to begin to replace it, until finally
folks decided to convert all BKL instances into identical local
implementations that could be replaced piecemeal with more specialized and
less heavyweight locks. After that, it was just a question of slogging
through each one until finally even the most finicky instances were
replaced with more specialized locking code.
</p>

<p>
Dominik seems to be using a similar technique now, in which areas of the
kernel that still need syscalls can masquerade as user space, while areas
of the kernel that are easier to fix get cleaned up first.
</p>

<p><em>Note: if you're mentioned above and want to post a response above the comment section, send a message with your response text to ljeditor@linuxjournal.com.</em></p></div>

<div class="field field--name-node-link field--type-ds field--label-hidden field--item"> <a href="https://www.linuxjournal.com/content/removing-all-syscall-invocations-kernel-space" hreflang="en">Go to Full Article</a>
</div>

</div>
</div>




https://www.linuxjournal.com/content/rem...rnel-space
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)