{"id":945,"date":"2015-04-14T13:00:43","date_gmt":"2015-04-14T18:00:43","guid":{"rendered":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/?p=945"},"modified":"2015-04-14T07:08:57","modified_gmt":"2015-04-14T12:08:57","slug":"dynamic-software-updating","status":"publish","type":"post","link":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/","title":{"rendered":"Dynamic Software Updating: Linux 4.0 and Beyond"},"content":{"rendered":"

Last month,\u00a0Steven J. Vaughan-Nichols<\/a>\u00a0of\u00a0ZDNet alerted us\u00a0that Linux 4.0 will provide support for<\/a>\u00a0“no-reboot patching.<\/a>” The\u00a0gist: When a security patch or other critical OS update comes out, you\u00a0can apply it without rebooting<\/em>.<\/p>\n

While rebootless patching is convenient for everyone, it’s a game\u00a0changer for some applications. For example, web and\u00a0cloud hosting services normally require customers to experience some\u00a0downtime while the OS infrastructure is upgraded; with rebootless\u00a0patching, upgrades happen seamlessly. Or, imagine upgrades to systems\u00a0hosting in-memory databases: Right now, you\u00a0have to checkpoint the DB\u00a0to stable storage, stop the system, upgrade it, restart it, read the\u00a0data from stable storage, and restart service. Just the checkpointing\u00a0and re-reading from disk could take tens of minutes.\u00a0With rebootless patching, this disruption is\u00a0avoided; cf. Facebook’s usage of a modified memcached<\/a>\u00a0that supports preserving state across\u00a0updates.<\/p>\n

I’m particularly excited by this announcement because I’ve been working on the general problem of updating running software, which I call dynamic software updating<\/em> (DSU), for nearly 15 years. In this post, co-authored with\u00a0my PhD student\u00a0Lu\u00eds Pina<\/a>, I\u00a0take a closer look at the challenge that DSU presents, showing that what Linux will support is still quite far from\u00a0what we might hope for, but\u00a0that\u00a0ideas from the research community promise\u00a0to get us closer to the ideal, both for operating systems and hopefully for many other applications as well.<\/p>\n

<\/p>\n

Dynamic software updating: What is it?<\/h2>\n

We have all experienced normal, or static<\/em>, software updates: Download the new code, stop the affected program if it’s running, apply the patch, and restart the program. What makes dynamic<\/em>\u00a0software updates different is that they avoid the stop-and-restart part by also updating the running program’s execution state<\/em>. This state consists of data<\/em>, like linked tree and list structures that store our in-memory database, and control<\/em>, like the execution stacks of active threads. The program code assumes the state adheres to a certain format and invariants, and therefore changing the code at run-time<\/em>\u00a0requires changing the execution state appropriately.<\/p>\n

\"dsu-process.001\"<\/a>

Dynamic Software Updating<\/p><\/div>\n

Consider an example. If in the updated program the entries of a hash table are extended with a timeout field, then a dynamic update needs to convert in-memory hashtable entries to now contain a timeout field; otherwise, when the updated code goes to access that field, it will behave unpredictably. Or, if the new code uses two threads to perform some functionality which in the old version requires only one thread, then we need to map the existing thread’s stack to an equivalent one for the new code, and start a new thread to handle the extracted functionality. Changes to in-memory data, like the first example, we call data migrations<\/em>, while changes to control, like the second example, we call control migrations<\/em>.<\/p>\n

Rebootless patching\u00a0in Linux 4.0<\/h2>\n

The rebootless patching\u00a0support\u00a0in\u00a0Linux 4.0 is the descendant of two existing proposals, kpatch<\/a>\u00a0(from RedHat) and kGraft<\/a>\u00a0(from SUSE).[ref]The new live kernel patching support that Linux 4.0 introduces is a common core from kpatch and kGraft. The new API allows modules that contain patches to be loaded, listed, and removed. It also performs the low-level redirection to replace patched functions. It still remains to bring in some kind of safety checking, as kpatch and kGraft differ on this.[\/ref]\u00a0These two descend from earlier research<\/a>, by Jeff Arnold and Frans Kaashoek,\u00a0on a solution called Ksplice<\/a>, which was bought by Oracle in\u00a02011<\/a>.<\/p>\n

These solutions focus on dynamic changes to code. The basic approach to dynamically updating a function f<\/strong> is to overwrite the\u00a0first few instructions of the current\u00a0f<\/strong> to jump to its new version. This approach has the benefit that any references to f<\/strong> elsewhere in the code or data (i.e., as function pointers) will still work.<\/p>\n

Activeness checking in kpatch<\/h3>\n

Function f<\/strong> cannot be running when this change takes place, for obvious reasons.\u00a0Kpatch additionally requires that changed functions are not active<\/em>, meaning they are not referenced by any process’s call stack at the time of an update (which it checks after pausing all processes). Why is this useful? The assumption is that the control state of the old and new kernel will be the same when no changed functions are active. As such, delaying the update until this condition is satisfied means\u00a0the control state of the running kernel is valid for the new code. This makes it easier on the programmer.<\/p>\n

Unfortunately, this assumption fails to account for the effects<\/em>\u00a0of prior execution of changed functions on the program’s data, even if the role of that data is the same between versions. Consider the following example (distilled from our prior work on dynamically updating OpenSSH daemons<\/a>):<\/p>\n

Old version:<\/p>\n

\r\nvoid go() {\r\n  setup(); \/* update here *\/\r\n  handle();\r\n}\r\nvoid setup() {\r\n}\r\nvoid handle() {\r\n  global_ptr = init;\r\n  x = (*global_ptr).field;\r\n}\r\n<\/pre>\n
New version:<\/p>\n
\r\nvoid setup() {\r\n  global_ptr = init;\r\n}\r\nvoid handle() {\r\n  x = (*global_ptr).field;\r\n}\r\n<\/pre>\n
Consider that a process is executing function go<\/strong>, which was not patched, right after function setup<\/strong>\u00a0returned and before calling function handle<\/strong>. This means that the old version of function setup<\/strong>\u00a0ran, which did not set the variable global_ptr<\/strong>. But after the update, the new version of function handle<\/strong>\u00a0will execute, which will dereference the global variable and crash. A research study we did found that kpatch-style\u00a0activeness checking<\/em>\u00a0is not sufficient<\/a> to ensure that the control and data state is correct, and moreover can be quite restrictive.<\/p>\n
Multi-version execution in kGraft<\/h3>\n
KGraft tries to address this problem by ensuring version consistency<\/em><\/a>. That is, when performing a system call, the kernel either executes old code or new code, but not a mix of both. KGraft enforces version consistency on a per-process basis, so it is possible for\u00a0one process to execute the new\u00a0code while another process executes the old code. When a process makes a system call after the patch is installed, kGraft sets a “new universe” flag on that process. From that point on, that process will always use the patched code. KGraft uses an extra level of indirection called a “reality-check” to decide, at the entry of patched functions, which code to execute based on the process flag. Once the flag is set on all processes, kGraft drops the now-redundant indirection and jumps straight to the patched code.<\/p>\n
The problem with multi-version execution is that processes running two different code versions could interact, e.g., through common data structures, and thereby potentially violate new (or outdated) invariants.\u00a0This problem would be particularly acute if the old and new version changed a data structure’s format.[ref]The multi-version execution\u00a0approach\u00a0was considered, for process-level dynamic updates, by\u00a0the POLUS<\/a> dynamic updating system.[\/ref]<\/p>\n
(Lack of) data updates<\/h3>\n
None of\u00a0these kernel live-patching mechanisms support updating data, at least not fully or\u00a0easily. Ksplice proposed updating data using shadow data-structures<\/em><\/a> (based on DynAMOS<\/a>\u00a0by Makris and Ryu). Given that the original data-structure has no space for new fields, the idea is to create a separate data-structure just for them and rewrite the original binary code to use the new structure when manipulating the new fields. This approach, however, introduces a lot of complexity (and opportunities for bugs) as the code is maintained and patched further, going ahead.<\/p>\n
Full-featured DSU<\/h2>\n
Linux 4.0 DSU support is a far cry from supporting Vaughan-Nichols’ hope\u00a0that\u00a0“With Linux 4.0, you may never need to reboot your operating system again:<\/em>” it is simply not flexible enough. The\u00a0goal of DSU is to avoid stops-and-restarts; thus, ideally, any<\/em>\u00a0updates to a program we can make statically we can also make dynamically. I.e., we should be able to add new functions, change function types (e.g., to have new or different arguments), or modify data structures, e.g., by adding new data elements, breaking apart or changing the types of existing elements, adding and removing pointers, etc. But\u00a0Linux 4.0’s rebootless patching support limits\u00a0flexibility for the sake of better performance, backward-compatibility, and ease of use by the kernel programmer, even though the latter is not quite satisfying, as we have discussed: ironically, a “rebootless patch” could result in a crash, defeating the point!<\/p>\n
The research community has been looking at how to support highly-flexible DSU for many years now.[ref]Good DSU surveys include\u00a0Segal and Frieder’s 1993 paper<\/a>, Ajmani’s 2002 survey<\/a>, and the related work of the Kitsune journal paper<\/a>.[\/ref] We\u00a0view\u00a0whole-process DSU<\/em>, pioneered by Makris and Bazzi’s\u00a0UpStare<\/a> system, as the most promising approach for user-space programs, owing to its flexibility. In this approach, the entirety of the new code is loaded into the memory of the running process and then control and data migrations directly update the execution state prior to, or even in conjunction with, subsequent execution that code.<\/p>\n
Kitsune and Rubah<\/h3>\n
We have developed two systems that take the whole-process approach:\u00a0Kitsune<\/a>, for C programs, and Rubah<\/a>, for Java programs.\u00a0Both systems are flexible enough to dynamically apply years’ worth of release-level updates, and they have been used to dynamically update substantial applications such as\u00a0redis<\/a>, memcached<\/a>, snort<\/a>,\u00a0H2<\/a>, and Voldemort<\/a>.\u00a0Besides their flexibility, these systems do not impose any measurable overhead on normal execution. This is because the whole-process approach allows the code to be fully optimized internally\u00a0\u2014\u00a0such optimizations would be inhibited by added levels of indirection (like trampolines) and spatial non-locality common in per-function updating approaches.[ref]Note that Upstare imposes substantial execution overhead because it compiles the program specially to perform stack re-winding, for control migration; Kitsune and Rubah favor programmer-provided support, which turns out to be much<\/em> more efficient.[\/ref]<\/p>\n
The downside of both approaches is additional programmer work in supporting both control and data migration.<\/p>\n
First, they require the programmer to add update points<\/em> to the program. These are points at which the program polls to see whether a dynamic update is available, and if so will start applying it. Programs typically have only a handful of update points, and they are naturally placed at the start of long-running loops, when invariants are established and\/or events have been fully handled.<\/p>\n
Second, the programmer must define state transformation functions<\/em>\u00a0which indicate how data from an old version of a type\/class should be used to initialize the updated version. For example, the state transformer might provide the default value for a new field. Fortunately, the process of finding and updating updated data values is automated. Kitsune updates all data at once, using a garbage collector-style mechanism. Rubah can do likewise, but also supports on-the-fly data migration, updating each outdated object when the new code first accesses it after the update. Both systems provide simple automation for writing state transformers, too, but sometimes the programmer needs to get involved.<\/p>\n
Third, the programmer must modify the program to support control-flow migration<\/em> between versions. Kitsune and Rubah start running the new program from the equivalent threads’ entry points (after data is migrated, or initiated in the on-the-flly case). To avoid re-running initialization code, the program can skip it, conditioned on being in updating mode<\/em>; this mode is disabled once the equivalent update point is reached in the new program.\u00a0We find that making control migration\u00a0changes to the program is relatively simple because update points tend to be shallow in the control flow graph, and initialization code is often skipped en masse<\/em>. For example, redis required only 2 extra LOC, and memcached required 9 LOC. Even better, this code rarely changes, so it is basically a one-time effort, rather than a per-update effort.<\/p>\n
In the end, this work amounts to only hundreds of lines of code (compared to tens or hundreds of thousands of lines in an application), and much of the work is done once. And the benefit is full-featured dynamic updates with excellent performance.<\/p>\n
What’s next?<\/h2>\n
Is it possible to apply the techniques from whole-process DSU to the OS kernel? One possibility is to apply\u00a0“whole-virtual machine” updates\u2014virtual machines are to virtual machine monitors (VMMs) what processes are to operating systems. Indeed, a recent criticism of the Linux 4.0 DSU support<\/a>\u00a0points to this direction: “Rather than trying to patch a running kernel …, why not just save the entire state of the system, boot into an entirely new kernel, then restore the previous state on top of the new kernel?”<\/p>\n
The idea of non-stop operation is appealing outside of standalone user programs and OS kernels. What about updating elements of a distributed system in a way that the communication protocol is changed? Or, what about updating the schema and contents of a database (so-called “schema migration”) while migrating the applications that use it (e.g., and avoid the 22 hour downtime experienced by Mediawiki<\/a>)? We can also imagine updating cloud-based web applications\u2014the updates can be pushed silently to the users even while the applications are in use. All of these changes would facilitate more ready application of functionality or performance improvements, and of security fixes. Once you realize that dynamic updates are not that different from static ones\u2014they just require a little more work to update the execution state\u2014you realize that the benefit of non-stop operation is\u00a0very much within reach.<\/p>\n","protected":false},"excerpt":{"rendered":"
Last month,\u00a0Steven J. Vaughan-Nichols\u00a0of\u00a0ZDNet alerted us\u00a0that Linux 4.0 will provide support for\u00a0“no-reboot patching.” The\u00a0gist: When a security patch or other critical OS update comes out, you\u00a0can apply it without rebooting. While rebootless patching is convenient for everyone, it’s a game\u00a0changer … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[49,85],"tags":[92,86,91,89,88,87,90],"class_list":["post-945","post","type-post","status-publish","format-standard","hentry","category-research","category-systems","tag-dsu","tag-dynamic-software-updating","tag-kitsune","tag-linux","tag-live-upgrades","tag-rebootless-patches","tag-rubah"],"yoast_head":"\nDynamic Software Updating: Linux 4.0 and Beyond - The PL Enthusiast<\/title>\n<meta name=\"description\" content=\"Spurred by the announcement of rebootless patch support in Linux 4.0, this article considers the path toward making dynamic software updating mainstream.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Dynamic Software Updating: Linux 4.0 and Beyond - The PL Enthusiast\" \/>\n<meta property=\"og:description\" content=\"Spurred by the announcement of rebootless patch support in Linux 4.0, this article considers the path toward making dynamic software updating mainstream.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/\" \/>\n<meta property=\"og:site_name\" content=\"The Programming Languages Enthusiast\" \/>\n<meta property=\"article:published_time\" content=\"2015-04-14T18:00:43+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-content\/uploads\/2015\/04\/dsu-process.001-e1428872727250-300x109.jpg\" \/>\n<meta name=\"author\" content=\"Michael Hicks\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Michael Hicks\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2015\\\/04\\\/14\\\/dynamic-software-updating\\\/#article\",\"isPartOf\":{\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2015\\\/04\\\/14\\\/dynamic-software-updating\\\/\"},\"author\":{\"name\":\"Michael Hicks\",\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/#\\\/schema\\\/person\\\/7d875a015cb2e83e9cd476df91028d5d\"},\"headline\":\"Dynamic Software Updating: Linux 4.0 and Beyond\",\"datePublished\":\"2015-04-14T18:00:43+00:00\",\"mainEntityOfPage\":{\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2015\\\/04\\\/14\\\/dynamic-software-updating\\\/\"},\"wordCount\":2213,\"commentCount\":7,\"image\":{\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2015\\\/04\\\/14\\\/dynamic-software-updating\\\/#primaryimage\"},\"thumbnailUrl\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/wp-content\\\/uploads\\\/2015\\\/04\\\/dsu-process.001-e1428872727250-300x109.jpg\",\"keywords\":[\"DSU\",\"dynamic software updating\",\"Kitsune\",\"Linux\",\"live upgrades\",\"rebootless patches\",\"Rubah\"],\"articleSection\":[\"Research\",\"Systems\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"http:\\\/\\\/www.pl-enthusiast.net\\\/2015\\\/04\\\/14\\\/dynamic-software-updating\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2015\\\/04\\\/14\\\/dynamic-software-updating\\\/\",\"url\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2015\\\/04\\\/14\\\/dynamic-software-updating\\\/\",\"name\":\"Dynamic Software Updating: Linux 4.0 and Beyond - The PL Enthusiast\",\"isPartOf\":{\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2015\\\/04\\\/14\\\/dynamic-software-updating\\\/#primaryimage\"},\"image\":{\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2015\\\/04\\\/14\\\/dynamic-software-updating\\\/#primaryimage\"},\"thumbnailUrl\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/wp-content\\\/uploads\\\/2015\\\/04\\\/dsu-process.001-e1428872727250-300x109.jpg\",\"datePublished\":\"2015-04-14T18:00:43+00:00\",\"author\":{\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/#\\\/schema\\\/person\\\/7d875a015cb2e83e9cd476df91028d5d\"},\"description\":\"Spurred by the announcement of rebootless patch support in Linux 4.0, this article considers the path toward making dynamic software updating mainstream.\",\"breadcrumb\":{\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2015\\\/04\\\/14\\\/dynamic-software-updating\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"http:\\\/\\\/www.pl-enthusiast.net\\\/2015\\\/04\\\/14\\\/dynamic-software-updating\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2015\\\/04\\\/14\\\/dynamic-software-updating\\\/#primaryimage\",\"url\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/wp-content\\\/uploads\\\/2015\\\/04\\\/dsu-process.001-e1428872727250.jpg\",\"contentUrl\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/wp-content\\\/uploads\\\/2015\\\/04\\\/dsu-process.001-e1428872727250.jpg\",\"width\":744,\"height\":271},{\"@type\":\"BreadcrumbList\",\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/2015\\\/04\\\/14\\\/dynamic-software-updating\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Dynamic Software Updating: Linux 4.0 and Beyond\"}]},{\"@type\":\"WebSite\",\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/#website\",\"url\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/\",\"name\":\"The Programming Languages Enthusiast\",\"description\":\"Developments in PL, and why they matter\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/#\\\/schema\\\/person\\\/7d875a015cb2e83e9cd476df91028d5d\",\"name\":\"Michael Hicks\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/dd0371ad9a0cb821df683b5d6a6cccc911e6e2af1778f28b77e8c90b0c319d14?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/dd0371ad9a0cb821df683b5d6a6cccc911e6e2af1778f28b77e8c90b0c319d14?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/dd0371ad9a0cb821df683b5d6a6cccc911e6e2af1778f28b77e8c90b0c319d14?s=96&d=mm&r=g\",\"caption\":\"Michael Hicks\"},\"sameAs\":[\"http:\\\/\\\/www.cs.umd.edu\\\/~mwh\\\/\"],\"url\":\"http:\\\/\\\/www.pl-enthusiast.net\\\/author\\\/mwh\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Dynamic Software Updating: Linux 4.0 and Beyond - The PL Enthusiast","description":"Spurred by the announcement of rebootless patch support in Linux 4.0, this article considers the path toward making dynamic software updating mainstream.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/","og_locale":"en_US","og_type":"article","og_title":"Dynamic Software Updating: Linux 4.0 and Beyond - The PL Enthusiast","og_description":"Spurred by the announcement of rebootless patch support in Linux 4.0, this article considers the path toward making dynamic software updating mainstream.","og_url":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/","og_site_name":"The Programming Languages Enthusiast","article_published_time":"2015-04-14T18:00:43+00:00","og_image":[{"url":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-content\/uploads\/2015\/04\/dsu-process.001-e1428872727250-300x109.jpg","type":"","width":"","height":""}],"author":"Michael Hicks","twitter_misc":{"Written by":"Michael Hicks","Est. reading time":"11 minutes"},"schema":{"@context":"https:\/\/fd.xuwubk.eu.org:443\/https\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/#article","isPartOf":{"@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/"},"author":{"name":"Michael Hicks","@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/#\/schema\/person\/7d875a015cb2e83e9cd476df91028d5d"},"headline":"Dynamic Software Updating: Linux 4.0 and Beyond","datePublished":"2015-04-14T18:00:43+00:00","mainEntityOfPage":{"@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/"},"wordCount":2213,"commentCount":7,"image":{"@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/#primaryimage"},"thumbnailUrl":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-content\/uploads\/2015\/04\/dsu-process.001-e1428872727250-300x109.jpg","keywords":["DSU","dynamic software updating","Kitsune","Linux","live upgrades","rebootless patches","Rubah"],"articleSection":["Research","Systems"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/","url":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/","name":"Dynamic Software Updating: Linux 4.0 and Beyond - The PL Enthusiast","isPartOf":{"@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/#website"},"primaryImageOfPage":{"@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/#primaryimage"},"image":{"@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/#primaryimage"},"thumbnailUrl":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-content\/uploads\/2015\/04\/dsu-process.001-e1428872727250-300x109.jpg","datePublished":"2015-04-14T18:00:43+00:00","author":{"@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/#\/schema\/person\/7d875a015cb2e83e9cd476df91028d5d"},"description":"Spurred by the announcement of rebootless patch support in Linux 4.0, this article considers the path toward making dynamic software updating mainstream.","breadcrumb":{"@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/#primaryimage","url":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-content\/uploads\/2015\/04\/dsu-process.001-e1428872727250.jpg","contentUrl":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-content\/uploads\/2015\/04\/dsu-process.001-e1428872727250.jpg","width":744,"height":271},{"@type":"BreadcrumbList","@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/2015\/04\/14\/dynamic-software-updating\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/"},{"@type":"ListItem","position":2,"name":"Dynamic Software Updating: Linux 4.0 and Beyond"}]},{"@type":"WebSite","@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/#website","url":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/","name":"The Programming Languages Enthusiast","description":"Developments in PL, and why they matter","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/#\/schema\/person\/7d875a015cb2e83e9cd476df91028d5d","name":"Michael Hicks","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/fd.xuwubk.eu.org:443\/https\/secure.gravatar.com\/avatar\/dd0371ad9a0cb821df683b5d6a6cccc911e6e2af1778f28b77e8c90b0c319d14?s=96&d=mm&r=g","url":"https:\/\/fd.xuwubk.eu.org:443\/https\/secure.gravatar.com\/avatar\/dd0371ad9a0cb821df683b5d6a6cccc911e6e2af1778f28b77e8c90b0c319d14?s=96&d=mm&r=g","contentUrl":"https:\/\/fd.xuwubk.eu.org:443\/https\/secure.gravatar.com\/avatar\/dd0371ad9a0cb821df683b5d6a6cccc911e6e2af1778f28b77e8c90b0c319d14?s=96&d=mm&r=g","caption":"Michael Hicks"},"sameAs":["https:\/\/fd.xuwubk.eu.org:443\/http\/www.cs.umd.edu\/~mwh\/"],"url":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/author\/mwh\/"}]}},"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/posts\/945","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/comments?post=945"}],"version-history":[{"count":11,"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/posts\/945\/revisions"}],"predecessor-version":[{"id":973,"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/posts\/945\/revisions\/973"}],"wp:attachment":[{"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/media?parent=945"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/categories?post=945"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fd.xuwubk.eu.org:443\/http\/www.pl-enthusiast.net\/wp-json\/wp\/v2\/tags?post=945"}],"curies":[{"name":"wp","href":"https:\/\/fd.xuwubk.eu.org:443\/https\/api.w.org\/{rel}","templated":true}]}}