User: Password:
Subscribe / Log in / New account

The Extensible Firmware Interface - an introduction

The Extensible Firmware Interface - an introduction

Posted Aug 23, 2011 10:22 UTC (Tue) by etienne (guest, #25256)
In reply to: The Extensible Firmware Interface - an introduction by cortana
Parent article: The Extensible Firmware Interface - an introduction

If I may, I would like to say something about kexec.
It is not to criticise kexec, that probably works perfectly, it is just about one use case: booting a different kernel release.

Let's imagine yesterday kernel managing yesterday device.
That yesterday device has some configuration bits labelled "do not touch", i.e. bits that you should write to the same value that you read them.
Having "do not touch" bits in configuration words is a usual way to plan for extensibility, those bits are currently zero, but in future (backward compatible) version of the device they may have a meaning, like enabling the super-duper new function.
So yesterday kernel behaves perfectly well, preserving the value of the "do not touch" bits, and obviously do not have the driver of the super-duper function.

Back to today, I have currently booted the today kernel, which knows how to drive the super-duper function, and because it has recognised the more powerful today's device, it has enabled the super-duper function in the device by setting the previously "do not touch" bit (now enable super-duper function bit) to the device register.

Now, if I kexec yesterday's kernel, it will not change the "do not touch" bit, but it does not have the super-duper function driver neither.
I am not saying this pattern happens often, I am not saying the system will always misbehave, I am just saying there is a risk.

(Log in to post comments)

The Extensible Firmware Interface - an introduction

Posted Aug 23, 2011 10:28 UTC (Tue) by cortana (subscriber, #24596) [Link]

It is a real risk, to be certain: but not in kexec itself; just in the tools that decide which kernel will be kexec'd when the shutdown command is issued.

Debian's kexec-tools package for instance always boots /vmlinuz, which is a symlink maintained by the various linux-image-* packages and which usually points to the latest installed kernel. IMO this is a mistake, and kexec should attempt to boot into the currently installed kernel, if it still exists.

This doesn't sound too hard--just look at the results of uname(2) and then look for a matching file in /boot. I think this would make your scenario less likely, however (at least in Debian's case) they only use a different filename for different kernel releases and ABI-changing updates to the same release, so the file /boot/vmlinux-3.0.0-1-amd64 that currently exists on my system may have been updated since the system booted with a file of the same name.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds