unqualified host name; sleeping for retry

After a fresh installation of FreeBSD today, I’d noticed that my boot up time was suffering due to this message which consistently appears:

Jul 19 16:58:38 freebsd sm-mta[1097]: My unqualified host name (freebsd) unknown; sleeping for retry
Jul 19 16:59:38 freebsd sm-mta[1097]: unable to qualify my own domain name (freebsd) -- using short name
Jul 19 16:59:38 freebsd sm-msp-queue[1100]: My unqualified host name (freebsd) unknown; sleeping for retry
Jul 19 17:00:38 freebsd sm-msp-queue[1100]: unable to qualify my own domain name (freebsd) -- using short 

As you can see, this machine that I’ve created does have the very original hostname of freebsd.

What the error message is telling us is that I need to fully qualify my hostname. Editing /etc/rc.conf you can change the hostname value to include this information. The top line of my rc.conf now reads as follows:

hostname="freebsd.home"

No more slow boot times; because of this problem, at least.

Mounting remote filesystems with sshfs

Getting direct access over ssh is simplified greatly by sshfs, a fuse based file system. To get started, install sshfs with your favourite package manager:

$ sudo pacman -S sshfs

To connect to a remote file system, you just use the following:

$ sshfs host: mountpoint

Much like ssh, the host argument can take on the format of user@host if you’re logged in as a user that doesn’t correspond to the remote machine.

When you’re done, unmounting the filesystem is done like so:

$ fusermount -u mountpoint

A GDT Primer

For Intel chips, the major processes (like memory management, interrupts, etc) are managed through a set of tables. These tables are as simple as length and a linear address to the actual table data.

The GDT or Global Descriptor Table is one of these tables and it’s what your CPU uses to describe its internal memory segmentation for the system.

In today’s post, I’ll take you through how the GDT is defined and how it is applied to your system.

What is it and how is it defined?

Like I said in the introduction, all that the GDT is made up of is a length and a linear address to the data. Here’s an example below, defined in assembly language

gdt_data:
   DQ 0x0000000000000000
   DQ 0x00CF9A000000FFFF
   DQ 0x00CF92000000FFFF

gdt_tab:
   DW 23
   DD gdt_data

In the above snippet, gdt_data defines the actual GDT entries. We’ll get into what the values mean shortly, but for now it’s important to understand that this block of data starts with a null entry (or all zeros) and then the entries begin. You’ll see that each entry is defined by DQ, so each entry is 8 bytes.

gdt_tab starts with the length of the structure (minus 1). The whole “minus 1” part comes in because the expected data type of the length is a word, it can only hold a maximum value of 65535 but you are allowed up to 65536 entries in the table. Obviously, it’s invalid to specify a table that has a zero length. Next, gdt_tab defines a linear address to the table data itself, gdt_data.

How is a GDT entry assembled?

Each GDT entry conforms to the following format:

From this table, you can see that it defines a 32 bit base which is a linear address of where the segment begins and a 20 bit limit which is the maximum addressable unit.

The access byte is 8 bits in flags that describe different access privileges. The byte breaks down like this:

The flags nibble is 4 bits that control size:

How do the values breakdown?

Above, we had some example data that we were setting up for a GDT. Here’s how those values break down.

Original value
00CF9A000000FFFF

base  24-31 : 00
flags       : C  (1100b)
limit 16-19 : F
access      : 9A (10011010b)
base 23-0   : 000000
limit 15-0  : FFFF

This particular entry says it’s at a base of 0x00000000, has a limit of 0xFFFFF. The access byte tells us that the segment is:

• Present
• Is privileged to Ring-0
• Is executable
• Can ONLY be executed in Ring-0
• Is readable

The flags also tell us that the segment has:

• A limit that is expressed in 4KiB units
• Our selectors are 32 bits

How is it set?

Actually defining the GDT entries is one thing, but you also need to set them as well. This is quite an easy process.

mov   eax, gdt_tab   ; load in the address of the table
lgdt  [eax]          ; load the new GDT

After this has happened, we need to jump into our new segment to continue executing code. In the table gdt_tab, the code segment was defined 2nd (after the null entry). The code segment definition is 0x08 (or just 8) bytes into the table.

After jumping to our code segment, we need to refresh all of the segment selectors so that they’re now pointing at the right place as well. 16 bytes (0x10) into the table (the third entry) is where we’ve defined the data segment.

   jmp   0x08:refresh_segments

refresh_segments:

   mov   eax, 0x10
   mov   ds, ax
   mov   es, ax
   mov   fs, ax
   mov   gs, ax
   mov   ss, ax

Differences between 32 and 64 bit

Segmentation is very simple once you enter the 64 bit world. Four of the segment registers: CS, SS, DS and ES start at 0x00 and have a limit of 0xFFFFFFFFFFFFFFFF. Pretty simple. FS and GS are still capable of a non-zero base address.

An example table on how this would look is like this:

gdt_tab_64:
   DQ 0x0000000000000000
   DQ 0x00A09A0000000000
   DQ 0x00A0920000000000

You can see how the base and limits have simplified greatly here.

Conclusion

There’s quite a bit more you can learn in this field. There’s also some excellent resources around the web to help out. Here’s just a few:

• Wikipedia
• OS Dev Wiki
• GDT Tutorial

Encode or Decode base64 at the console

Today’s post is a quick tip on encoding and decoding base64 information with the base64 command at the linux prompt.

In order to encode a piece of text, you can do the following:

$ echo 'I want to encode this text' | base64
SSB3YW50IHRvIGVuY29kZSB0aGlzIHRleHQK

To reverse the process, simply use the -d switch:

$ echo SSB3YW50IHRvIGVuY29kZSB0aGlzIHRleHQK | base64 -d
I want to encode this text

Simple.

Starting Linux module development

Introduction

Developing modules for the Linux Kernel has previously been a difficult discipline to even get started in, but as time has passed it’s become a more approachable and accessible topic. In today’s post, I’m going to go through

• How to setup your build environment
• Writing the code for a simple module
• Building your module
• Adding and removing your module from the Kernel

There are a lot of different sources on the internet that have this information and the best reference that I can suggest is on the LDP which is here.

We’ve got a bit to cover, so let’s get started. One last thing though, I’m running Arch Linux to write this tutorial however everything that I’m writing about here should be directly translatable into your distribution of choice.

Setting up your build environment

You need to put your system into a state where you’re able to build kernel modules, and you’ll do this with the linux-headers package from your distribution’s package manager.

sudo pacman -S linux-headers

Once this has installed, you’ll find a build environment has been made under /lib/modules/ on your system. You’ll also have all of the development files required to include in your modules.

The code

First up, just a couple of requirements. We’re going to print a kernel message using printk when the module is initialised and we’ll print another when the module has been unloaded. Pretty unimaginative but it’ll be great for the sake of demonstration.

Here’s the code:

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Michael Tuttle");
MODULE_DESCRIPTION("A useless module for demonstration purposes");

/** Initialises our module into the kernel */
static int __init message_init(void) {
   printk(KERN_INFO "Module has been loaded");
   return 0;
}

/** Unloads our module from the kernel */
static void __exit message_exit(void) {
   printk(KERN_INFO "Module has been unloaded");
}

module_init(message_init);
module_exit(message_exit);

That’s it for the code. It’s pretty easy to follow. You can see that message_init is what will be called when our module is loaded and message_exit when unloaded. Traditionally these were called init_module and cleanup_module respectively but these names are allowed to change due to the use of the __init, module_init, __exit and module_exit macros.

printk is what we’ll use to send some text into the kernel messages. You retrieve these with the dmesg shell command.

Building your module

The Makefile for this module is actually quite simple, but requires a little explanation.

obj-m += msg.o

all:
   make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
   make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Quite simple in the end, but cryptic if you haven’t come across some of it before. The obj-m directive tells the make system that we want a kernel module. obj-d can be used here when we’re making a driver.

The make targets are executed against the build environment we installed above. -C tells make to issue its instructions in the folder given.

After compiling your module, you’re ready to see it in action.

Adding and Removing your module

To get your kernel to start using your module, you issue insmod against the .ko file that has been built for you.

$ sudo insmod msg.ko

The kernel now should have loaded your module and you should be able to confirm that it’s loaded by checking dmesg:

$ dmesg

. . .
. . .
. . .
[ 3320.686668] Module has been loaded

Of course there’s an easier way to check that it’s loaded. You can see a list of all the loaded modules in your kernel by issuing lsmod.

$ lsmod
Module                  Size  Used by
msg                      825  0
. . .
. . .
. . .

The first half has gone to plan. To unload this module, we now use rmmod.

$ sudo rmmod msg.ko

Now that the module has been removed, we should see the leaving message in the output of dmesg.

$ dmesg

. . .
. . .
. . .
[ 3641.668948] Module has been unloaded