kernel June 2015

kernel@lists.fedoraproject.org

12 participants
13 discussions

[PATCH] Add 10-yama-ptrace.conf (rhbz 1209492)
by Mark Wielaard 03 Aug '15

03 Aug '15

This fixes the yama bug #1209492 but lets administrators still add extra restrictions if desired. This patch should apply as is against both f22 and master. --- 10-yama-ptrace.conf | 30 ++++++++++++++++++++++++++++++ kernel.spec | 11 +++++++++++ 2 files changed, 41 insertions(+) create mode 100644 10-yama-ptrace.conf diff --git a/10-yama-ptrace.conf b/10-yama-ptrace.conf new file mode 100644 index 0000000..bcf0e69 --- /dev/null +++ b/10-yama-ptrace.conf @@ -0,0 +1,30 @@ +# The ptrace system call is used for interprocess services, communication +# and introspection (like synchronisation, signaling, debugging, tracing +# and profiling) of processes. +# +# Usage of ptrace is restricted by normal user permissions. Normal +# unprivileged processes cannot interact through ptrace with processes +# that they cannot send signals to or processes that are running set-uid +# or set-gid. +# +# yama ptrace scope can be used to reduce these permissions even more. +# This should normally not be done because it will break various programs +# relying on the default ptrace security restrictions. But can be used +# if you don't have any other way to separate processes in their own +# domains. A different way to restrict ptrace is to set the selinux +# deny_ptrace boolean. Both mechanisms will break some programs relying +# on the ptrace system call and might force users to elevate their +# priviliges to root to do their work. +# +# For more information see Documentation/security/Yama.txt in the kernel +# sources. +# +# This runtime kernel parameter can be set to the following options: +# (Note that setting this to anything except zero will break programs!) +# +# 0 - Normal ptrace security permissions. +# 1 - Restricted ptrace. Only child processes plus normal permissions. +# 2 - Admin-only attach. Only executables with CAP_SYS_PTRACE. +# 3 - No attach. No process may call ptrace at all. Irrevocable. +# +kernel.yama.ptrace_scope = 0 diff --git a/kernel.spec b/kernel.spec index dfc4500..87efd85 100644 --- a/kernel.spec +++ b/kernel.spec @@ -460,6 +460,9 @@ Source1000: config-local Source2000: cpupower.service Source2001: cpupower.config +# Default sysctl files +Source3000: 10-yama-ptrace.conf + # Here should be only the patches up to the upstream canonical Linus tree. # For a stable release kernel @@ -1711,6 +1714,10 @@ BuildKernel() { rm -rf $RPM_BUILD_ROOT/lib/modules/$KernelVer/vdso/.build-id %endif + # Install default sysctl settings. + %{__install} -D -m 444 %{SOURCE3000} \ + $RPM_BUILD_ROOT%{_sysctldir}/10-yama-ptrace-$KernelVer.conf + # And save the headers/makefiles etc for building modules against # # This all looks scary, but the end result is supposed to be: @@ -2342,6 +2349,7 @@ fi /lib/modules/%{KVERREL}%{?2:+%{2}}/vdso\ /etc/ld.so.conf.d/kernel-%{KVERREL}%{?2:+%{2}}.conf\ %endif\ +%config(noreplace) %{_sysctldir}/10-yama-ptrace-%{KVERREL}%{?2:+%{2}}.conf\ /lib/modules/%{KVERREL}%{?2:+%{2}}/modules.*\ %{expand:%%files -f kernel-%{?2:%{2}-}modules.list %{?2:%{2}-}modules}\ %defattr(-,root,root)\ @@ -2375,6 +2383,9 @@ fi # # %changelog +* Thu Jun 23 2015 Mark Wielaard <mjw(a)redhat.com> +- Add 10-yama-ptrace.conf (rhbz 1209492) + * Thu Jun 18 2015 Josh Boyer <jwboyer(a)fedoraproject.org> - Add patch to fix touchpad issues on Razer machines (rhbz 1227891) -- 2.4.3

4 13

Re: [kernel/f21] Make sure acpi brightness_switch is disabled (like forever in Fedora)
by Hans de Goede 29 Jul '15

29 Jul '15

Hi Josh, On 07/28/2014 07:04 PM, Josh Boyer wrote: > commit e6fe382d1d53d4cdf9b544729dc823d4eab0217c > Author: Josh Boyer <jwboyer(a)fedoraproject.org> > Date: Mon Jul 28 13:03:01 2014 -0400 > > Make sure acpi brightness_switch is disabled (like forever in Fedora) > > Upstream reverted the change to turn the ACPI brightness_switch_enabled > parameter off by default. Revert the revert so we go back to the state > Fedora has traditionally been in. Ack, I was planning on doing this myself but you beat me to it, thanks for taking care of this. Note that 3.17 will have this patch: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=… Which fixes the 2 steps being taken for one keypress problem while keeping the acpi brightness_switch behavior enabled, so that people who have an acpi-video controlled backlight and a userspace which does not do backlight control (e.g. windowmaker). So for 3.17 we should IMHO drop the revert-revert and stick with upstream behavior. Alternatively we could apply that patch now instead of the revert-revert. Regards, Hans

3 7

Fedora kernel git tree and package maintenance
by Josh Boyer 09 Jul '15

09 Jul '15

Hi All, The kernel team has been running an exploded git tree since Flock last year. This has been mostly a "nice to have", but several people have commented on how useful it is for them when debugging issues, etc. Having the exploded sources with the patches we carry included lets them easily see what we have changed and how. While not a huge burden, this has been mostly an additional effort on top of what we already do. In order to make us a bit more efficient, we've been looking at ways to automate or ease this, as well as make it possible for more than one person to maintain it. This has lead to some discussion around moving to making the exploded git tree the canonical source location for Fedora kernel work. I'm sending this email to start a conversation around that. So what would this mean? It means we'd maintain the exploded source tree very similar to today, with it rebasing on top of whatever upstream we're using as our base. For info on how that works, see the blog post I did about that a while ago. Using this exploded tree, I've created some scripts to generate the pkg-git content. This is probably the biggest workflow change involved. We still need to use pkg-git to do builds in koji, but direct commits to that repo would be disabled outside of a few of us needed to do the syncs. Patches and config changes could be done via email to this list, or possibly via pull request to the branch maintainer of the exploded tree. Why would we do this? A few reasons. First, it allows us to eliminate duplicate maintenance in multiple spots while still providing all the same things we are right now. Second, it moves us to more of an upstream kernel development model and hopefully increases both visibility and communication in terms of what patches/changes go in, etc. It also makes our job easier during rebases, as we can literally use 'git rebase' and work via that instead of having to copy around patches to different trees or manually adjust patches outside of a normal git workflow. Who does this impact? Honestly, not many. There are exactly 4 people that commit to pkg-git today on anything resembling a regular basis. However, it is my hope that changing the workflow a bit makes this somewhat easier for others to work against a tree and submit patches and changes. I'm not under any impressions that it will exponentially increase our contributors, but it will quite possibly make things a bit more transparent. Is this a done decision? No. Not at all. In fact, the scripts aren't even finished yet. I wanted to get the discussion started before really investing heavily in finishing them off. Justin and Laura have copies of the (unfinished) scripts and a howto document on various tasks. I'll likely send the howto out once I get a few of the last remaining steps working for people to read over. But the general idea isn't going to change much, which is why we're talking about this now. When would this happen? Unclear. Certainly not this month as one of the primary stakeholders is on PTO. If the discussion goes well and this direction is something we're going to do, then it might be next month or at some natural cut-over point. Will the exploded tree go away if we don't change to this model? Also unclear. I'd hesitantly say it would stick around, but it might change in the way it is created and published. I'm sure there will be more questions, so please ask away. Looking forward to hearing other's thoughts. josh

3 6

kdbus and Fedora
by Josh Boyer 08 Jul '15

08 Jul '15

Hi All, Harald and I were recently talking about kdbus and how it plays into Fedora. Right now, the kernel-playground COPR is carrying the kdbus patches, but that isn't widely used and isn't included in a broad test base. Obviously our distribution is heavily entwined with D-Bus and we were looking to see if it was possible to help kdbus testing and development by doing some kind of integration within Fedora itself. I promised Harald I would talk it over with the other Fedora kernel maintainers and after a brief discussion we came up with the following possible proposal. If Fedora were to carry kdbus in any form, the following things would be required: 1) There would be a single canonical location to track kdbus development. After talking with Harald, that should be the upstream tree that gregkh is using to submit patches. 2) Harald's team (systemd, etc) would commit to testing the system both with and without kdbus active. Obviously we do not want to enforce reliance on something as core critical as kdbus while it is still being actively developed upstream. That could cause a lot of deviation down the road and it isn't the aim here. 3) kdbus would only be carried in the rawhide branch until it is merged upstream. As a concrete example, if kdbus was not merged in the upstream kernel at the time rel-eng creates the F23 branches, then Fedora 23 will never get kdbus. It will be carried in rawhide and rawhide only until it's accepted upstream. The maintainers actually hope this does get merged but we want to make sure we are prepared to drop this without causing too much trouble if needed. 4) After discussing a bit with the rest of the Fedora kernel maintainers, we would carry an additional patch that would require 'kdbus-enabled' to be specified before the kernel would allow kdbus to be loaded (or similar mechanism). This would focus the main testing effort for all the default images to remain as they are today, while easily allowing the plumbing layer developers access to kdbus for their enablement testing. These conditions would hopefully help the Fedora kernel maintainers avoid some of the pitfalls of carrying a large chunk of out of tree code and if they're all met we feel fairly comfortable with doing this. We wanted to send this out for a bit wider discussion and review before proceeding with it, and I agreed to start this thread so here we are. Harald, does the above look like what you were envisioning when we talked earlier? josh

9 19

why are these drivers missing from the Fedora kernel?
by Ranjan Maitra 03 Jul '15

03 Jul '15

Hi, I posted this earlier but did not get a response, so here's hoping that someone who notices has more suggestions. I am a long-time Fedora user since Fedora Core 1 and I am looking at installing Fedora 22 on a MS Surface Pro 3 with Type Cover. But in order to do that (and to have the cover recognized), I noticed that the file linux-***/drivers/hid/hid-ids.h in the kernel from kernel.org is missing. This is however available at kcbench (which is the kernel compiled for benchmarking). I was wondering what the reasoning behind this is, because we can not have the Type Cover 3 recognized with the LiveCD while installing (and so installing without a keyboard is a major hassle). Not to mention, kcbench draws in over 500 MB with a dnf update. Also, is this the correct arena for discussing linux-firmware? If not, I apologize. If it is, I was looking at: /lib/firmware/mrvl which is provided by the linux-firmware rpm and I noticed that it is missing some files: This is what is in my updated files list: pcie8897_uapsta.bin sd8797_uapsta.bin usb8766_uapsta.bin sd8688.bin sd8887_uapsta.bin usb8797_uapsta.bin sd8688_helper.bin sd8897_uapsta.bin usb8897_uapsta.bin However, the list here (git://git.marvell.com/mwifiex-firmware.git) have some more -- here is thelist: pcie8897_uapsta.bin sd8797_uapsta.bin usb8766_uapsta.bin* sd8688.bin sd8801_uapsta.bin* usb8797_uapsta.bin sd8688_helper.bin sd8887_uapsta.bin* usb8801_uapsta.bin* sd8787_uapsta.bin sd8897_uapsta.bin usb8897_uapsta.bin So, I was wondering: why are some of the files missing? Is it because of non-OSS issues? Or should I file a bug/feature request? Many thanks, Ranjan ____________________________________________________________ Can't remember your password? Do you need a strong and secure password? Use Password manager! It stores your passwords & protects your account. Check it out at http://mysecurelogon.com/manager

4 9

ppc64 kernel config changes heads up
by Peter Robinson 01 Jul '15

01 Jul '15

Hi All, If you don't care about powerpc you can stop reading :-) If you do.... I went to do what I thought was a basic fix up to the kernel builds on POWER to get rid of the last bits of the ppc32 legacy, on my list for some time, and it has become more of a slightly epic slash and burn! The resulting output kernel configs are for all intents and purpose unchanged but the git diff is some what epic. The top level of the changes are: Core changes that apply too all kernels (ppc64/ppc64p7/ppc64le) reside in config-powerpc64-generic config-powerpc64 -> legacy platforms that are older than POWER7 and their dependencies (here lies the ghosts of PowerPC G5 and friends). config-powerpc64le and config-powerpc64p7 contain anything specific to POWER7 and newer that might affect older platforms, or LE/BE specific to p7 and later I've removed anything that pertains to PPC32 and Cell processors (the later were all disabled now anyway) but if the kernel docs were wrong and they do by chance work on some other 64 bit platform that still works do let me know. So the only thing of real note is the ppc64p7 and ppc64le configs no longer have any old IDE configs enabled or any of the legacy Apple bits pulled in, I don't believe that should cause any pain what so ever, I only bring this up because it's the only thing of note on diffs of before/after resulting config diffs. So ultimately please test kernel builds going forward. There's a scratch build here [1] until we get an official one to test. There's no perf packages, that appears broeken... even on vanilla pre commit :) For those that are morbidly interested in the diff (and don't have the Fedora kernel package check out) you can see that here [2]. Ultimately the large git commit looks quite scary but the actual change to the 3 configs are minimal and I believe this should make things cleaner moving forward :-) I look forward to the testing feedback including any further suggested cleanups to the new configs, oh and please test :-) Peter [1] http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2582705 [2] http://pkgs.fedoraproject.org/cgit/kernel.git/commit/?id=c9229e16082bdc9b2f…

3 3

Initial aarch64 config updates for 4.2
by Peter Robinson 30 Jun '15

30 Jun '15

Below are a few minor updates for aarch64 in 4.2, didn't want to send too many in fear of getting the process screwed up. Feedback welcomne :)

2 4

Re: ppc64 kernel config changes heads up
by Peter Robinson 28 Jun '15

28 Jun '15

Alex, > With all due respect, you do realize that several companies actually still manufacture and sell 32-bit PowerPC processors, correct? Do you think this move will be well-met by them? With all due respect do you realise we actually dropped support for "32-bit PowerPC processors" for all release post Fedora 20? Fedora 20 went EOL this week but it was known when Fedora 20 went GA in December of 2013, around 18 months ago, that ppc-32 was EOL. This isn't a shock or unknown, it was widely publicised that that if people were interested in 32 bit PPC in general that they needed to pick up the architecture maintainership, and in fact the kernel hasn't had the bits in place to build for ppc-32 for some time, in the ppc32 case it's merely cleaning up the left over bits of something, in terms of the Fedora kernel, that has long been dead. Peter >> On Jun 26, 2015, at 2:40 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote: >> >> Hi All, >> >> If you don't care about powerpc you can stop reading :-) >> >> If you do.... I went to do what I thought was a basic fix up to the >> kernel builds on POWER to get rid of the last bits of the ppc32 >> legacy, on my list for some time, and it has become more of a slightly >> epic slash and burn! >> >> The resulting output kernel configs are for all intents and purpose >> unchanged but the git diff is some what epic. >> >> The top level of the changes are: >> >> Core changes that apply too all kernels (ppc64/ppc64p7/ppc64le) reside >> in config-powerpc64-generic >> >> config-powerpc64 -> legacy platforms that are older than POWER7 and >> their dependencies (here lies the ghosts of PowerPC G5 and friends). >> >> config-powerpc64le and config-powerpc64p7 contain anything specific to >> POWER7 and newer that might affect older platforms, or LE/BE specific >> to p7 and later >> >> I've removed anything that pertains to PPC32 and Cell processors (the >> later were all disabled now anyway) but if the kernel docs were wrong >> and they do by chance work on some other 64 bit platform that still >> works do let me know. >> >> So the only thing of real note is the ppc64p7 and ppc64le configs no >> longer have any old IDE configs enabled or any of the legacy Apple >> bits pulled in, I don't believe that should cause any pain what so >> ever, I only bring this up because it's the only thing of note on >> diffs of before/after resulting config diffs. >> >> So ultimately please test kernel builds going forward. There's a >> scratch build here [1] until we get an official one to test. There's >> no perf packages, that appears broeken... even on vanilla pre commit >> :) >> >> For those that are morbidly interested in the diff (and don't have the >> Fedora kernel package check out) you can see that here [2]. >> >> Ultimately the large git commit looks quite scary but the actual >> change to the 3 configs are minimal and I believe this should make >> things cleaner moving forward :-) >> >> I look forward to the testing feedback including any further suggested >> cleanups to the new configs, oh and please test :-) >> >> Peter >> >> [1] http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2582705 >> [2] http://pkgs.fedoraproject.org/cgit/kernel.git/commit/?id=c9229e16082bdc9b2f… >> _______________________________________________ >> ppc mailing list >> ppc(a)lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/ppc >

2 1

file hid-ids.h
by Ranjan Maitra 27 Jun '15

27 Jun '15

Hi, I am a long-time Fedora user and I am looking at installing Fedora 22 on a MS Surface Pro 3 with Type Cover. But in order to do that (and to have the cover recognized), I noticed that the file linux-***/drivers/hid/hid-ids.h in the kernel from kernel.org is missing. This is however available at kcbench (which is the kernel compiled for benchmarking). I was wondering what the reasoning behind this is, because we can not have the Type Cover 3 recognized with the LiveCD while installing (and so installing without a keyboard is a major hassle). Also, is this the correct arena for discussing linux-firmware. If not, I apologize. If it is, I was looking at: /lib/firmware/mrvl which is provided by the linux-firmware rpm and I noticed that it is missing some files: This is what is in my updated files list: pcie8897_uapsta.bin sd8797_uapsta.bin usb8766_uapsta.bin sd8688.bin sd8887_uapsta.bin usb8797_uapsta.bin sd8688_helper.bin sd8897_uapsta.bin usb8897_uapsta.bin However, the list here (git://git.marvell.com/mwifiex-firmware.git) have some more -- here is thelist: pcie8897_uapsta.bin sd8797_uapsta.bin usb8766_uapsta.bin* sd8688.bin sd8801_uapsta.bin* usb8797_uapsta.bin sd8688_helper.bin sd8887_uapsta.bin* usb8801_uapsta.bin* sd8787_uapsta.bin sd8897_uapsta.bin usb8897_uapsta.bin So, I was wondering: why are some of the files missing? Is it because of non-OSS issues? Or should I file a bug/feature request? Many thanks, Ranjan ____________________________________________________________ FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family! Visit http://www.inbox.com/photosharing to find out more!

1 0

[PATCH] kernel-tests: modsign: Change keyring name and kernel module file name
by Masami Ichikawa 27 Jun '15

27 Jun '15

This patch changed keyring name and kernel module name to run modsign test correctly. Current kernel uses .system_keyring as keyring name so test code needs to use key name .system_keyring instead of module_sign. Fedora project provides kernel modules as xz archived format. So, test code should extract a kernel module from an archive file. --- default/modsign/modsign_tests.sh | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/default/modsign/modsign_tests.sh b/default/modsign/modsign_tests.sh index b0bab67..63748ad 100755 --- a/default/modsign/modsign_tests.sh +++ b/default/modsign/modsign_tests.sh @@ -7,7 +7,7 @@ modsign_check_modules() # Grab a module to mess around with. We'll pick one that is fairly # stand-alone and rarely used. - cp /lib/modules/`uname -r`/kernel/fs/minix/minix.ko . + xz -dc /lib/modules/`uname -r`/kernel/fs/minix/minix.ko.xz > minix.ko # Make sure we have the signed module marker cat ./minix.ko | strings | grep "~Module signature appended~" &> /dev/null @@ -59,7 +59,7 @@ modsign_unsigned() { # Grab a module to mess around with. We'll pick one that is fairly # stand-alone and rarely used. - cp /lib/modules/`uname -r`/kernel/fs/minix/minix.ko . + xz -dc /lib/modules/`uname -r`/kernel/fs/minix/minix.ko.xz > minix.ko strip -g ./minix.ko # Make sure it isn't already loaded @@ -109,13 +109,13 @@ modsign_third_party() modsign=0 if [ -f /proc/keys ] then - cat /proc/keys | grep module_sign &> /dev/null + cat /proc/keys | grep .system_keyring &> /dev/null if [ $? -ne "0" ] then echo Module signing not enabled exit 3 fi - keyring=`cat /proc/keys | grep module_sign | cut -f 1 -d " "` + keyring=`cat /proc/keys | grep .system_keyring | cut -f 1 -d " "` keyctl list 0x${keyring} | grep "Fedora kernel signing key" &> /dev/null if [ $? == "0" ] then -- 2.4.3

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel June 2015