September 2013 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] BtrFS as default fs?
by Jeff Mahoney 12 Sep '13

12 Sep '13

Hi all - Last month I posted queries to this list (and several other locations, including the forums) asking about people's experiences with btrfs. For the most part it seemed like the experience had improved over time. Most of the concerns were either with interactions with zypper or old perceptions of instability that were based more on old impressions than new testing. With the exception of an ENOSPC issue that had been recently fixed, users actively using the file system seemed pretty satisfied with it. I posted a followup question a week or two later asking what people thought about limiting the 'supported' feature set in the way we do in SLES so that it's clear to all users which parts of the file system are considered stable. A quick table of what that looks like: Supported Unsupported --------- ----------- Snapshots Inode cache Copy-on-Write Auto Defrag Subvolumes RAID Metadata Integrity Compression Data Integrity Send / Receive Online metadata scrubbing Hot add/remove Manual defrag Seeding devices Manual deduplication (soon) Multiple devices "Big" Metadata (supported read-only) Over time this table will change. Items from the Unsupported list will move to the Supported list as they mature. That proposal was pretty well received except, predictably, by those using the features listed. In practice, all that's required for those users to continue uninterrupted is to add the 'allow_unsupported=1' option to the btrfs module either on the kernel command line or /etc/modprobe.d. There is nothing inherently limiting to any openSUSE user with this practice. The features are all still in the code and available immediately just by setting a flag. It can even be done safely after module load or even after file systems that don't use the unsupported features have been mounted. I intend to introduce this functionality into openSUSE soon. One other aspect to consider: Even though they are independent projects, we've been focusing heavily on btrfs support in the SLES product. As a result, the openSUSE kernel will end up getting much of that work 'for free' since most of the same people maintain the kernel for both projects. So that's the "why it's safe" part of the proposal. I haven't gotten to the "why" yet, but then you probably already know the "whys". Subvolumes. Built-in snapshots that don't corrupt themselves when an exception table runs out of space. Built-in integrity verification via checksums. Built-in proactive metadata semantic checking via scrubbing. Online defrag. Soon we'll see online deduplication of arbitrary combinations of files. The code is written, it just needs to be pulled in. You've seen the rest of the feature set. Once we test more of it under load and ensure that it's mature enough to roll out, you'll get those features for free. So, I'd like to propose that we use btrfs as the default file system for the 13.1 release before we release the first beta. Thanks for your time. -Jeff -- Jeff Mahoney SUSE Labs

16 30

[opensuse-kernel] Update of Kernel:openSUSE-12.2
by Eugene Istomin 10 Sep '13

10 Sep '13

Hello, can you update OpenSUSE 12.2 kernels ( 3.4 LTS branch , https://build.opensuse.org/project/show/Kernel:openSUSE-12.2) to 3.4.60/3.4.61? Thanks. -- Best regards, Eugene Istomin -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 1

[opensuse-kernel] Re: openSUSE Build Service - Kernel
by Michal Marek 06 Sep '13

06 Sep '13

On 6.9.2013 10:55, Eugene Istomin wrote: > Hello sirs, > > > > can you update OpenSUSE 12.2 kernels ( 3.4 LTS branch , > https://build.opensuse.org/project/show/Kernel:openSUSE-12.2) to 3.4.60? Hi Eugene, such requests are best directed to the opensuse-kernel(a)opensuse.org mailing list. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 0

[opensuse-kernel] [RFC PATCH 00/18 v3] Signature verification of hibernate snapshot
by Lee, Chun-Yi 05 Sep '13

05 Sep '13

Hi experts, This patchset is the implementation for signature verification of hibernate snapshot image. The origin idea is from Jiri Kosina: Let EFI bootloader generate key-pair in UEFI secure boot environment, then pass it to kernel for sign/verify S4 image. Due to there have potential threat from the S4 image hacked, it may causes kernel lost the trust in UEFI secure boot. Hacker attack the S4 snapshot image in swap partition through whatever exploit from another trusted OS, and the exploit may don't need physical access machine. So, this patchset give the ability to kernel for parsing the RSA private key from EFI bootloader, then using the private key to generate the signature of S4 snapshot image. Kernel put the signature to snapshot header, and verify the signature when kernel try to recover snapshot image to memory. ============== How To Enable ============== Set enable the CONFIG_SNAPSHOT_VERIFICATION kernel config. And you can also choice which hash algorithm should snapshot be signed with. Then rebuild kernel. Please note this function need UEFI bootloader's support to generate key-pair in UEFI secure boot environment, e.g. shim. Current shim implementation by Gary Lin: Git: https://github.com/lcp/shim/tree/s4-key-upstream RPM: https://build.opensuse.org/package/show/home:gary_lin:UEFI/shim Please use the shim from above URL if you want to try. Please remember add the hash of shim to db in UEFI BIOS because it didn't sign by Microsoft or any OSV key. ========= Behavior ========= The RSA key-pair are generated by EFI bootloader(e.g. shim) in UEFI secure boot environment, so this function binding with EFI secure boot enabled. The kernel behavior is: + UEFI Secure Boot ON. Kernel found private key from shim: Kernel will run the signature check when S4. + UEFI Secure Boot ON. Kernel didn't find key from shim: Kernel will lock down S4 function. + UEFI Secure Boot OFF Kernel will disable S4 signature check, and ignore any keys from EFI bootloader. Unconditional allow hibernate launch. On EFI bootloader side, the behavior as following: + First, kernel will check the following 2 EFI variable: S4SignKey-fe141863-c070-478e-b8a3-878a5dc9ef21 [BootService] S4WakeKey-fe141863-c070-478e-b8a3-878a5dc9ef21 [Runtime][Volatile] S4SignKey and S4WakeKey is a RSA key-pair: - S4SignKey is a private key that's used to generate signature of S4 snapshot. The blob format of S4SignKey is PKCS#8 uncompressed format, it should packaged a RSA private key that's followed PKCS#1. - S4WakeKey is a public key that's used to verify signature of S4 snapshot. The blob format of S4WakeKey is X.509 format, it should packaged a RSA public key that's followed PKCS#1. + EFI bootloader must generate RSA key-pair when system boot: - Bootloader store the public key to EFI boottime variable by itself - Bootloader put The private key to S4SignKey EFI variable for forward to kernel. + EFI stub kernel will load the S4SignKey blob to RAM before ExitBootServices, then copy to a memory page to maintain by hibernate_key.c. This private key will used to sign snapshot when S4. + When machine resume from hibernate: - EFI bootloader should copy the public key from boottime variable to S4WakeKey EFI variable. - Bootloader need generates a new key-pair for next round S4 usage. It should put new private key to S4SignKey variable. + EFI bootlaoder need check the following EFI runtime variable for regenerate new key-pair: GenS4Key-fe141863-c070-478e-b8a3-878a5dc9ef21 The size of GenS4Key is 1 byte, OS(kernel or userland tool) will set it to "1" for notify efi bootloader regenerate key-pair. ============== Implementation ============== Whole implementation including 3 parts: shim, asymmetric keys and hibernate: + shim: Current solution implemented by Gary Lin: https://github.com/lcp/shim/tree/s4-key-upstream Please use shim from the above URL if you want to try. Please remember add this shim to db because it didn't sign by Microsoft or any OSV key. + Asymmetric keys: This patchset implemented uncompressed PKCS#8 and RSA private key parser, it also implement the signature generation operation of RSASSA-PKCS1-v_5 in PKCS#1 spec. [RFC3447 sec 8.2.2] Set CONFIG_PKCS8_PRIVATE_KEY_INFO_PARSER=y will give kernel the abilities to parsing private key in uncompressed PKCS#8 blob and generate signature. + Hibernate: Set CONFIG_SNAPSHOT_VERIFICATION=y will enable the function of snapshot signature generation and verification. I reserved 512 byes size in snapshot header for store the signature that's generated from the digest with SHA algorithms. For adapt S4 signature check to secure boot, I have porting 3 patches from Fedora kernel, authors are Josh Boyer and Matthew Garrett. I also add Cc. to them. Please help review this RFC patchset! Appreciate for any comments! v3: - Load S4 sign key before ExitBootServices in efi stub. - In Makefile, moved hibernate_keys.o before hibernate.o for load S4 sign key before check hibernate image. It makes sure the new sign key will be transfer to resume target kernel. - Set "depends on EFI_STUB" in Kconfig. v2: - Moved SNAPSHOT_VERIFICATION kernel config to earlier patch. - Add dummy functions to simplify the ifdef check. - Sent to opensuse-kernel(a)opensuse.org for review: http://lists.opensuse.org/opensuse-kernel/2013-08/msg00025.html v1: - Internal review - github: https://github.com/joeyli/linux-s4sign/commits/devel-s4sign Josh Boyer (1): Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode Lee, Chun-Yi (15): asymmetric keys: add interface and skeleton for implement signature generation asymmetric keys: implement EMSA_PKCS1-v1_5-ENCODE in rsa asymmetric keys: separate the length checking of octet string from RSA_I2OSP asymmetric keys: implement OS2IP in rsa asymmetric keys: implement RSASP1 asymmetric keys: support parsing PKCS #8 private key information asymmetric keys: explicitly add the leading zero byte to encoded message Hibernate: introduced RSA key-pair to verify signature of snapshot Hibernate: generate and verify signature of snapshot Hibernate: Avoid S4 sign key data included in snapshot image Hibernate: applied SNAPSHOT_VERIFICATION config to switch signature check Hibernate: adapt to UEFI secure boot with signature check Hibernate: show the verification time for monitor performance Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm Hibernate: notify bootloader regenerate key-pair for snapshot verification Matthew Garrett (2): Secure boot: Add new capability efi: Enable secure boot lockdown automatically when enabled in firmware Documentation/kernel-parameters.txt | 7 + Documentation/x86/zero-page.txt | 2 + arch/x86/boot/compressed/eboot.c | 121 ++++++++++ arch/x86/include/asm/bootparam_utils.h | 8 +- arch/x86/include/asm/efi.h | 9 + arch/x86/include/uapi/asm/bootparam.h | 4 +- arch/x86/kernel/setup.c | 7 + arch/x86/platform/efi/efi.c | 68 ++++++ crypto/asymmetric_keys/Kconfig | 11 + crypto/asymmetric_keys/Makefile | 16 ++ crypto/asymmetric_keys/pkcs8.asn1 | 19 ++ crypto/asymmetric_keys/pkcs8_info_parser.c | 152 ++++++++++++ crypto/asymmetric_keys/pkcs8_parser.h | 23 ++ crypto/asymmetric_keys/pkcs8_private_key.c | 148 ++++++++++++ crypto/asymmetric_keys/pkcs8_rsakey.asn1 | 29 +++ crypto/asymmetric_keys/private_key.h | 29 +++ crypto/asymmetric_keys/public_key.c | 32 +++ crypto/asymmetric_keys/rsa.c | 283 ++++++++++++++++++++++- crypto/asymmetric_keys/signature.c | 28 +++ include/crypto/public_key.h | 28 +++ include/keys/asymmetric-subtype.h | 6 + include/linux/cred.h | 2 + include/linux/efi.h | 18 ++ include/uapi/linux/capability.h | 6 +- kernel/cred.c | 17 ++ kernel/power/Kconfig | 77 ++++++- kernel/power/Makefile | 1 + kernel/power/hibernate.c | 37 +++ kernel/power/hibernate_keys.c | 329 ++++++++++++++++++++++++++ kernel/power/main.c | 11 +- kernel/power/power.h | 35 +++ kernel/power/snapshot.c | 345 +++++++++++++++++++++++++++- kernel/power/swap.c | 22 ++ kernel/power/user.c | 22 ++ 34 files changed, 1925 insertions(+), 27 deletions(-) create mode 100644 crypto/asymmetric_keys/pkcs8.asn1 create mode 100644 crypto/asymmetric_keys/pkcs8_info_parser.c create mode 100644 crypto/asymmetric_keys/pkcs8_parser.h create mode 100644 crypto/asymmetric_keys/pkcs8_private_key.c create mode 100644 crypto/asymmetric_keys/pkcs8_rsakey.asn1 create mode 100644 crypto/asymmetric_keys/private_key.h create mode 100644 kernel/power/hibernate_keys.c -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

9 60

[opensuse-kernel] Apresentadora Priscilla Alcantara
by PRIKOTA PRODU��ES 05 Sep '13

05 Sep '13

1 0

[opensuse-kernel] modprobe: unrecognized option '--allow-unsupported-modules'
by Cristian Rodríguez 05 Sep '13

05 Sep '13

Hi: Apparently the "unsupported modules" thing has crawled into openSUSE Factory mkinitrd , everytime I run it tells me: modprobe: unrecognized option '--allow-unsupported-modules' /lib/mkinitrd/scripts/setup-modules.sh check_supported_kernel should just return 0 in openSUSE as it is meaningless and nothing else supports this concept of "unsupported modules" (not systemd, not udev, not kmod, etc..etc.. none of the modern stack does) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 2

[opensuse-kernel] enabling function tracer
by Andi Kleen 04 Sep '13

04 Sep '13

Hi, One thing that I find inconvenient with standard open suse kernels is that the function tracing support is disabled (CONFIG_FUNCTION_TRACER). I know it's in the tracing kernel, but that has a lot of stuff that is really slow. It's incredibly useful to quickly debug or analyze things without recompiling. I know the thing had significant overhead in the old days, but since dynamic mcount patching was added the overhead should be fairly low (<1-2%) when disabled. Any chance to enable it by default? I also noticed that some ftrace features should be also cheap are also disabled like CONFIG_TRACER_SNAPSHOT. And it's not clear why block trace is disabled too, it should be also practically free when disabled. But at least the function tracer would be nice. -Andi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 2

[opensuse-kernel] dmesg not good
by Felix Miata 04 Sep '13

04 Sep '13

KDE4: 2.4GHz Celeron 1GB RAM http://fm.no-ip.com/Tmp/SUSE/Factory/t2240-dmesg-trap-os131m4-311rc7.txt Xorg OK KDE plenty slow KDE3: 2.4GHz P4 1GB RAM http://fm.no-ip.com/Tmp/SUSE/Factory/gx260-dmesg-trap-os131m4-311rc7.txt http://fm.no-ip.com/SS/os131m4Xconfig-gx260-i845Gk3corrupt.png Both systems run 13.1M4/3.11.rc7 on i845G video. As check within past 10 or so hours I updated both of these, plus other 13.1M4/KDE3 systems with Radeon and Nouveau video, and one with 13.1M4/KDE4/Radeon without noticing any video corruption, but I didn't look for traps in their dmesgs either, since I didn't notice register dumps on tty1 during boot on them. So, kernel problem? Intel driver problem? KDE problem? Multi problem? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 1

[opensuse-kernel] Kernel naming scheme for 13.1
by Jeff Mahoney 03 Sep '13

03 Sep '13

Hi all - One of the things I'd like to consider for openSUSE 13.1 is changing the naming scheme to include the release in the uname -r output so that when there is a version collision between openSUSE and SLES, we can tell the difference. I've introduced a similar proposal for the naming change to the SLES kernels, so this isn't a case of making the distinction only with openSUSE. So instead of: 3.7.10-1.11-default We could have: 3.7.10-1.11.oS12.3-default I suppose the kernel release for Factory would be: 3.7.10-1.11.oSF-default Feedback I've heard off-list has been that some people prefer to have the project abbreviation in the uname strings be all lower case. It's easier on the eyes, but I don't have a strong opinion either way. -Jeff -- Jeff Mahoney SUSE Labs

4 9

[opensuse-kernel] ath9k_htc driver - Atheros USB TL-WN821N
by Alex Naumov 02 Sep '13

02 Sep '13

Hi folks, It seems that we have problem with ath9k_htc driver. I'm not sure is it bug or not, maybe I should to install something else? Before I create the new bug_report I want to discuss about it here to be sure. # lsusb Bus 001 Device 002: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287] # dmesg [ 3896.012025] usb 1-3: new high speed USB device number 2 using ehci_hcd [ 3896.130936] usb 1-3: New USB device found, idVendor=0cf3, idProduct=7015 [ 3896.130941] usb 1-3: New USB device strings: Mfr=16, Product=32, SerialNumber=48 [ 3896.130944] usb 1-3: Product: USB WLAN [ 3896.130947] usb 1-3: Manufacturer: ATHEROS [ 3896.130949] usb 1-3: SerialNumber: 12345 [ 3896.515340] cfg80211: Calling CRDA to update world regulatory domain [ 3896.602625] cfg80211: World regulatory domain updated: [ 3896.602628] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 3896.602631] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 3896.602634] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [ 3896.602636] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) [ 3896.602639] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 3896.602642] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 3896.675872] usb 1-3: ath9k_htc: Firmware - htc_7010.fw not found [ 3896.675884] ath9k_htc: probe of 1-3:1.0 failed with error -22 [ 3896.676219] usbcore: registered new interface driver ath9k_htc I can reproduce it in oS 12.1 x86_64 (3.1.0-1.2-desktop) and oS 13.1m4 (3.10.1-3.g0cd5432-desktop) i686. Ciao, Alex -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 1