kernel news – 22.02.2013

Posted: February 22, 2013 in kernel

-Martin Schwidefsky has s390 patches for the merge window:

The most prominent change in this patch set is the software dirty bit
patch for s390. It removes __HAVE_ARCH_PAGE_TEST_AND_CLEAR_DIRTY and
the page_test_and_clear_dirty primitive which makes the common memory
management code a bit less obscure. Heiko fixed most of the PCI related
fallout, more often than not missing GENERIC_HARDIRQS dependencies.
Notable is one of the 3270 patches which adds an export to tty_io to
be able to resize a tty. The rest is the usual bunch of cleanups and
bug fixes.

There is a merge conflict in arch/s390/Kconfig between the current
upstream and the s390 branch. The cause is the Heikos Kconfig sorting
vs the removal of HAVE_IRQ_WORK. The correct merge is the sorted list
without the HAVE_IRQ_WORK select.

-Jiri Kosina updates trivial and HID:

– new support of a group of Win7/Win8 multitouch devices, from Benjamin
Tissoires
– fix for compat interface brokenness in uhid, from Dmitry Torokhov
– conversion of drivers to use hid_driver helper, by H Hartley Sweeten
– HID over I2C transport received ACPI enumeration support, written by
Mika Westerberg
– there is an ongoing effort to make HID sensor hubs independent of USB
transport. The first self-contained part of this work is provided here,
done by Mika Westerberg
– a few smaller fixes here and there, support for a couple new devices
added

-Takashi Iwai has sound updates for -rc1:

The biggest change in this update is the unification of HD-audio codec
parsers. Now the HD-audio codec is parsed in a generic parser code
which is invoked by each HD-audio codec driver. Some background
information is found in David Henningsson’s blog entry:
http://voices.canonical.com/david.henningsson/2013/01/18/upcoming-changes-to-the-intel-hda-drivers/

Other than that, some random updates/fixes like USB-audio and a bunch
of small AoC updates as usual.

-Greg KH has updates for driver-core:

There are two major series here, both of which touch lots of drivers all
over the kernel, and will cause you some merge conflicts:
– add a new function called devm_ioremap_resource() to properly be
able to check return values.
– remove CONFIG_EXPERIMENTAL

-The same Greg Kroah-Hartman announces kernels 3.0.66 and 3.4.33.

-Yet the same Greg has tty/serial and char/misc patches:

Here’s the big tty/serial driver patches for 3.9-rc1.

More tty port rework and fixes from Jiri here, as well as lots of
individual serial driver updates and fixes.

All of these have been in the linux-next tree for a while.
##########################################################
Here’s the big char/misc driver patches for 3.9-rc1.

Nothing major here, just lots of different driver updates (mei, hyperv, ipack,
extcon, vmci, etc.).

All of these have been in the linux-next tree for a while.

-David Howells updates linux-trace, and I recommend you read this if
you’re into EFI booting :

It provides a facility by which keys can be added dynamically to a kernel that
is running in secure-boot mode. To permit a key to be loaded under such a
condition, we require that the new key be signed by a key that we already have
(and trust) – where keys that we “already have” could include those embedded in
the kernel, those in the UEFI database and those in cryptographic hardware.

Now, “keyctl add” will already handle X.509 certificates that are so signed,
but Microsoft’s signing service will only sign runnable EFI PE binaries.

We could require that the user reboot into the BIOS, add the key, and then
switch back, but under some circumstances we want to be able to do this whilst
the kernel is running.

The way we have come up with to get around this is to embed an X.509
certificate containing the key in a section called “.keylist” in an EFI PE
binary and then get the binary signed by Microsoft. The key can then be passed
to the kernel by passing the signed binary:

keyctl padd asymmetric “” {ID of .system_keyring} flags:

KEY_FLAG_TRUSTED – this key is trusted.

KEY_FLAG_TRUSTED_ONLY – only links to trusted keys can be made to this
keyring.

I’m not sure that this is the best mechanism by which to filter keyring
additions, but it’s not currently visible to the user, and so can be changed.
One thing we might want to consider is using X.509 extension fields to contain
bitfields that indicate what is permitted of the key inside an X.509
certificate. These contribute to the X.509 cryptographic digest and so are
secure.

What these patches then do is allow you to add new keys by signing them with a
key a user will already have. There can be more than one source for these
keys: firstly, there is a key built into the kernel for module signing
purposes, and secondly, we have patches under development for extracting keys
from the UEFI signature database.

Note: Though we don’t actually execute the PE binary container to get at the
key, the binary must be executable in the EFI environment for Microsoft to sign
it.

The test wrapper I’m using is this:

#include
#include

EFI_STATUS
efi_main (EFI_HANDLE image_handle, EFI_SYSTEM_TABLE *systab)
{
InitializeLib(image_handle, systab);
Print(L”This program contains a list of public keys.\n”);
return EFI_SUCCESS;
}

extern __attribute__((section(“.keylist”))) const uint8_t certificate_list[];
extern __attribute__((section(“.keylist”))) const uint8_t certificate_list_end[];
asm(“.section .keylist,\”a\”\n”
“certificate_list:\n”
“.incbin \”signing_key.x509\”\n”
“certificate_list_end:”
);

and is built from pekey.c by something like this:

CPPFLAGS := -nostdinc -I /usr/include/efi -I /usr/include/efi/x86_64

CFLAGS := -O2 -fpic \
-Wall -fshort-wchar -fno-strict-aliasing \
-fno-merge-constants -mno-red-zone

LDSCRIPT := /usr/lib64/gnuefi/elf_x86_64_efi.lds
CRT0 := /usr/lib64/gnuefi/crt0-efi-x86_64.o
X509 := magrathea
KEY := /data/modsign/linux-modsign/signing_key.priv

pekey.efi.signed: pekey.efi
pesign -i $< -o $@ -c $(X509) -p $(KEY) -s -f

pekey.efi: pekey.so
objcopy \
-j .text -j .sdata -j .data -j .dynamic -j .dynsym -j .rel \
-j .rela -j .reloc -j .keylist –target=efi-app-x86_64 $< $@

pekey.so: pekey.o
$(LD) -nostdlib -T $(LDSCRIPT) -shared -Bsymbolic $(CRT0) $< -o $@ \
-L /usr/lib64 -lefi -lgnuefi \
-L /usr/lib/gcc/x86_64-redhat-linux/4.7.2 -lgcc

pekey.o: pekey.c Makefile
$(CC) $(CPPFLAGS) $(CFLAGS) -c $< -o $@

-Arnd Bergmann announces 3.9 changes for arm-soc:

Here is the usual arm-soc set of pull requests. There is a total
of 645 non-merge changesets, which this time is dominated by the
sh-mobile platform cleanups in size. In the effort to modernize
the way that ARM platform code is structured, sh-mobile has been
a little late to the game, but they are making up for that now.

Another topic that keeps both the patch count and the total
number of changed lines high is the work to remove platform
specific header files. This will keep going on for at least
one or two releases I fear, but we are already seeing the
fruits of it, and now have a total of 18 platforms that started
out separately and can now be built as ‘multiplatform’ together
with others.

We have reduced the number of separate branches for you a bit,
trying to make things easier for us, and getting fewer conflicts
between the arm-soc branches. These nine branches contain all
the important changes, but there are three more branches with
stuff that came late before the merge window. If everything
goes well, we will send pull requests for those next week,
or leave them for 3.10 if there are problems.

Olof has done almost all the merges again for this round,
since I was on parental leave for half the time, but I’m
sending out the pull requests now since he is currently at
ELC.

The merge conflicts I mention in the tags are all for conflicts
between the arm-soc branches. There are a few more conflicts
with other stuff you already pulled, but it all looks simple
as well. I have uploaded a ‘for-linus’ branch to the arm-soc
tree with the resolutions I used.

-Bob Liu has blackfin updates, Vinod Koul updates slave-dmaengine

This is fairly big pull by my standards as I had missed last merge window.
So we have the support for device tree for slave-dmaengine, large updates to
dw_dmac driver from Andy for reusing on different architectures. Along with this
we have fixes on bunch of the drivers

and H. Peter Anvin updates x86/microcode.

-Vineet Gupta introduces arch/arc (Synopsys ARC) CPU support for -rc1:

I would like to introduce the Linux port to ARC Processors (from Synopsys) for
3.9-rc1. The patch-set has been discussed on the public lists since Nov and has
received a fair bit of review, specially from Arnd, tglx, Al and other subsystem
maintainers for DeviceTree, kgdb …..

The arch bits are in arch/arc, some asm-generic changes (acked by Arnd), a minor
change to PARISC (acked by Helge).

The series is a touch bigger for a new port for 2 main reasons:
1. It enables a basic kernel in first sub-series and adds ptrace/kgdb/.. later
2. Some of the fallout of review (DeviceTree support, multi-platform-image
support) were added on top of orig series, primarily to record the revision history.

-Greg KH again with USB patches aimed at -rc1:

Nothing major, lots of gadget fixes, and of course, xhci stuff.

All of this has been in linux-next for a while, with the exception of
the last 3 patches, which were reverts of patches in the tree that
caused problems, they went in yesterday.

-James Bottomley announces the first round of SCSI updates, and this concludes
today’s news.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s