OpenBSD Journal

Kernel syspatches will soon be smaller thanks to KARL

Contributed by pitrh on from the KARL kranks kernel kode krunch dept.

It almost went unnoticed due to the 6.2-beta announcement, but Antoine Jacoutot (ajacoutot@) just commited a very useful update to syspatch. In this commit, the groundwork is done for having syspatch update only the kernel object files that have changed. Due to KARL, the scheme to relink the kernel for each reboot, it makes sense to save space and bandwidth that way.

The commit message reads: 

CVSROOT:	/cvs
Module name:	src
Changes by:	ajacoutot@cvs.openbsd.org	2017/08/21 02:45:38

Modified files:
	distrib/syspatch: bsd.syspatch.mk 

Log message:
Kernel syspatches will now only contain the differing object files.
The syspatch(8) utility will be modified accordingly to relink the kernel at the
end of its run (not done yet, still WIP). That will give us KARL and much
smaller patches.

Idea from deraadt@
OK robert@

The kernel relinking as part of syspatch is still a work in progress, but we really look forward to seeing this in action!

(Comments are closed)

Comments

  1. By Anonymous Coward (2620:149:4:302:286b:599b:616a:f67b) on

    Hopefully syspatch will support the systems that opted out from relinking the kernel each reboot

    Comments

    1. By Paul 'WEiRD' de Weerd (weerd) weerd@weirdnet.nl on https://beta.undeadly.org

      That's interesting. Why would you want to opt out? But more importantly: how did you opt out?

      To install a syspatch kernel update, you need to install a new kernel, which syspatch will build for you (in a random order). So, I guess, it depends on how you opted out.

      Comments

      1. By Anonymous Coward (82.68.199.128) on

        It will need relinking to get the syspatch update, but wouldn't specifically need relink at every boot. Because boot-time relinking is part of the standard os distribution, whatever you do to disable it will need to handle this.

      2. By Anonymous Coward (2620:149:4:302:3186:6868:b9ee:4e72) on

        quoting to Theo's email [1]:

        This mechanism is incompatible with the current workings of unhibernate,
        but I working on a solution for that, so if you use -current, don't expect
        unhibernate to work. You can disable the mechanism using
        echo no > /usr/share/compile/GENER*/SHA256
        but we all love security so why would you do that.

        Although I am not 100% certain this is still supported

        1: https://marc.info/?l=openbsd-tech&m=149732026405941

  2. By Zimmie (63.241.252.2) on

    Excellent! The batch of updates in early August was kind of goofy. My system downloaded the kernel eleven times, when I'm pretty sure only the most recent was strictly needed.

  3. By d.c. (109.107.215.223) on

    Is there a way to tell syspatch which sets are needed? I don't like to have x* installed on my servers, so that syspatch always tries to offer me "007_freetype" (and to skip it then).

    KARL looks interesting :)

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]