A maintenance release (now at version 0.2.5) of my gcbd package (described only in these two posts) is now CRAN. More details about the package are available in the paper which is also included in the gcbd R package. Changes were minimal and driven mostly by some CRAN Policy changes which now prefer vignette sources files in (top-level) directory vignettes/ Courtesy of CRANberries, there is also a diffstat report for the most recent release.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

So SteamOS has been released. While that's marginally interesting in and as of itself, there are two observations to be made:

1. Microsoft, Nintendo, and Sony will feel an impact. More functionality on cheaper hardware which can easily by upgraded; I bet quite a few managers are not happy, at the moment.
2. While the stand-alone Linux Steam client was initially targeted at Ubuntu, SteamOS is based on Debian Wheezy.

Actual Linux (not Android) for the end user The first one means more Linux installations. In the living room. On a machine that children are really focussed on and will want to play with, quite literally. The next logical step is for people who play games to install SteamOS on their other machines; desktops, laptops, everywhere they want to game. This could really be the tipping point where the average adolescent computer enthusiast does not need to reboot into Linux to fool around with, but the other way round: To need to boot to Windows for a few select legacy applications which don't run on the FLOSS variant of Wine like Office or Photoshop. And once this momentum starts to shift, other software vendors will follow the money trail. Could 2014 finally be.... the year of Linux on the desktop...? Debian vs Debian-based The latter one is also really interesting... Obviously, I don't know why Valve decided to go down this road, but there are several reasons which come to mind:

• No need for the extra bloat
• They wanted to avoid the tie-in with another for-profit entity
• Unhappiness with some technical decisions made by UbuntuCanonical
• Lack of faith in the long-term governance of Ubuntu

What we are left with is a major player entering the ring of Linux for end-users and choosing Debian over Ubuntu. Hopefully, improvements to the base system will be fed back upstream, enabling all Debian-based distributions to profit easily, not only Ubuntu-based ones. I am willing to bet that two years ago, SteamOS would have been based on Ubuntu, not Debian. Recently, there's been a lot of backlash over various decisions which Canonical forced onto Ubuntu and it will be interesting to see how this plays out in the long run... I will be interesting to see how much pain Linux Mint and Kubuntu will endure. Forecast Users All in all, we are looking at a massive influx of new users into the Debian ecosystem. How massive? 65 million registered users massive. 7 million concurrent users at once, 1.2 million users actively playing the top 100 games at the same time massive. This is huge. Contributors In time, a substantial part of that userbase will switch over one or more of their machines over to SteamOS. The tinkerers among them will realize they can install plain Debian and install Steam as a package. The hackers among those will start to improve upon their systems; and what better way to do that then to go upstream? If even a tiny fraction of users makes it this far, the count of actively involved contributors with Debian will skyrocket if we let them join. Raspbian and some other not-quite-ideal decisions come to mind. Vendors Commercial software vendors need to stay profitable. Thus, they are forced to support distributions which promise enough paying users. In the past, this meant mainly SuSE and Red Hat; they had commercial backers, went through certifications, etc. In the recent past, this also meant Ubuntu. All of a sudden, Debian stable has a potential market of tens of millions of average computer users and computer enthusiasts. A lot of whom will want to continue to use their OS of choice at work, as well. Oh boy...

I attended the 1st Debian mokumoku meeting. mokumoku ( ) means silently and concentrativeness in Japan. There were about 6 people in a room. I tried to prepare release of Namazu and KAKASI.

This morning when preparing the update of a package, and I saw a PNG file in its documentation. Even before opening it, I felt old, tired, distressed and unable to escape the situation. Inspecting the file confirmed that the image was not hand made. The source file is missing. The proof: anther image in the same directory has the same style and a SVG source. To make things worse, there are no instructions on how to generate the PNG from the SVG. More and more in these cases, I give up and abandon the package. I lost time and energy make Upstream some requirements for which I personally have no concrete interest. SVG in addition to PNG is better, but PNG alone for the documentation of a Free software is Free enough for me. However, the points of view expressed on debian-devel give me the impression that it is not good enough for Debian, so I just give up

Tuesday was a really nice evening. A few weeks ago I found a poster about the concert of [dunkelbunt], and got my ticket only on monday. I was told by the ticket sellers that they still have plenty left. In the end when I turned up at the event at tuesday though the concert hall was fully packed with people and I was told that it actually was sold out. There wasn't much place inside the hall left, so I mostly stood in the doorway to the bar area and enjoyed the music from there. If you listen to their songs you might get an idea why the music catched me and I started to let the music move my body, literally. It's a great feeling after a tough day, and there were some other nice people around which let the same happen to them so it did feel less awkward for me. Anyway, if you want to find out if their music can do the same to you, here are some songs to listen to:

• The Chocolate Butterfly: This was actually the first song that got me interested in them which was playing on a local radio station.
• Cinnamon Girl: One of the reasons why [dunkelbunt] is put into the electro swing genre. :)
• Schlawiener: The title is a pun, a mix between "Schlawiner" (smooth operator) and "Wiener" (Viennese).

Enjoy!

/music permanent link Comments: 1 Flattr this

Cleaning up X server warnings So I was sitting in the Narita airport with a couple of other free software developers merging X server patches. One of the developers was looking over my shoulder while the X server was building and casually commented on the number of warnings generated by the compiler. I felt like I had invited someone into my house without cleaning for months embarrassed and ashamed that we d let the code devolve into this state. Of course, we ve got excuses the X server code base is one of the oldest pieces of regularly used free software in existence. It was started before ANSI-C was codified. No function prototypes, no const , no void * , no enums or stdint.h. There may be a few developers out there who remember those days (fondly, of course), but I think most of us are glad that our favorite systems language has gained a lot of compile-time checking in the last 25 years. We ve spent time in the past adding function prototypes and cleaning up other warnings, but there was never a point at which the X server compiled without any warnings. More recently, we ve added a pile of new warning flags when compiling the X server which only served to increase the number of warnings dramatically. The current situation With the master branch of the X server and released versions of the dependencies, we generate 1047 warnings in the default build. -Wcast-qual considered chatty The GCC flag, -Wcast-qual, complains when you cast a pointer and change the const qualifier status. A very common thing for the X server to do is declare pointers as const to mark them as immutable once assigned. Often, the relevant data is actually constructed once at startup in allocated memory and stored to the data structure. During server reset, that needs to be freed, but free doesn t take a const pointer, so we cast to (void *), which -Wcast-qual then complains about. Loudly. Of the 1047 warnings, 380 of them are generated by this one warning flag. I ve gone ahead and just disabled it in util/macros for now. String constants are a pain The X server uses string constants to initialize defaults for font paths, configuration options, font names along with a host of other things. These end up getting stored in variables that can also take allocated storage. I ve gone ahead and declared the relevant objects as const and then fixed the code to suit. I don t have a count of the number of warnings these changes fixed; they were scattered across dozens of X server directories, and I was fixing one directory at a time, but probably more than half of the remaining warnings were of this form. And a host of other warnings Fixing the rest of the warnings was mostly a matter of stepping through them one at a time and actually adjusting the code. Shadowed declarations, unused values, redundant declarations and missing printf attributes were probably the bulk of them though. Changes to external modules Instead of just hacking the X server code, I ve created patches for other modules where necessary to fix the problems in the right place.

• proto/fontsproto. Declares FontPathElement names as const char *
• mesa/drm. Adds printf attribute to the debug_print function
• util/macros. Removes -Wcast-qual from the default warning set.

Getting the bits In case it wasn t clear, the X server build now generates zero warnings on my machine. I m hoping that this will also be true for other people. Patches are available at:

xserver - git://people.freedesktop.org/~keithp/xserver warning-fixes
fontsproto - git://people.freedesktop.org/~keithp/fontsproto fontsproto-next
mesa/drm - git://people.freedesktop.org/~keithp/drm warning-fixes
util/macros - already upstream on master

Keeping our house clean Of course, these patches are all waiting until 1.15 ships so that we don t accidentally break something important. However, once they re merged, I ll be bouncing any patches which generate warnings on my system, and if other people find warnings when they build, I ll expect them to send patches as well. Now to go collect the tea cups in my office and get them washed along with the breakfast dishes so I won t be embarrassed if some free software developers show up for lunch today.

Fingerprints and Key IDsOpenPGPv4 fingerprints are made from an SHA-1 digest over the key's public key material, creation date, and some boilerplate. SHA-1 digests are 160 bits in length. The "long key ID" of a key is the last 64 bits of the key's fingerprint. The "short key ID" of a key is the last 32 bits of the key's fingerprint. You can see both of the key IDs as a hash in and of themselves, as "32-bit truncated SHA-1" is a sort of hash (albeit not a cryptographically secure one). I'm arguing here that short Key IDs and long Key IDs are actually useless, and we should stop using them entirely where we can do so. We certainly should not be exposing normal human users to them. (Note that I am not arguing that OpenPGP v4 fingerprints themselves are cryptographically insecure. I do not believe that there are any serious cryptographic risks currently associated with OpenPGP v4 fingerprints. This post is about Key IDs specifically, not fingerprints.)Key IDs have serious problemsAsheesh pointed out two years ago that OpenPGP short key IDs are bad because they are trivial to replicate. This is called a preimage attack against the short key ID (which is just a truncated fingerprint). Today, David Leon Gil demonstrated that a collision attack against the long key ID is also trivial. A collision attack differs from a preimage attack in that the attacker gets to generate two different things that both have the same digest. Collision attacks are easier than preimage attacks because of the birthday paradox. dlg's colliding keys are not a surprise, but hopefully the explicit demonstration can serve as a wakeup call to help us improve our infrastructure. So this is not a way to spoof a specific target's long key ID on its own. But it indicates that it's more of a worry than most people tend to think about or plan for. And remember that for a search space as small as 64-bits (the long key ID), if you want to find a pre-image against any one of 2k keys, your search is actually only in a (64-k)-bit space to find a single pre-image. The particularly bad news: gpg doesn't cope well with the two keys that have the same long key ID:

0 dkg@alice:~$ gpg --import x
gpg: key B8EBE1AF: public key "9E669861368BCA0BE42DAF7DDDA252EBB8EBE1AF" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
0 dkg@alice:~$ gpg --import y
gpg: key B8EBE1AF: doesn't match our copy
gpg: Total number processed: 1
2 dkg@alice:~$ 

This probably also means that caff (from the signing-party package) will also choke when trying to deal with these two keys. I'm sure there are other OpenPGP-related tools that will fail in the face of two keys with matching 64-bit key IDs. We should not use Key IDs I am more convinced than ever that key IDs (both short and long) are actively problematic to real-world use of OpenPGP. We want two things from a key management framework: unforgability, and human-intelligible handles. Key IDs fail at both.

• Fingerprints are unforgable (as much as SHA-1's preimage resistance, anyway -- that's a separate discussion), but they aren't human-intelligible.
• User IDs are human-intelligible, and they are unforgable if we can rely on a robust keysigning network.
• Key IDs (both short and long) are neither human-intelligible nor unforgable (regardless of existence of a keysigning network), so they are the worst of all possible worlds.

So reasonable tools should not expose either short or long key IDs to users, or use them internally if they can avoid them. They do not have any properties we want, and in the worst case, they actively mislead people or lead them into harm. What reasonable tool should do that? How to replace Key IDs If we're not going to use Key IDs, what should we do instead? For anything human-facing, we should be using human-intelligible things like user IDs and creation dates. These are trivial to forge, but people can relate to them. This is better than offering the user something that is also trivial to forge, but that people cannot relate to. The job of any key management UI should be to interpret the cryptographic assurances provided by the certifications and present that to the user in a comprehensible way. For anything not human-facing (e.g. key management data storage, etc), we should be using the full key itself. We'll also want to store the full fingerprint as an index, since that is used for communication and key exchange (e.g. on calling cards). There remain parts of the spec (e.g. PK-ESK, Issuer subpackets) that make some use of the long key ID in ways that provide some measure of convenience but no real cryptographic security. We should fix the spec to stop using those, and either remove them entirely, or replace them with the full fingerprints. These fixes are not as urgent as the user-facing changes or the critical internal indexing fixes, though. Key IDs are not useful. We should stop using them.Tags: collision, crypto, gpg, openpgp, pgp, security

I am happy to announce that OASIS v0.4.0 has just been released. OASIS is a tool to help OCaml developers to integrate configure, build and install systems in their projects. It should help to create standard entry points in the source code build system, allowing external tools to analyse projects easily. This tool is freely inspired by Cabal which is the same kind of tool for Haskell. You can find the new release here and the changelog here. More information about OASIS in general on the OASIS website. I have recently resumed my work on OASIS and this will be hopefully the new version that will lead to quicker iteration in the development of OASIS. The development process was slowdown by the fact, that I feared introducing new fields in _oasis or regression. This was a pain and I decided to change my development model. Features The most important step is the introduction of AlphaFeatures and BetaFeatures fields. They allow to introduce pieces of code that will only be activated if certain features are listed in those fields. It should help to be always ready to release. The features also cover other aspect like flag_tests and flag_docs which has been introduced in OASIS v0.3.0. In fact the features API is now used to introduce all enhancement while keeping backward compatibility with regard to OASISFormat. Rather than defining a ~since_version:0.3 for fields we use a feature that handle the maturity level of the feature. When I feel a specific feature is ready to ship, I just change the InDev Alpha to InDev Beta and then SinceVersion 0.4. On the long term, when we won't support anymore a version of OASIS that existed before the SinceVersion, the feature will always be true and I will fully integrate it in the code. The only constraint around features is: if you use AlphaFeatures or BetaFeatures field, you must use the latest OASISFormat... Features section in the manual. Example of features available:

• section_object: allow to create object (.cmo/.cmx) in _oasis
• pure_interface: an OCamlbuild feature that allows to handle .mli without a .ml file

Automate Another topic is automation of testing releases. For OASIS v0.3.0, I ran tests on all platforms manually, late in the development of v0.3.0 and it was painful to fix. So I have decided to setup a Jenkins instance that automate testing on Linux. On the long term, I plan to also setup a Mac OS X builder and start looking at Windows as well. This should help me catch errors early and be able to fix them quickly. However, for v0.4.0 I have decided to just release what I have and which has mainly be tested on Linux. The point here is to quickly release and iterate, rather than wait for perfection. Hopefully end user testing will allow to quickly discover new bugs. Time boxed release In the coming months, I will try to do time boxed releases. I will try to release version of OASIS every 15th of the month. The point here is to try to iterate faster and avoid long delay between release. See you in 1 month for the next release.

Having used GNU/Linux systems for some time now, and having submitted patches to a fair number of open source projects, it is nice to finally get a patch accepted into the biggest open source project of them all, the Linux kernel. While I did submit a kernel patch to OpenWrt back in 2011, it is maintained as a rebased patchset, and was never upstreamed to Linus' tree. That changed today though, when a small patch I (had forgotten I had) sent to the linux-media mailinglist back in October 2013, was just pulled by Linus Torvalds into his tree for the Linux 3.13-rc4 release; so I'm now proud to be able to call myself a contributor to the Linux Kernel.

...
Creating var directory '/usr/src/git/debian/pkg-mariadb/builddir/mysql-test/var'...
Checking supported features...
MariaDB Version 5.5.32-MariaDB-1
Installing system database...
 - SSL connections supported
Collecting tests...
Using server port 42388
==============================================================================
TEST                                      RESULT   TIME (ms) or COMMENT
--------------------------------------------------------------------------
worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
oqgraph.basic                            [ skipped ]  No OQGraph
oqgraph.binlog                           [ skipped ]  No OQGraph
sphinx.sphinx                            [ skipped ]  No Sphinx
archive.archive-big                      [ skipped ]  Test needs --big-test
binlog.binlog_multi_engine               [ skipped ]  ndbcluster disabled
binlog.binlog_spurious_ddl_errors        [ disabled ]  BUG#11761680 2013-01-18 astha Fixed on mysql-5.6 and trunk
binlog.binlog_truncate_innodb            [ disabled ]  BUG#11764459 2010-10-20 anitha Originally disabled due to BUG#42643. Product bug fixed, but test changes needed
federated.federated_server               [ skipped ]  Test needs --big-test
...

For the fifth year in a row the fearless WebKitGTK+ hackers have gathered in A Coru a to bring GNOME and the web closer. Igalia has organized and hosted it as usual, welcoming a record 30 people to its office. The GNOME foundation has sponsored my trip allowing me to fly the cool 18 seats propeller airplane from Lisbon to A Coru a, which is a nice adventure, and have pulpo a feira for dinner, which I simply love! That in addition to enjoying the company of so many great hackers. The goals for the hackfest have been ambitious, as usual, but we made good headway on them. Web the browser (AKA Epiphany) has seen a ton of little improvements, with Carlos splitting the shell search provider to a separate binary, which allowed us to remove some hacks from the session management code from the browser. It also makes testing changes to Web more convenient again. Jon McCan has been pounding at Web s UI making it more sleek, with tabs that expand to make better use of available horizontal space in the tab bar, new dialogs for preferences, cookies and password handling. I have made my tiny contribution by making it not keep tabs that were created just for what turned out to be a download around. For this last day of hackfest I plan to also fix an issue with text encoding detection and help track down a hang that happens upon page load. Martin Robinson and myself have as usual dived into the more disgusting and wide-reaching maintainership tasks that we have lots of trouble pushing forward on our day-to-day lives. Porting our build system to CMake has been one of these long-term goals, not because we love CMake (we don t) or because we hate autotools (we do), but because it should make people s lives easier when adding new files to the build, and should also make our build less hacky and quicker it is sad to see how slow our build can be when compared to something like Chromium, and we think a big part of the problem lies on how complex and dumb autotools and make can be. We have picked up a few of our old branches, brought them up-to-date and landed, which now lets us build the main WebKit2GTK+ library through cmake in trunk. This is an important first step, but there s plenty to do. Under the hood, Dan Winship has been pushing HTTP2 support for libsoup forward, with a dead-tree version of the spec by his side. He is refactoring libsoup internals to accomodate the new code paths. Still on the HTTP front, I have been updating soup s MIME type sniffing support to match the newest living specification, which includes specification for several new types and a new security feature introduced by Internet Explorer and later adopted by other browsers. The huge task of preparing the ground for a one process per tab (or other kinds of process separation, this will still be topic for discussion for a while) has been pushed forward by several hackers, with Carlos Garcia and Andy Wingo leading the charge. Other than that I have been putting in some more work on improving the integration of the new Web Inspector with WebKitGTK+. Carlos has reviewed the patch to allow attaching the inspector to the right side of the window, but we have decided to split it in two, one providing the functionality and one the API that will allow browsers to customize how that is done. There s a lot of work to be done here, I plan to land at least this first patch durign the hackfest. I have also fought one more battle in the never-ending User-Agent sniffing war, in which we cannot win, it looks like. I am very happy to be here for the fifth year in a row, and I hope we will be meeting here for many more years to come! Thanks a lot to Igalia for sponsoring and hosting the hackfest, and to the GNOME foundation for making it possible for me to attend! See you in 2014!

Just a trivial fact: every polyhedron that is used in linear programming is convex, that is !!mathjaxbegin-i!! QXggXGxlcSBi !!mathjaxend-i!! is convex, for a matrix !!mathjaxbegin-i!! QQ== !!mathjaxend-i!! and a (column) vector !!mathjaxbegin-i!! Yg== !!mathjaxend-i!!. Proof: Take any !!mathjaxbegin-i!! eCcsIHgnJw== !!mathjaxend-i!! that satisfy the system of inequalities !!mathjaxbegin-i!! QXggXGxlcSBi !!mathjaxend-i!!. Then, for !!mathjaxbegin-i!! MCBcbGVxIFxsYW1iZGEgXGxlcSAx !!mathjaxend-i!!, we have that !!mathjaxbegin-i!! XGxhbWJkYSBBeCcgXGxlcSBcbGFtYmRhIGI= !!mathjaxend-i!!, that is !!mathjaxbegin-i!! QSBcbGFtYmRhIHgnIFxsZXEgXGxhbWJkYSBi !!mathjaxend-i!!. Similarly, for !!mathjaxbegin-i!! eCcn !!mathjaxend-i!!, we have that !!mathjaxbegin-i!! QSAoMS1cbGFtYmRhKSB4JyBcbGVxICgxLVxsYW1iZGEpIGI= !!mathjaxend-i!!. Summing the inequalities, we get: !!mathjaxbegin-d!! CiBBW1xsYW1iZGEgeCcgKyAoMS1cbGFtYmRhKSB4JyddIFxsZXEgW1xsYW1iZGEgKyAoMS1cbGFt YmRhKV0gYiA9IGIsCg== !!mathjaxend-d!! which means that !!mathjaxbegin-i!! XGhhdHt4fSA9IFxsYW1iZGEgeCcgKyAoMS1cbGFtYmRhKSB4Jyc= !!mathjaxend-i!! is again a solution of the original set of inequalities, thus concluding the argument.

A nice set of recent posts have done a great job detailing the remaining ways that a root user can get at kernel memory. Part of this is driven by the ideas behind UEFI Secure Boot, but they come from the same goal: making sure that the root user cannot directly subvert the running kernel. My perspective on this is toward making sure that an attacker who has gained access and then gained root privileges can t continue to elevate their access and install invisible kernel rootkits. An outline for possible attack vectors is spelled out by Matthew Gerrett s continuing useful kernel lockdown patch series. The set of attacks was examined by Tyler Borland in Bypassing modules_disabled security . His post describes each vector in detail, and he ultimately chooses MSR writing as the way to write kernel memory (and shows an example of how to re-enable module loading). One thing not mentioned is that many distros have MSR access as a module, and it s rarely loaded. If modules_disabled is already set, an attacker won t be able to load the MSR module to begin with. However, the other general-purpose vector, kexec, is still available. To prove out this method, Matthew wrote a proof-of-concept for changing kernel memory via kexec. Chrome OS is several steps ahead here, since it has hibernation disabled, MSR writing disabled, kexec disabled, modules verified, root filesystem read-only and verified, kernel verified, and firmware verified. But since not all my machines are Chrome OS, I wanted to look at some additional protections against kexec on general-purpose distro kernels that have CONFIG_KEXEC enabled, especially those without UEFI Secure Boot and Matthew s lockdown patch series. My goal was to disable kexec without needing to rebuild my entire kernel. For future kernels, I have proposed adding /proc/sys/kernel/kexec_disabled, a partner to the existing modules_disabled, that will one-way toggle kexec off. For existing kernels, things got more ugly. What options do I have for patching a running kernel? First I looked back at what I d done in the past with fixing vulnerabilities with systemtap. This ends up being a rather heavy-duty way to go about things, since you need all the distro kernel debug symbols, etc. It does work, but has a significant problem: since it uses kprobes, a root user can just turn off the probes, reverting the changes. So that s not going to work. Next I looked at ksplice. The original upstream has gone away, but there is still some work being done by Jiri Slaby. However, even with his updates which fixed various build problems, there were still more, even when building a 3.2 kernel (Ubuntu 12.04 LTS). So that s out too, which is too bad, since ksplice does exactly what I want: modifies the running kernel s functions via a module. So, finally, I decided to just do it by hand, and wrote a friendly kernel rootkit. Instead of dealing with flipping page table permissions on the normally-unwritable kernel code memory, I borrowed from PaX s KERNEXEC feature, and just turn off write protect checking on the CPU briefly to make the changes. The return values for functions on x86_64 are stored in RAX, so I just need to stuff the kexec_load syscall with mov -1, %rax; ret (-1 is EPERM):

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/init.h>
#include <linux/module.h>
#include <linux/slab.h>
static unsigned long long_target;
static char *target;
module_param_named(syscall, long_target, ulong, 0644);
MODULE_PARM_DESC(syscall, "Address of syscall");
/* mov $-1, %rax; ret */
unsigned const char bytes[] =   0x48, 0xc7, 0xc0, 0xff, 0xff, 0xff, 0xff,
                                0xc3  ;
unsigned char *orig;
/* Borrowed from PaX KERNEXEC */
static inline void disable_wp(void)
 
        unsigned long cr0;
        preempt_disable();
        barrier();
        cr0 = read_cr0();
        cr0 &= ~X86_CR0_WP;
        write_cr0(cr0);
 
static inline void enable_wp(void)
 
        unsigned long cr0;
        cr0 = read_cr0();
        cr0  = X86_CR0_WP;
        write_cr0(cr0);
        barrier();
        preempt_enable_no_resched();
 
static int __init syscall_eperm_init(void)
 
        int i;
        target = (char *)long_target;
        if (target == NULL)
                return -EINVAL;
        /* save original */
        orig = kmalloc(sizeof(bytes), GFP_KERNEL);
        if (!orig)
                return -ENOMEM;
        for (i = 0; i < sizeof(bytes); i++)  
                orig[i] = target[i];
         
        pr_info("writing %lu bytes at %p\n", sizeof(bytes), target);
        disable_wp();
        for (i = 0; i < sizeof(bytes); i++)  
                target[i] = bytes[i];
         
        enable_wp();
        return 0;
 
module_init(syscall_eperm_init);
static void __exit syscall_eperm_exit(void)
 
        int i;
        pr_info("restoring %lu bytes at %p\n", sizeof(bytes), target);
        disable_wp();
        for (i = 0; i < sizeof(bytes); i++)  
                target[i] = orig[i];
         
        enable_wp();
        kfree(orig);
 
module_exit(syscall_eperm_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Kees Cook <kees@outflux.net>");
MODULE_DESCRIPTION("makes target syscall always return EPERM");

If I didn t want to leave an obvious indication that the kernel had been manipulated, the module could be changed to:

• not announce what it s doing
• remove the exit route to not restore the changes on module unload
• error out at the end of the init function instead of staying resident

And with this in place, it s just a matter of loading it with the address of sys_kexec_load (found via /proc/kallsyms) before I disable module loading via modprobe. Here s my upstart script:

# modules-disable - disable modules after rc scripts are done
#
description "disable loading modules"
start on stopped module-init-tools and stopped rc
task
script
        cd /root/modules/syscall_eperm
        make clean
        make
        insmod ./syscall_eperm.ko \
                syscall=0x$(egrep ' T sys_kexec_load$' /proc/kallsyms   cut -d" " -f1)
        modprobe disable
end script

And now I m safe from kexec before I have a kernel that contains /proc/sys/kernel/kexec_disabled.

2013, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Last year I told you that I spent two full-time days working on Debian as a part of initiative sponsored by my current employer. This year I ve devoted these two days again for Debian. Quick summary of what I was able to do during these two days. 11 bugs, 4 lintian errors and 43 warnings were fixed. In addition 3 packages now use new source format (usually that means repackaging software from scratch). 4 uses new copyright format and the newest Standards-Version. 5 packages were updated to the newest upstream version. Changelog entries:
potrace (1.11-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream version.
* Completely repackaged from scratch (funny experience as usual):
- uses new copyright format
- uses debhelper compatibility level 9 w/hardening options
- uses the newest Standards-Version
- fixes 11 lintian warnings and 2 errors
* Fixes typo in manpage. (Closes: #694492) -- Bartosz Fenski Mon, 9 Dec 2013 11:23:32 +0100 makeself (2.2.0-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream release. (Closes: #690105)
- handles df output in more portable way (Closes: #641804)
* Repackaged from scratch.
- uses new packaging format 3.0 (Closes: #670738)
- uses new copyright format
- uses debhelper compatibility level 9
- uses the newest Standards-Version
- fixes 2 lintian errors and 6 warnings -- Bartosz Fenski Mon, 09 Dec 2013 17:32:45 +0100 dibbler (1.0.0~rc1-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream release candidate 1 version (Closes: #686539)
- doesn't drop dhcp session during pppd restarts (Closes: #641237)
- doesn't hang indefinitely on 'stop' (Closes: #675272)
* Calls dh --with autotools_dev to prevent build failures (Closes: 727356)
* Includes Japanese debconf translation (Closes: #718921)
* Updated Standards-Version (no changes needed)
* Uses debhelper compatibility level 9 w/hardening options
* init scripts now source init functions
* Fixes 20 lintian warnings. -- Bartosz Fenski Tue, 10 Dec 2013 10:05:56 +0100 calcurse (3.1.4-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream version.
* ACK previous NMU - thanks!
* Bumped Standards-Version (no changes needed) -- Bartosz Fenski Tue, 10 Dec 2013 12:22:06 +0100 ipcalc (0.41-4) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* Fixes overzealous input checking (Closes: #332468)
* Martin F Krafft removed as co-maintainer (Closes: #719098)
+ package now uses new copyright format
* Bumped Standards-Version (no changes needed) -- Bartosz Fenski Tue, 10 Dec 2013 13:05:15 +0100 msort (8.53-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream release.
* ACK previous NMUs, thanks!
* Switched to new source format.
* Switched to new copyright format.
* Moved patches to new quilt format and described them.
* Bumped Standards-Version (no changes needed)
* Has correct tcl/tk dependencies (Closes: #545135)
* Doesn't segfault with certain input (Closes: #630485) -- Bartosz Fenski Tue, 10 Dec 2013 16:39:44 +0100
Thank you Akamai

A new Armadillo release 3.930 came out a few days ago, with a very nice set of changes (see below). I rolled this into RcppArmadillo 0.3.930.0. However, one of these changes revealed that R shipped only the standard SVD for complex-valued matrices, and not the more performant divide-and-conquer approach. So in R builds using the default built-in Lapack, at least one CRAN package no longer built. After some back and forth, Conrad put some branching in the library to fall back to the standard SVD, and I added a built-time configuration test for an appropriate preprocessor directive used by the fallback code. This is now on which is now on CRAN and in Debian as RcppArmadillorelease 0.3.930.1, and Conrad will probably update the Armadillo page as well (though the fix is only needed with R's builtin Rlapack). Also of note is that R Core already added the missing Fortran routine zgesdd to R 3.1.0 (aka "R-devel") so this issue goes away with the next release. Also of note, I wrote up a short Rcpp Gallery post illustrating the performance gains available from divide-and-conquer SVD. The complete list of changes is below.

Changes in RcppArmadillo version 0.3.930.1 (2013-12-09)

• Upgraded to Armadillo release Version 3.930.1
  • Armadillo falls back to standard complex svd if the more performant divide-and-conquer variant is unavailable
• Added detection for Lapack library and distinguish between R's own version (withhout zgesdd) and system Lapack; a preprocessor define is set accordingly

Changes in RcppArmadillo version 0.3.930.0 (2013-12-06)

• Upgraded to Armadillo release Version 3.930 ("Dragon's Back")
  • added divide-and-conquer variant of svd_econ(), for faster SVD
  • added divide-and-conquer variant of pinv(), for faster pseudo-inverse
  • added element-wise variants of min() and max()
  • added size() based specifications of submatrix view sizes
  • added randi() for generating matrices with random integer values
  • added more intuitive specification of sort direction in sort() and sort_index()
  • added more intuitive specification of method in det(), .i(), inv() and solve()
  • added more precise timer for the wall_clock class when using C++11
• New unit tests for complex matrices and vectors

Courtesy of CRANberries, there is also a diffstat report for the most recent release As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

krb5-sync is the software we run at Stanford to synchronize principal information from a central Heimdal realm to Active Directory, allowing users to use either a Linux-based Kerberos environment or Active Directory with the same account and password. The original intent of this release was to add a new feature to allow a subsidiary instance of an account in the MIT or Heimdal realm to be synchronized with the instance-less account in Active Directory. This allows, for example, an rra/windows instance to be used to set and maintain the password for an rra principal in Active Directory. In the process of implementing that, though, I ended up doing a significant overall of the code, since the plugin architecture was quite awkward and dated. The code now uses the MIT Kerberos data structures in a more natural and native way, since MIT Kerberos has now added direct support for plugins of this sort. Kerberos contexts and Kerberos error codes are used uniformly throughout the plugin, which provides consistent and more robust error handling and reporting. I also significantly enhanced the test suite, although it still needs more work to test the core functionality that has complex external dependencies. This release also drops support for all versions of MIT Kerberos prior to 1.9, which required an external patch; to run krb5-sync 3.0, you should upgrade to a recent version of MIT Kerberos. This allowed me to drop support for the legacy API. There are a couple of major backward-incompatible changes in this release (and both unfortunately are not handled automatically by the Debian package upgrade, since it's hard to find and safely modify KDC configuration). First, the ad_ldap_base configuration option is now mandatory when synchronizing account status and its meaning has changed. Previously, dc elements for the realm were appended to a provided partial base. Now, the complete DN of the root of the Active Directory tree should be provided. This is more flexible and more useful with a wider variety of Active Directory setups. Second, I took advantage of the backward-incompatibilities to change the module name to sync.so from krb5_sync.so, since the latter sounded weirdly redundant and verbose when installed in the Kerberos plugin directory. This will require a configuration change to the plugin configuration for the KDC or kadmin server. Also in this release are a couple of new options: ad_queue_only, which forces all changes to be queued for later processing instead of processed in real time, and syslog, which can be used to turn off the internal syslog logging of non-errors from the module. (This is mostly useful for test suites.) Now, password changes are queued on any Active Directory failure, not just a few oddly-distinguished ones. The previous behavior was rather specific to Stanford's needs, and queuing all password changes shouldn't pose any problems. Finally, the krb5-sync-backend utility program for manipulating the queued changes has been completely rewritten and is much cleaner. It now uses the Net::Remctl::Backend Perl module for command and option handling, so that module (provided with remctl 3.4 or later) must be installed. It also requires IPC::Run, which is available from CPAN. It uniformly supports a -d option to specify the queue location, and skips event files during processing that no longer exist. You can get the latest release from krb5-sync distribution page.

This release of my collection of shared C, Perl, and Autoconf code fixes a bug in all the Autoconf macros that use the lib-helper framework for optional use of libraries. The --with flag without a path would result in yes/include and yes/lib to be added to the compiler and linker paths. It also adds Autoconf probles for Cyrus SASL libraries, contributed by Julien LIE based on the INN macros. This release also adds support for KADM5_MISSING_KRB5_CONF_PARAMS to portable/kadmin.h and the test_tmpdir function to Test::RRA::Automake. The latter works the same as it does in the C and shell TAP libraries. Finally, the shared valgrind suppression file adds a suppression for the memory allocated by dlopen to store error messages for dlerror on Linux, which is apparently never freed. You can get the latest release from the rra-c-util distribution page.

Once more, I m going to FOSDEM 2014, the largest Free/Libre/Open Source Software event in Europe (5,000 attendants every year). As usual, I will be in charge of the Desktops DevRoom, together with our friends from Gnome (Christophe Fergeau), Unity (Didier Roche), Enlightenment (Philippe Caseiro) and others. See you in Brussels 1-2 February 2014! BTW, have you already submitted your talk proposal for the Desktops DevRoom? The deadline (15th December) is very close! Do not wait any more!!! See the details here: FOSDEM 2014 Desktops DevRoom Call for Talks