fidzu : Linux

Webopedia: "Jelly Bean is the anticipated dessert-themed Android codename for an upcoming version 5.0 update of the open source Android mobile operating system."

06 Feb 2012 12:08pm GMT

Last week I delivered benchmarks showing how Ubuntu 12.04 is ARM-ing up for better performance with ARM-based hardware and detailed some of the plans Canonical has for this architecture going forward. While those benchmarks last week illustrated some significant performance improvements with the Ubuntu 12.04 stack -- in large part due to the switch to hard floating-point support -- the gains are not over. In fact, there are already some striking improvements if using the Texas Instruments OMAP4460 SoC as found on the PandaBoard ES.

06 Feb 2012 11:33am GMT

With the Mesa 8.0 release right around the corner, in recent weeks there have been a number of benchmarks on Phoronix looking at this latest open-source OpenGL library and its drivers, including Gallium3D. In this article though are new benchmarks from one of the areas not explored yet: the Intel Gallium3D driver performance.

06 Feb 2012 10:36am GMT

Zelda Classic (ZC) is a tribute to one of the greatest video games of all time: Nintendo's The Legend of Zelda. It has been developed into an exact replica of the NES version. Beyond that, Zelda Classic allows the development of new quests that can use either the traditional graphics or enhanced graphics, as well as new enemies, items, and challenges. Zelda Classic works very well in Linux and lots of custom quests can be played.

06 Feb 2012 9:39am GMT

Shutter is the best screenshot tool in Linux. I'll show you how to

06 Feb 2012 8:42am GMT

In this article I talk about manning turrets, fighting capital ships, and explosions

06 Feb 2012 6:20am GMT

PCLinuxOS is a Mandriva based distribution that is geared towards novice users. It has a big community in which is there to help new users to Linux get off on the right foot.

06 Feb 2012 5:23am GMT

While not exclusively a Gnu-Linux product (runs on LAMP and WAMP stacks), the selection of OpenEMR by the Peace Corps for its worldwide EMR needs, lends a powerful measure of legitimacy and value to the use of open source EMRs in general and OpenEMR specifically. .http://www.govhealthit.com/news/peace-corps-plans-ehr-system-2013 .OpenEMR continues to grow its active developer community incorporating state of the art capacity including 5010 standards, Android apps, etc. .http://www.open-emr.org/ .Jack Cahn MDOEMR.org Board

06 Feb 2012 4:26am GMT

Project Zomboid has added a new video and some screenshots of new locations that will be available in the upcoming update!

06 Feb 2012 3:29am GMT

[url=http://lxer.com/team.php][img]http://lxer.com/content/Scott_Ruecker.jpg[/img][/url] [b]LXer Feature: 05-Feb-2012[/b]Is it February already? This week we have a new Linux powered Spark tablet and btrfs goes production ready. Take the road less traveled in installing Ubuntu, the death of file sharing, Venn diagrams and a whole lot more. Enjoy!

06 Feb 2012 2:31am GMT

Bill Reynolds announced of the second version of PCLinuxOS 2012.2 on 3rd Feb,2012. It uses Linux Kernel 2.6.38.8 and desktop environment is KDE 4.6.5. The Synaptic package manager is there for package management which contain over 13,500 packages. PCLinuxOS is mainly forked from Mandriva and very user friendly operating system.

06 Feb 2012 2:19am GMT

A few days ago I wrote that the Wayland Display Server is preparing for a stable 1.0 release and now this weekend from FOSDEM new information has been learned...

06 Feb 2012 1:22am GMT

FreeBSD still lacks mainline support for kernel mode-setting (KMS) on modern hardware, but at least it's still being worked on...

06 Feb 2012 12:24am GMT

Script writing is the art and craft of writing scripts for the general public. The script can take the form of musicals, plays, novels, films, television programmes, and more. Each time you watch a show on television, visit the cinema, or read a book you are consuming the trials and tribulations of a script writer.

05 Feb 2012 11:27pm GMT

Xubuntu 12.04 LTS Alpha 2 is powered by Linux kernel 3.2.2 and is built on top of the Xfce 4.8 desktop environment. It features a new greeter and desktop theme, as well as minor changes to various packages and default settings (including the size of the Terminal font).

05 Feb 2012 10:30pm GMT

LWN: Linux has a lot of filesystems, but two of them (ext4 and btrfs) tend to get most of the attention.

05 Feb 2012 10:00pm GMT

A discussion has been started about a next-generation API for Linux KVM (Kernel-based Virtual Machine) virtualization...

05 Feb 2012 9:33pm GMT

Eric Anholt of Intel spoke on Saturday at FOSDEM 2012 in Belgium about the state of the Intel Linux graphics driver user-space and some of their future plans...

05 Feb 2012 8:37pm GMT

OSnews: If you've used UNIX or any of its derivatives, you've probably wondered why there's /bin, /sbin, /usr/bin, /usr/sbin in the file system.

05 Feb 2012 6:00pm GMT

EnterpriseNetworkingPlanet: HP is taking the bold step of being the first major vendor to offer full commercial support for open source OpenFlow software defined networking technology.

05 Feb 2012 2:00pm GMT

UbuntuManual: A majority of Linux users prefer sticking to their terminal rather than accessing through a GUI for most of their daily tasks.

05 Feb 2012 10:00am GMT

Muktware: The 3.3 kernel release will let you boot an Android userspace with no modifications, but not very good power management.

05 Feb 2012 6:00am GMT

InternetNews: So how much do Linux Foundation fellows make anyways?

04 Feb 2012 11:00pm GMT

Linux.com: Care to rethink your desktop user experience? It may be simpler than you think.

04 Feb 2012 7:00pm GMT

WIRED Enterprise: "First created in 2004, OpenMRS is now used in countries across the globe, including Rwanda, Mozambique, Haiti, India, China, and the Phillipines."

04 Feb 2012 3:00pm GMT

PC Quest: "Presented here are the key points to keep in mind before moving to open source software."

04 Feb 2012 11:04am GMT

OSTATIC: "There are a number of free resources available for Windows users who want to take the Linux plunge. In this post, you'll find our updated collection of several of them that can make moving to Linux very easy."

04 Feb 2012 7:02am GMT

Datamation: Tech salesman have daydreams just like everyone else.

04 Feb 2012 1:00am GMT

Wazi: "Imagine a hundred-user network where people come and go, and you, the systems administrator, have to create and delete users not only for access to the operating system but on the many applications that also require authorization."

03 Feb 2012 11:01pm GMT

Linuxaria: "Which Filesystem should I use with this big disk ?"

03 Feb 2012 10:03pm GMT

LinuxBSDos.com: "The battle between malware writers and those trying to make their life miserable is a never ending one."

03 Feb 2012 9:02pm GMT

sed -i 's/gregkh@suse.de/gregkh@linuxfoundation.org/g' .addressbook

01 Feb 2012 5:08am GMT

A recent post to LKML stated that the patch in question did not plan to hold any global locks, including rcu_read_lock(), presumably because of concerns about contention or overhead. This blog entry is intended to help address any lingering concerns about rcu_read_lock() contention and overhead.

To be fair, at first glance, rcu_read_lock()'s source code does look a bit scary and slow:

static inline void rcu_read_lock(void)
{       
        __rcu_read_lock();
        __acquire(RCU);
        rcu_lock_acquire(&rcu_lock_map);
}

However, a closer look reveals that both __acquire() and rcu_lock_acquire() compile to nothing in production kernels (CONFIG_PROVE_LOCKING=n). This leaves __rcu_read_lock(), which is compiled differently for different settings of CONFIG_PREEMPT.

Let's start with CONFIG_PREEMPT=n. We have:

static inline void __rcu_read_lock(void)
{       
        preempt_disable();
}

And, again for CONFIG_PREEMPT=n:

#define preempt_disable()               do { } while (0)

The overall result for rcu_read_lock() when CONFIG_PREEMPT=n is therefore as follows:

static inline void rcu_read_lock(void)
{       
}

Similar analysis of rcu_read_unlock()</code> reveals that it is also an empty static inline function for CONFIG_PREEMPT=n. It is to be hoped that this is sufficiently lightweight for most practical purposes. If you find a case where it is too heavyweight, I would be very interested in hearing about it!

That leaves CONFIG_PREEMPT=y, which actually has executable code in its definition of __rcu_read_lock() as follows:

void __rcu_read_lock(void)
{       
        current->rcu_read_lock_nesting++;
        barrier();
}

The first statement is a simple non-atomic increment of a simple int that is located in the task's own task_struct. The barrier in the second statement expands as follows:

#define barrier() __asm__ __volatile__("": : :"memory")

This is an empty asm that generates no code, but that does disable code-motion optimizations that might otherwise move memory references across the barrier() statement. So, the executable code for rcu_read_lock() for CONFIG_PREEMPT=y is as follows:

void rcu_read_lock(void)
{       
        current->rcu_read_lock_nesting++;
}

A similar analysis of rcu_read_unlock() for CONFIG_PREEMPT=y yields the following:

void __rcu_read_unlock(void)
{
        struct task_struct *t = current;

        if (t->rcu_read_lock_nesting != 1)
                --t->rcu_read_lock_nesting;
        else {
                t->rcu_read_lock_nesting = INT_MIN;
                if (unlikely(ACCESS_ONCE(t->rcu_read_unlock_special)))
                        rcu_read_unlock_special(t);
                t->rcu_read_lock_nesting = 0;
        }
}

The common case of a single level of rcu_read_lock() nesting executes the else clause of the first if statement, and only executes the then clause of the second if statement when the RCU read-side critical section was either preempted or ran for several milliseconds.

So in the common case, rcu_read_unlock() for CONFIG_PREEMPT=y executes two tests of task-local variables and two assignments to task-local variables.

This should be sufficiently lightweight for most purposes.

Of course, RCU is intended for read-mostly situations, and RCU updates can have significant overhead, incurring significant latency, CPU overhead, and/or cache misses. That said, there are some special cases where RCU updates can be extremely fast, as shown in Figures 12 and 13 of the supplementary materials to User-Level Implementations of Read-Copy Update. (No, the supplementary materials are not behind a paywall: Click on the "Supplemental Material(PDF)" link.)

31 Jan 2012 6:36pm GMT

GPL enforcement is a surprisingly difficult task. It's not just a matter of identifying an infringement - you need to make sure you have a copyright holder on your side, spend some money sending letters asking people to come into compliance, spend more money initiating a suit, spend even more money encouraging people to settle, spend yet more money actually taking them to court and then maybe, at the end, you have some source code. One of the (tiny) number of groups involved in doing this is the Software Freedom Conservancy, a non-profit organisation that offers various services to free software projects. One of their notable activities is enforcing the license of Busybox, a GPLed multi-purpose application that's used in many embedded Linux environments. And this is where things get interesting

GPLv2 (the license covering the relevant code) contains the following as part of section 4:

Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.

There's some argument over what this means, precisely, but GPLv3 adds the following paragraph:

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation

which tends to support the assertion that, under V2, once the license is terminated you've lost it forever. That gives the SFC a lever. If a vendor is shipping products using Busybox, and is found to be in violation, this interpretation of GPLv2 means that they have no license to ship Busybox again until the copyright holders (or their agents) grant them another. This is a bit of a problem if your entire stock consists of devices running Busybox. The SFC will grant a new license, but on one condition - not only must you provide the source code to Busybox, you must provide the source code to all other works on the device that require source distribution.

The outcome of this is that we've gained access to large bodies of source code that would otherwise have been kept by companies. The SFC have successfully used Busybox to force the source release of many vendor kernels, ensuring that users have the freedoms that the copyright holders granted to them. Everybody wins, with the exception of the violators. And it seems that they're unenthusiastic about that.

A couple of weeks ago, this page appeared on the elinux.org wiki. It's written by an engineer at Sony, and it's calling for contributions to rewriting Busybox. This would be entirely reasonable if it were for technical reasons, but it's not - it's explicitly stated that companies are afraid that Busybox copyright holders may force them to comply with the licenses of software they ship. If you ship this Busybox replacement instead of the original Busybox you'll be safe from the SFC. You'll be able to violate licenses with impunity.

What can we do? The real problem here is that the SFC's reliance on Busybox means that they're only able to target infringers who use that Busybox code. No significant kernel copyright holders have so far offered to allow the SFC to enforce their copyrights, with the result that enforcement action will grind to a halt as vendors move over to this Busybox replacement. So, if you hold copyright over any part of the Linux kernel, I'd urge you to get in touch with them. The alternative is a strangely ironic world where Sony are simultaneously funding lobbying for copyright enforcement against individuals and tools to help large corporations infringe at will. I'm not enthusiastic about that.

comments

30 Jan 2012 11:40pm GMT

As co-editor of the last edition of the File Hierarchy Standard before it merged into the Linux Standard Base, I've been following the discussion about combining the directories /bin, /sbin and /lib into /usr/bin, /usr/sbin and /usr/lib respectively. You can follow it too, via the LWN discussion.

To summarize, there are two sides to the debate. The "pro" side points out:

1. Nothing will really change for users, as symlinks will make old stuff still work.
2. There are precedents in Solaris and Fedora.
3. The weak reasonings used previously to separate / and /usr no longer apply.
4. Separate /usr has become increasingly unsupported anyway.
5. Moving to /usr will enable genuine R/O root filesystem sharing.

The "anti" side, however, raises very salient points:

1. Lennart Poettering supports it.
2. Lennart Poettering is an asshole.

Fellow Anti-mergers, I understand the pain and anguish that systemd has caused you personally, and your families. Your hopes and dreams crushed, by someone with all the charm of a cheese grater across the knuckles. Your remaining life tainted by this putrescent subhuman who forced himself upon your internet.

Despite the privation we have all endured, please find strength to stop this nightmarish ravaging of our once-pure filesystems. For if he's not stopped now, what hope for /usr/sbin vs /usr/bin?

28 Jan 2012 5:04am GMT

Jolly has been hacking up a nice new RSSI monitoring firmware application for OsmocomBB.

I let the pictures speak for themselves:

I really hope this trend continues and we'll get some actual user interface in OsmocomBB at some point this year..

28 Jan 2012 1:00am GMT

Some days ago, I noticed that the famous OP25 project (a Free Software implementation of the APCO25 system, a digital trunked radio system) was no longer reachable on-line. It seems they were running this on a desktop PC in a university. As nobody in the project still seems to be at that university, a change in the network configuration had accidentally rendered the website unreachable.

After some quick e-mails, I offered to host them within the osmocom.org family of Free Software Projects for mobile communications. This is when op25.osmocom.org was created, and a full-site backup uploaded + installed.

I'm really happy that we were able to do a small part to help to make sure this valuable project remains accessible to interested parties in the signal processing and mobile communications field.

25 Jan 2012 1:00am GMT

At the osmocom project, we recently discovered the most interesting NVS NV08C-CSM module. It not only is a superb GPS receiver, but it includes GALILEO and GLONASS receivers, too. However, it's only available as an industry module, or as an expensive (700 EUR or so) evaluation kit.

Given the cheap PCB prototyping service at seeedstudio, I thought I'd spend an afternoon creating the schematics and PCB layout for an evaluation board. It exports the two 3.3V UARTs on OsmocomBB-style 2.5mm jacks, so they can be used with the T191 cables. I have the feeling this 2.5mm jack is becoming a new standard for low-voltage RS232 links ;)

Furthermore, it exports the SPI, I/O and I2C on a 20pin 2.54mm pitch header, connects to an external antenna via a MCX socket and has an optional footprint for a CR2032 battery on the bottom side.

So far, the board seems to be working fine. If there is interest in the bare PCB itself (without components!), please send me an e-mail. Depending on the amount of interest we might add it to the sysmocom webshop.

Schematics and Gerber files will be available at http://openbsc.osmocom.org/trac/wiki/osmo-nvs-gps soon.

25 Jan 2012 1:00am GMT

I gave a presentation on UEFI at LCA 2012 - you can watch it here, with the bonus repeat (and different jokes) here. It's a gentle introduction to UEFI, followed by some discussion of the problems we've faced in dealing with implementation bugs.

The fundamental problem is that UEFI is a lot of code. And I really do mean a lot of code. Ignoring drivers, the x86 Linux kernel is around 30MB of code. A comparable subset of the UEFI tree is around 35MB. UEFI is of a comparable degree of complexity to the Linux kernel. There's no reason to assume that the people who've actually written this code are significantly more or less competent than an average Linux developer, so all else being equal we'd probably expect somewhere around the same number of bugs per line. Of course, not all else is equal.

Even today, basically all hardware is shipping with BIOS by default. The only people to enable UEFI are enthusiasts. Various machines will pop up all kinds of dire warnings if you try to turn it on. UEFI has had very little real world testing. And it really does show. In the few months I've been working on UEFI I've discovered machines where SetVirtualAddressMap() calls code that has already been (per spec) discarded. I've seen cases where it was possible to create variables, but not to delete them. I've seen a machine that would irreparably corrupt its firmware when you tried to set a variable. I've tripped over code that fails to parse invalid boot variables, bricking the hardware. Many vendors independently fail to report the correct framebuffer stride. And those are just the ones that have ended up on hardware which crosses my desk, which means I haven't even tested the majority of consumer-grade hardware with UEFI.

The problems with UEFI have very little to do with its design or the ability of the people implementing it. After a few years of iterative improvements it stands a good chance of being more reliable and useful than BIOS. Increased commonality of code between vendors is a blessing and a curse - in the long term it means that these bugs can be shaken out, but in the short term it means that at least one hardware-destroying bug has ended up carried by multiple vendors. Right now we're still in the short term and it's likely that we'll find yet more UEFI bugs that cause all sorts of problems. The next few years will probably be a bumpy ride.

comments

23 Jan 2012 3:52pm GMT

(Update January 18th 2012 - you probably want to read this for details on why the technical details described below are not the difficult bit of the problem)

An obvious question is why Linux doesn't support UEFI secure booting. Let's ignore the issues of key distribution and the GPL and all of those things, and instead just focus on what would be required. There's two components - the signed binary and the authenticated variables.

The UEFI 2.3.1 spec describes the modification to the binary format required to produce a signed binary. It's not especially difficult - you add an extra entry to the image directory, generate a hash of the entire binary other than the checksum, the certificate directory entry and the signatures themselves, encrypt that hash with your key and embed the encrypted hash in the binary. The problem has been that there was a disagreement between Microsoft and Intel over whether this signature was supposed to include the PKCS header or not, and until earlier this week the only widely available developer firmware (Intel's) was incompatible with the only widely available signed OS (Microsoft's). There's further hilarity in that the specification lists six supported hash algorithms, but the implementations will only accept two. So pretty normal, really. Developing towards a poorly defined target is a pain. Now that there's more clarity we'll probably have a signing tool before too long.

Authenticated variables are the other part of the puzzle. If a variable requires authentication, the operating system's attempt to write it will fail unless the new data is appropriately signed. The key databases (white and blacklists) are examples of authenticated variables. The signing actually takes place in userspace, and the handoff between the kernel and firmware is identical for both this case and the unauthenticated case. The only problem in Linux's support here is that our EFI variable support was written to a pre-1.0 version of the EFI specification which stated that variables had a maximum size of 1024 bytes, and this limitation ended up exposed to userspace. So all we really need to do there is add a new interface to let arbitrary sized variables be written.

Summary: We don't really support secure boot right now, but that's ok because you can't buy any hardware that supports it yet. Adding support is probably about a week's worth of effort at most.

comments

18 Jan 2012 1:05am GMT

I wrote about the technical details of supporting the UEFI secure boot specification with Linux. Despite me pretty clearly saying that this was ignoring issues of licensing and key distribution and the like, people are now using it to claim that Linux could support secure boot with minimal effort. In a sense, they're right. The technical implementation details are fairly straightforward. But they're not the difficult bit.

Secure boot requires that all code that can touch hardware be trusted

Right now, if you can run unstrusted code before the OS then you can subvert the OS. Secure boot gives you a mechanism for making sure you only run trusted code, which protects against that. So your UEFI drivers have to be signed, your bootloader has to be signed, and your bootloader must only load a signed kernel. If you've only booted trusted code then you know that your OS is safe. But, unlike trusted boot, secure boot provides no way for you to know that only trusted code was executed. That has to be ensured by OS policy.

This doesn't sound like too much of a problem. But it is. Imagine we have a signed Linux bootloader and a signed Linux kernel, and that these signatures are made with a globally trusted key. These will boot on any hardware using secure boot. Now imagine that an attacker writes a kernel module that sets up a fake UEFI environment, stops the kernel from running code and then executes the Windows bootloader - kind of like kexec, but a little more fiddly. The Windows bootloader believes that it's performing a secure boot, but in fact everything that it believes is trustworthy is the attacker's fake UEFI code. The user's encryption passphrase is logged, the Windows kernel is modified to hide the Linux code and despite everything looking fine your credit card details are on their way to China. In this scenario, the signed Linux kernel is simply used as a malware loader. The only sign that anything is wrong is that boot will be slightly slowed down.

Signing the kernel isn't enough. Signed Linux kernels must refuse to load any unsigned kernel modules. Virtualbox on Linux? Dead. Nvidia binary driver on Linux? Dead. All out of tree kernel modules? Utterly, utterly dead. Building an updated driver locally? Not going to happen. That's going to make some people fairly unhappy.

(The same applies to Windows, of course. Windows 7 allows you to disable driver integrity checks. Windows 8 will have to forbid that when the system's using secure boot)

Licensing

GPLv3 has various requirements for signing keys to be available. Microsoft's new requirement that systems support the installation of user keys would let users boot their own modified bootloaders, so that may end up being sufficient to satisfy the license. But we're then beholden on Microsoft - if they remove that requirement then users lose that freedom, and suddenly we're in an awkward licensing situation. There are ongoing conversations about exactly what we're able to do here, but it's not a solved problem.

Key distribution

The UEFI spec doesn't describe or mandate a central certifying authority. Microsoft require that everyone carry their key. We could generate our own, but we have much less sway with vendors. There's no way to guarantee that all hardware vendors will generate our key. And, obviously, if we generate a key, we can't just hand the private half out to others. That means that it becomes impossible for people to produce derivative versions of Linux distributions without getting their own key. The kind of identity verification that would be required for getting such a key is likely to be expensive, and also fairly likely to require that the distribution have a legally registered company in order to facilitate the identity verification. Think Extended Validation certificates, not Startssl Free. Hobbyist Linux distributions will be a thing of the past.

Doesn't custom mode fix this?

Microsoft's certification requirements now state that all systems must support a custom mode, implying that it will be possible for a user to install their own keys. Linux vendors would then be able to ship with their own keys on the install media and impose their own policies. Everyone's happy. It's not really good enough, though. People have spent incredible amounts of time and effort making it easy to install Linux by doing little more than putting a CD in a drive. Asking them to go into the firmware and reconfigure things adds an extra barrier that restricts the ability to install Linux to more technically skilled users. And it's even worse than that. This is the full description of the requirement for custom mode:

1. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK.
   
2. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with Secure Boot turned off.
   
3. The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.

There's a few things missing from this, namely:

• Any description of the UI. It's effectively impossible to document Linux installation when the first step becomes (a) complicated and (b) vendor specific. Vendors are using the UEFI transition to differentiate themselves by coming up with their own unique firmware interfaces. Custom mode is going to look different everywhere.
• Any description of the key format. A raw binary representation of the key? An EFI_SIGNATURE_DATA struct? A base64 encoding of one, further protected with ROT13? We just don't know.
• Any way to use custom mode for unattended installs. It's a firmware interface that requires a physically present user. Want to install a few thousand machines over the network? This isn't a scalable approach
• …and this one's nitpicking, but there's not actually any requirement that the user be able to add keys - a vendor could conform to this language by only letting users delete keys. This is actually ok as long as the user deletes Pk, because then we'll effectively be back in setup mode and can install our own keys from the installer, but it still results in some practical problems

So no, custom mode doesn't make everything ok. Custom mode with a mandated UI and a documented key format would be much closer, but it wouldn't solve the problem of unattended automated installs.

Summary

We can write the code required to support secure boot on Linux in a minimal amount of time - in fact, most of it's now done. But significant practical problems remain, and so far we have no workable solutions for any of them.

comments

18 Jan 2012 12:55am GMT

This is a pre-announcement so people can start planning travel for the year.

The Linux Security Summit for 2012 will be held on the 30th and 31st of August in San Diego, CA, USA. It will be co-located with LinuxCon North America, plumbers and the kernel summit.

More details to follow.

18 Jan 2012 12:43am GMT

This is what I got when tracking one of my inbound shipments:

It seems DHL is having fun bouncing the package back and forward between Hong Kong and Leipzig(Germany). So far, it started in HK, then arrived in Leipzig on January 8, went back to HK, back to Leipzig, back to HK, back to Leipzig and is currently allegedly again in Hong Kong _after_ succesfully passing German customs clearance on January 15.

For the TCP/IP nerds among the readers: I wonder when the TTL expires.

17 Jan 2012 1:00am GMT

I've set up a new git repository for the Linux kernel security subsystem on the new kernel.org server.

The URLs are:

git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
http://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
https://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git

Developers should work against the "next" branch.

A web-browsable interface via gitweb may be found at:

http://git.kernel.org/?p=linux/kernel/git/jmorris/linux-security.git;a=summary

The temporary repo on selinuxproject.org will go away soon, so please update your repositories.

16 Jan 2012 5:02am GMT

I shot videos of several of the presentations at the Fedora User and Developer Conference yesterday. For your viewing pleasure:

• "State of Fedora" from the Fedora Project Leader, Jared Smith [ogg]
• Mike McGrath, team lead for OpenShift, demoing OpenShift [ogg]
• Jon Masters and Chris Tyler, on the ARM architecture in Fedora [ogg]. ARM is a secondary architecture today. By Fedora 18, with your help, it needs to become a primary architecture.
• David Nalley presented on CloudStack, which is aiming for Fedora 17 inclusion. [ogg]
• Dan Prince and Russell Bryant giving an introduction to OpenStack [ogg]
• Mo Morsi presenting the Aeolus cloud management project [ogg]

[Update 1/18/2012] I was able to upload all the videos to YouTube. http://www.youtube.com/playlist?list=PL2BAA7FF83E6482C2
is a playlist with all 6.

15 Jan 2012 5:50pm GMT

I mentioned it briefly before: I've designed a small E1/T1/J1 transceiver board, which is going to be used for experimentally interfacing such a TDM line with microcontroller and/or FPGA. The name of this board is osmo-e1-xcvr.

The first prototype PCBs have arrived yesterday, and despite lots of other more important work I couldn't resist but to actually solder some of the units. The result can be seen here:

I don't have time to do anything beyond very basic testing right now, but so far the boards seem to be doing fine. Now we need a driver for the transceiver chip, and connect its control interface over SPI to some microcontroller (likely sam7s/sam3s/sam3u in my case). The actual serial bitstream will end up at the SSC peripheral of the controller.

14 Jan 2012 1:00am GMT

I thought it would be easier to do a round of stable kernel releases in the middle of the larger kernel merge window, to prevent the next round from being so big (given that there are a lot of patches usually applying during the -rc1 merge window cycle).

So, I've now done:

• Linux 2.6.32.54-rc1 release
• Linux 3.0.17-rc1 release
• Linux 3.1.9-rc1 release
• Linux 3.2.1-rc1 release

Please go test and let me know if there are any problems with any of these kernels. If I've missed any patches that you feel should be in them, also please let me know.

Note, this is most likely going to be the LAST 3.1.y kernel release, so please move off to the 3.2 kernel at this point in time. Maintaining so many different kernel branches all at once is not trivial, and I want to minimize it if at all possible.

10 Jan 2012 10:54pm GMT