I am finally able to publish the traditional interview about the recent OpenBSD release.
OpenBSD 4.5was released on May 1st, so I am very late and also the interview is shorter than usual, but this has to do with my unstable health condition.
I would like to thank all the developers that were kind enough to answer my questions even if asked so late, also the developers that were writing code at the recent Hackathon, and obviously all the developers at large that built this nice release.
Let's begin...
How does this release sound? :)
Jacob Meuser:Full, clear and multidimensional ;)
S/PDIF output support was added to the ac97(4) layer and is used by auvia(4) and auich(4). Support for 4 and 6 channel playback was added to auich(4). A recording bug that affected many auvia(4) devices was fixed.
There was a lot of work done to azalia(4) in this release cycle as well. The HDA/Azalia specification is very interesting. It defines a set of widgets from which an audio codec can be constructed, and the codec can be queried for its properties. This theoretically allows for a wide range of devices to all work under one driver.
However, the specification is complex and it leaves some things to be "vendor defined". In addition, some important properties of the codec are actually set by the system BIOS on boot, so the same codec in one machine may actually be functionally quite different on another machine.
As of OpenBSD 4.4, the azalia(4) driver had fairly poor generic codec support, along with much codec/BIOS dependent code. I decided that continuing to add codec dependent code was simply not maintainable, and focused on making the generic support work everywhere, as it is supposed to.
As of OpenBSD 4.5, the azalia(4) driver has very little codec dependent code, and the support on most codecs is far superior to what it was in 4.4, even those that had complete codec/BIOS dependent support.
The following features are now generically supported by azalia(4). They were either not supported at all or only partly supported by codec dependent code:
- jack sense speaker muting
- jack retasking
- multichannel playback/recording
- S/PDIF output
- 20 and 24-bit playback and recording
But probably the biggest improvement is a more usable mixer interface. One of the biggest complaints was that there were too many controls. This problem was addressed in several ways. First, the controls that did nothing were removed. Then mixers were "collapsed" from having several mute controls, to having a single control that uses a set. And finally, widgets were grouped together. On some machines, the list of mixer controls shrank by over 50%.
Oh, I lied, the biggest improvement is that now all azalia(4) have an outputs.master control. By far the biggest complaint for azalia(4) was, "I can't change the volume". There are a few codecs that simply have no volume control, but otherwise, there is volume control that should work with keyboard volume keys as well as the mixer GUIs in ports.
sio_open(3) documents a new audio API, what is it?
Alexandre Ratchov:Roughly, it's aimed to become the main OpenBSD API for audio. It's used by applications to play and record audio streams.
The main goal of the API is to overally simplify audio. Simpler audio API means simpler code, less bugs and more robustness. The API also unentangles the application internals from the audio subsystem internals. This allowed using aucat(1) as an audio server.
Audio applications must be ported to the new API in order to benefit from new audio features. This may seem a lot of work. Actually it ends up that often it's simpler to port the application to the sio_open(3) API than trying to fix subtle design bugs. Still work is in progress.
There has been a lot of work on aucat(1). What features does it provide in this release?
Alexandre Ratchov:aucat(1) now has server capability and is integrated in the audio subsystem as a minimalistic audio server. Basically, audio applications communicate with aucat(1) and aucat(1) communicates with the physical device, processing audio data on the fly. This imports all aucat(1) features into the audio subsystem:
- resampling and conversions: now applications that don't support device's encoding or sample rate can work. Useful on fixed-rate devices or devices with unusual encodings.
- mixing: multiple applications can play on the same audio device simultaneously
- demultiplexing: multiple applications can record from the same device (handy for monitoring)
- multistreaming: channel ranges of an audio device can be configured to appear as independent devices. For instance headphones and speakers on 5.1 devices can be configured to appear as separate audio devices.
The new sio_open(3) API, makes aucat(1) server transparent for applications. If the server is running then, applications will use it, else they will use the audio(4) device.
The audio server approach helps moving CPU intensive code (resampling, conversions) from the kernel to userspace, improving responsiveness of interactive applications.
The protocol used by aucat(1), implements timing messages, allowing to very precisely synchronize audio to something else, or to enforce desired latency requirements.
What changed in the ports and packaging system?
Marc Espie:As far as the tools go, not much actually changed: packages now internally use sha256 for all file checksums instead of md5, so no part of the ports/packages system relies on md5 these days (which is now to be seriously broken).
The truth of the matter is that I'm working on bigger changes, but they were not ready before 4.5, so I'll have a lot more to say for 4.6 ;-)
For packages, the biggest change is probably Alex Ratchov and Jacob Meuser's work: they wrote a new simpler and better frontend to the audio subsystem. As usual in OpenBSD, new and sexy things like that don't count unless somebody uses them, and there was a rampage throughout the ports tree to convert most ports to the new subsystem. So, in 4.5, most audio ports go through libsndio, and as a result, they can be mixed together.
The other important thing is that a lot of people pitched in to ensure more packages for more exotic architectures, so you'll probably be surprised to see that arm (for instance) has a heck of a lot of compiled packages this release.
What is new in OpenBSD/sparc64?
Mark Kettenis:The most exciting new functionality in 4.5 for OpenBSD/sparc64 is that we now support virtual I/O on sun4v through the vdsk(4) and vnet(4) drivers. This means that it is now possible to run OpenBSD in a logical domain on machines with UltraSPARC T1, T2 and T2+ processors. On some of Sun's CoolThreads servers, you can even give a logical domain running OpenBSD access to real hardware. This makes it possible to run a pf firewall on the same machine as the services you're trying to protect, without compromising security. Those services could even be hosted on a logical domain running Solaris.
There are also quite a few improvements in our support for real hardware, including an accelerated framebuffer driver for Sun Expert3D, Expert3D-Lite, XVR-500, XVR-600 and XVR-1200 framebuffers and a matching X driver.
How is your work on Xenocara going on?
Matthieu Herrb:Some progress have been made, although not as good as I would have expected. OpenBSD 4.5 ships with xserver 1.5.3, recent versions of most graphics cards drivers, libraries and utilities. I've also prepared the way to make importing new releases of X components easier in the future.
Owain as done lots of great work to fix bugs in drm and Mesa drivers on Intel and ATI chips so Xenocara now has good 3D support on mainstream drivers.
There are a few prolems though. The most proeminent one is that X.Org developers broke multi-card based multi-head support in xserver 1.5 (not only on OpenBSD) and although I tried to fix it (with help of other developers), it is still broken and will probably stay broken until all the work on porting GEM and kernel side mode-settings to OpenBSD is done.
What is the status of the sensors framework?
Constantine A. Murenin:The sensors framework would not be the same without the drivers. As always, with this release cycle we've had a number of drivers introduced to the sensors framework. Users ofcac(4)andmpi(4)RAID controllers would be happy to find the newly added bio and sensor support. There are also two brand-new drivers:gpiodcf(4)for timedelta sensors through GPIO pins andschsio(4)for SMSC SCH311x series of Super I/O Hardware Monitors.
Out of the existing sensor drives we can note the newly added support for the integrated temperature sensors of the AMD Family 11h processors inkm(4), which, amongst others, covers the processors marketed under theTurion X2 Ultrabrand; additional chip support was added init(4),lm(4),owtemp(4)andsdtemp(4), and some bug fixes were made init(4)andlmenv(4).
Overall, with this release there are now 72 drivers that are exposing sensors with thesensordev_install(9)API. Taking the opportunity, I'd like to point out that an overview of the sensors framework as of OpenBSD 4.5 has been recently presented at AsiaBSDCon 2009, and aformal paper [PDF]has been written and made available.
It seems you have worked on disklabel to improve its support for different filesystems and devices. Would you like to tell us more?
Kenneth R Westerback:Joel Sing pointed out at h2k8 that SGI could not create a CD that would boot and provide FFS filesysstems. This was preventing the creation of CD install media for SGI. One of the many interesting changes that resulted from fixing this was making the reading and writing of disklabels sector size agnostic. Disklabels, which are only 512 bytes in size, are now correctly placed and found inside larger sectors.
Another improvement to disklabel handling was the refinement of FAT and FAT32 filesystem recognition. Camera, phone and removable media manufacturers continue to create FATxx filesystems on their devices that have an absolutely minimal amount of metadata. And every company has their own idea of minimal of course! This makes trying to do sanity checks on such filesystems a problem. This time around we fixed the handling of filesystems found on some SDHC cards.
The most significant fix to disklabel processing was preventing the writing of disklabels with incorrect checksums on systems using MBR or DPME disk partitioning. This was occuring because the code 'spoofing' native partitions was modifying a disklabel being written even though it did not need to.
Finally, disklabels constructed from an architecture specific native disklabels are now subject to the same consistancy checks as all other disklabels."
What is ypldap(8)? When should we use it?
Alexander Schrijver:ypldap(8) is part of LDAP support in OpenBSD. It works by talking the YP protocol (like ypserv(8)) using data replicated from an LDAP directory.
ypldap(8) currently doesn't support the netid.byname map, which is needed by the getgrouplist(3) function. This makes ypldap(8) currently only useful for testing purposes, or if all you need to use is the passwd.by{name,uid} and group.by{name,gid} maps. Testing is of course important for the further development of ypldap(8).
Implementing the netid.byname map turned out to be quite difficult to do properly. And the proper solution hasn't been found yet.
Why have you added to resolver(3) the possibility to be forced to perform lookups by TCP only? How can this behaviour be configured?
Damien Miller:It is sometimes handy to perform name resolution via TCP, in particular it allows forwarding lookups over an SSH tunnel. For this reason, I also added the ability to specify a port number to a resolv.conf(5) nameserver option, e.g. "namesever [127.0.0.1]:5300"
Unfortunately, some programs (e.g. firefox) implement their own name resolution and need to be extended to support the new options.
This release includes OpenSSH 5.2. What's new in this version?
Damien Miller:openssh-5.2 is mainly a bugfix release, after openssh-5.1 added many features and invasive bugfixes. The most notable fixes we added were to mitigate the attacks againstCBC mode ciphers-- these are basically infeasible now. We also repaired a number of bugs that were introduced or exposed by the 5.1 release.
How does the new attack mitigation measure implemented in malloc(3) work?
Damien Miller:There are two main protections that are implemented. First, the data structure that contains the malloc options (set via /etc/via malloc.conf or the MALLOC_OPTIONS environment variable) is now protected against moditication once it has been initialised. This protection involves changing its memory mapping so that it is read-only. This stops an attacker from turning off the default abort-on-failure as part of an attack.
The second protection is to allocate the main malloc bookkeeping structure (struct dir_info) at runtime using mmap, and to wrap it in two "guard pages". Attacks on heaps generally rely on corrupting this bookkeeping information, so it is worth protecting it. Mapping it at runtime ensures that it will have an unpredictable address that will make attacks less deterministic (previously it was a predictable location relative to other malloc data structures).
The guard pages are memory regions mapped with neither read nor write access (via mprotect(2)'s PROT_NONE), will cause a segmentation fault on any attempt to read or write them. This makes it more difficult to clobber the structure, as the attacker will need to hit the precise page in which it lives.
Federico Biancuzziis a freelance interviewer. He is co-author of "Masterminds of Programming - Conversations with the Creators of Major Programming Languages", a book published by O'Reilly.
[版权声明]BSD爱好者乐园站内文章，如来源不是互联网，则均系原创或翻译之作，可随意转载，或以此为基础进行演译，但务必以链接形式注明原始出处和作者信息，否则属于侵权行为。另对本站转载他处文章，俱有说明，如有侵权请联系本人，本人将会在第一时间删除侵权文章。
TAG: openbsd OpenBSD