I’ve finally found reliable workarounds for a long-standing issue where my Intel MacBook doesn’t work with most projectors.
The error message when trying to use xrandr to force output via VGA looks like:
$ xrandr --output VGA --auto xrandr: cannot find crtc for output VGA
It seems the driver has a bug where it thinks it has the hardware available to drive the LCD panel, DVI and analogue VGA outputs at the same time, when it can in fact only handle two of these. xrandr shows three displays enabled:
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1280 x 1280 VGA connected (normal left inverted right x axis y axis) 1024x768 60.0 800x600 60.3 640x480 59.9 LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) 286mm x 179mm 1280x800 59.9 + 1024x768 60.0* 800x600 60.3 640x480 59.9 TMDS-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0* 800x600 60.3 640x480 59.9 TV disconnected (normal left inverted right x axis y axis)
I’m guessing this might have something to do with both analogue and digital signals being sent out the same connector. In any case, the fix is to disable ‘TMDS-1′.
This can be done during an active session:
$ xrandr --output TMDS-1 --off $ xrandr --output VGA --auto
The X server can also be configured to disable ‘TMDS-1′ during startup. On F10, you need to first create an xorg.conf. I ended up doing this:
# yum install system-config-display # system-config-display
and just quit, which seems to cause
/etc/X11/xorg.conf to be generated.
I edited the file, adding the “Option” line to the “Device” section:
Section "Device" Identifier "Videocard0" Driver "intel" Option "monitor-TMDS-1" "dvi" EndSection
then, I added this section:
Section "Monitor" Identifier "dvi" Option "Disable" "true" EndSection
which all seems to work ok for me and is about as obvious as quantum supergravity.
LCA has been great fun so far — more later.
I’m preparing to travel to Hobart for LCA next week, which will be a refreshing break from the 40° heat in Sydney, and from conference jet lag—this will my first same-timezone conference in a couple of years, and the closest I’ve ever been to Antarctica.
With increased use of virtualization, one security benefit of physically separated systems — strong isolation — is reduced, an issue which may be ameliorated with the application of MAC security (e.g. SELinux, SMACK) in the host system.
For example, a flaw in the hypervisor or errant misconfiguration of the host may allow a virtualized guest OS to “break out” into the host environment and compromise other guests. By applying MAC security to virtual machine instances at the host level, such threats may be mitigated through strong isolation and containment of guests.
If you think hypervisor flaws are merely some kind of theoretical threat, you’re dreaming. A large number of folk seem to be entirely unware of virtualization security issues, according to Joe Hernick of Network Computing:
To find out how prepared our readers are, we fielded a survey—and got some eye-popping results. We can’t help thinking that the 43% saying they feel virtualized machines are just as safe and secure as traditional environments are whistling past the graveyard. Of the 384 IT operations and security professionals responding, a mere 11% have put formal strategies in place to protect their VMs.
Hyperbole aside, people who are deploying virtualized systems definitely need to start thinking about this stuff.
The sVirt project is currently in initial development, with the aim of making a v1.0 release shipping this year in Fedora. A key feature of the initial release will providing simple MAC isolation of KVM domains, so virtualized systems can’t attack each other or the host system.
While Dan Walsh gave an ad-hoc talk on the subject last week at Fudcon in Boston, and I gave an ad-hoc lightning talk at Foss.my, this will be the first planned presentation properly outlining the goals, architecture and implementation strategy; and how this is part of extending flexible MAC security across every level of the modern application stack from the local OS to the globally distributed environment (cloud, grid et al). There’s no shortage of interesting and bizarrely difficult problems to solve in this area. Or buzzwords.
LCA looks to be a fun conference this year, if not perhaps a little subdued due to the economic crisis (and hopefully nothing to do with Tasmania being the world’s leading producer of pharmaceutical opiates).
Talks I hope to see include:
- AIO: Why is this so hard? (Zach Brown)
- Using a Malicious User-Level RCU to Torture RCU-Based Algorithms (Paul McKenney)
- Geek my Ride (Jon Oxer and Jared Herbohn)
The organizers have just announced mystery prizes for folk registering in the final week, so if you’re yet to decide whether to attend, there’s some more encouragement.
This is to announce a kernel security subsystem wiki, supported by the kind folk at kernel.org. It’s intended for use by community developers and users of kernel security projects. So far, there are sections on working with the security-testing git repo, a listing of various kernel security projects, and an events page. If there’s something you’d like to see or change on the wiki (particularly if it relates to your own project), create an account and make it so.
Note that this wiki is not related to security response: the security incident contact for the kernel per the MAINTAINERS file is security @ kernel.org.
Version 2.6.28 of the Linux kernel was released during Christmas, so I thought it’d be worthwhile waiting until after typical vacation days to post a summary of changes to the security subsystem. As always, thanks to the Kernel Newbies folk who track major kernel changes.
- Dummy SELinux policy support
Serge Hallyn added a dummy policy for SELinux to the kernel tree. This is useful for testing SELinux and a base for building minimal and experimental security policies.
- Bouned per-thread security contexts for SELinux
KaiGai Kohei submitted a patch which allows different threads in a process to be labeled with distinct security contexts. Such threads are guaranteed to not exceed the security policy permissions of the parent process. This is part of his work in extending SELinux to the web application stack, and in this case, is aimed at constraining in-process web server scripts (e.g. mod_python applications).
- Labeled networking updates
Paul Moore provided a series of updates to the Labeled networking subsystem, which he promises to document on his blog.
- MAC policy for privilege in Smack
Casey Schaufler extended Smack so that MAC policy may be used to limit the use of privilege. Previously, the Smack model maintained strict orthogonality between privilege and access control, where privileged processes were exempted from MAC policy enforcement. This feature allows for MAC policy enforcement of processes running with specific security label (as written to
/smack/onlycap), or for all processes if the
onlycaplabel is specified as ‘*’.
- TPM updates
Rajiv Andrade provided several updates for the TPM driver.
This was not a terribly exciting release for the security subsystem.
Thus far for the 2.6.29 kernel, the main change is the massive credentials API change from David Howells. This has caused a couple of regressions, which were picked up by subsystem testing of Linus’ tree. Fixes have been developed and are currently partially merged upstream. It seems we need to get more testing done in linux-next to avoid such breakage during future merge windows.
Also noteworthy is the merge of the pathname security hooks for LSM, which should pave the way for TOMOYO and AppArmor in 2.6.30, subject to the general patch submission review process. TOMOYO is only a couple of acks from approval, has been baking in -mm, and is pretty much self-contained. It may even appear in 2.6.29 if the merge window is open for features long enough.
Commits to the master git repo are sent via gregkh’s bti, using the following script as the $repo/hooks/post-receive hook:
read oldrev newrev refname
/usr/bin/git rev-list $oldrev...$newrev --no-merges --pretty=format:"%h|%ae|%s" --abbrev-commit | grep -v ^commit |
while read a; do
echo "$short_refname|$a" | cut -f-140 | ~/bin/bti
It may not scale too well, but it’s simple. Suggestions for improvement are welcome.
Unrelatedly, here’s a short video I took of a long train in Bangalore:
Some observant folk may have noticed that I’m now listed as the kernel security subsystem maintainer. This came about as a result of the growing number of security projects headed upstream, and recent comments from Linus and Andrew about the lack of a clear security maintainer. In some ways, this is a formalization of the role I’d been performing with the security-testing tree, although of course the workload and responsibility levels will increase.
I’d like to thank Chris Wright, Casey Schaufler and Stephen Smalley for their endorsements and support in this, and I’m expecting that all in the kernel security community will continue forward in a collaborative approach. I consider previous discussions on architecture resolved.
For new security components being proposed for upstream merge, I’d like to generally follow the protocol outlined by Arjan van de Ven and summarized at KernelTrap: Documenting Security Module Intent.
Essentially, any new security project—not limited to LSMs—should be accompanied by a clear and concise document outlining its requirements and expected uses. This is to allow both security and regular folk to perform review of the code in terms of how it meets the specified requirements, and to avoid getting bogged down in unresolvable discussions about the project’s security model.
A good example of how such an approach has helped is with the recent anti-malware scanning project, which rapidly went from zero to hero in a few weeks following elucidation of design goals. The project now has buy-in from several core developers and has led to fsnotify, a unification and overhaul of the various filesystem notification schemes in the kernel.
The design document does not need to be a novel: a page or two should be enough, and certainly as much as you’d expect upstream developers to read first-up.
FOSS.IN has certainly changed a lot since I first attended in 2005, where there were several thousand delegates, an expansive talks programme, and a significant commercial presence with a dedicated trade hall. Since then, and particularly following this year’s omlette post, the organizers have been nudging the conference toward an increasingly technical and participatory event.
This year, somewhat following the example of the Plumbers Conference, the core of FOSS.IN became workout sessions, with fewer traditional conference talks. The aim, according to the organisers, is to provide Indian developers with access to a dedicated technical event similar to the experiences available to FOSS developers in North America and Europe.
Approximately a thousand delegates registered, although I’d estimate that there were typically around three to five hundred people present during the course of the conference. One of the organizers noted that in previous years, the crowd of delegates would change from day to day, reflecting each days programming, but that this year, the crowd was essentially the same throughout.
While there were several standalone talks, this was not an event aimed at a passive audience. From my observations, the main action was found in active participation in workout sessions, BoFs, and ad-hoc hacking gatherings. It seemed that wherever there was a power outlet, you’d find a small group of people gathered with laptops, working on something.
There was a major KDE presence at the conference, although most of my time was spent involved in kernel-related events. I heard that a KDE theme song was composed, performed and recorded at the conference, so I wonder if this may be the first FOSS conf to create and ship a conventional work of art.
Around two weeks before the conference started, the organizers allocated a day to a then yet-to-be-defined Linux Kernel Hacker Gathering, asking kernel folk to “organize something”. Several emails later, with a growing cc: list and finally a small mailing list set up by Harald, a basic outline was determined. A planning meeting was organized for the Monday before the conference at the IBM Bangalore campus. Details of the Kernel Workout were also finalized there.
The LKHG event started on Friday with a series of talks on various kernel topics by upstream developers, then opened up for a series of lightning talks from delegates, and finished with an open discussion. There weren’t as many lightning talks as were hoped for, which was not unreasonable given the excessively short lead-time for the CfP. For this to work better in the future, I’d suggest having a much longer lead-time, and more publicity aimed specifically at kernel developers working outside of the upstream process, to engage such folk with the wider community. There were still some very good discussions around the relatively few lightning talks, in any case.
The kernel workout session was then held the following and final day. It appeared to succeed beyond expectations, largely due to the planning which happened in the few available days beforehand. Getting the word out on the prerequisites was critical. In this case, to participate, you had to be ready to hit the ground running with an already checked-out source tree on your laptop, which you knew how to build and run. Following that, it was a matter of choosing something from the set of tasks selected by the organizers, and asking for help from mentors if needed. There was also a preparatory session before the workout for people to get set up, although I missed that as I was giving a different talk at the time. Many of the major upstream Indian kernel hackers were there as mentors, so it was definitely the place to be to really get into things.
The results of the workout have been published on the workout wiki. As of writing, several patches from the workout have now been accepted into the kernel. Some were already posted and receiving review before the end of the workout.
Earlier that day, I gave a talk on Fedora Kiosk Mode. It’s useful now to have a high-level application such as this to demonstrate an application of modern MAC security. Thus far, it’s been difficult to communicate the benefits of generalized MAC in theoretical terms. It’s clear from the example of Kiosk Mode that MAC does not need to be complicated if abstracted correctly, and that it can provide desirable and useful benefits to everyday users. There’s a lot more to come in this area, too.
A particular highlight of the conference was the closing keynote by Kalyan Varma, which turned out to be probably the best talk I’ve ever seen on any topic. I knew it was something to do with photography, but I had no idea what was in store: a linking of ideas as diverse as FOSS community principles; amusing security hacking demonstrations; photographing new species; having your work exhibited at the London School of Economics; working with the BBC and David Attenborough; getting a cheque from the makers of Snakes on a Plane for using one of your Creative Commons flickr photos; and what this all has to do with drinking tea and saving the environment. Harald has also written about the talk. I hope the video of the talk is published online soon, and I really wouldn’t be surprised to see Kalyan presenting it at TED.
Overall, I greatly enjoyed the conference, and feel that I’d generally prefer to attend these kinds of working conferences in the future. Given the overheads involved in travel (productivity hits in particular), the traditional “famous people get up and talk about how great they are” talk-based conferences are decreasingly compelling. It’s great to meet up with folk I’ve been working with online, but even greater to do so in the context of getting useful development-related tasks done.
A huge thanks to the team for letting me be part of this amazing event. There was certainly no shortage of challenges for them this year, and they ensured that everyone who put something into the conference got a lot more back out.
I’m on my way back from FOSS.IN, waiting for a connecting flight to Sydney in Singapore on a hearty three hours sleep.
Here’s a flickr photoset.
I ended up getting a photo of nearly every mainline kernel hacker from India (with the notable exception of Dipankar, who was on vacation).
The above is a shot from the Linux kernel workout session, which resulted in several useful improvements and bugfixes for the kernel, some of which are already making their way upstream.
More details on the conference later.
It’s the end of the first day of FOSS.IN/2008, with people at the speakers hotel continuing to hack on various projects late into the night (11:30pm at this stage).
I’ll provide more detailed observations on the conference after it’s over; for now, some information on the Linux Kernel Workout session scheduled for Saturday.
For people wishing to attend:
There’s now a wiki page for the workout, detailing tasks to be addressed, as well as prerequisites for participation. Please read and follow the latter. You will need a git checked-out kernel tree which has been configured and boot tested on your laptop. Don’t try and do this on the day, as there will not be enough time, nor enough wireless bandwidth.
You should probably also attend the Linux Kernel Hacker Gathering on the Friday, the schedule for which is being finalized, and will help prepare for the workout session.
Here’s Harald Welte from his GSM hacking workout session today. Note that he’s evolved to the stage where he simply emanates code. Either that, or he’s sitting in front of the projector.