kernel July 2015

kernel@lists.fedoraproject.org

15 participants
12 discussions

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

04 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

failed to build kernel from kernel-4.2.0-0.rc3.git3.1.fc23.src.rpm
by Masami Ichikawa 26 Jul '15

26 Jul '15

Hi, I tried to rebuild kernel from kernel-4.2.0-0.rc3.git3.1.fc23.src.rpm but I got following error. Applying: lib/cpumask: Make CPUMASK_OFFSTACK usable without debug dependency Applying: amd-xgbe-a0: Add support for XGBE on A0 Applying: amd-xgbe-phy-a0: Add support for XGBE PHY on A0 Applying: arm64: avoid needing console= to enable serial console Applying: usb: make xhci platform driver use 64 bit or 32 bit DMA Applying: arm64: acpi drop expert patch Applying: ARM: tegra: usb no reset error: drivers/usb/core/hub.c: does not exist in index Patch failed at 0007 ARM: tegra: usb no reset The copy of the patch that failed is found in: /home/masami/rpmbuild/BUILD/kernel-4.1.fc23/linux-4.2.0-0.rc3.git3.1.fc23.x86_64/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". error: Bad exit status from /var/tmp/rpm-tmp.yWoA78 (%prep) Failed patch is this. masami@f23-test:~$ cat rpmbuild/BUILD/kernel-4.1.fc23/linux-4.2.0-0.rc3.git3.1.fc23.x86_64/.git/rebase-apply/patch --- drivers/usb/core/hub.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 43cb2f2e3b43..7f838ec11c81 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -4996,6 +4996,13 @@ static void hub_event(struct work_struct *work) (u16) hub->change_bits[0], (u16) hub->event_bits[0]); + /* Don't disconnect USB-SATA on TrimSlice */ + if (strcmp(dev_name(hdev->bus->controller), "tegra-ehci.0") == 0) { + if ((hdev->state == 7) && (hub->change_bits[0] == 0) && + (hub->event_bits[0] == 0x2)) + hub->event_bits[0] = 0; + } + /* Lock the device, then check to see if we were * disconnected while waiting for the lock to succeed. */ usb_lock_device(hdev); any idea? I did following command to rebuild on fedora 23(x86_64) environment. rpmbuild -bp --target=$(uname -m) kernel.spec Cheers, -- Masami Ichikawa - masami256(a)gmail.com - masami(a)fedoraproject.org

3 3

Fwd: Re: failed to build kernel from kernel-4.2.0-0.rc3.git3.1.fc23.src.rpm
by Lance Lassetter 26 Jul '15

26 Jul '15

-------- Original Message -------- From: Lance Lassetter <lancelassetter(a)gmail.com> Sent: July 26, 2015 9:46:22 AM CDT To: Josh Boyer <jwboyer(a)fedoraproject.org> Subject: Re: failed to build kernel from kernel-4.2.0-0.rc3.git3.1.fc23.src.rpm On July 26, 2015 9:06:35 AM CDT, Josh Boyer <jwboyer(a)fedoraproject.org> wrote: >On Sun, Jul 26, 2015 at 9:39 AM, Masami Ichikawa <masami256(a)gmail.com> >wrote: >> Hi, >> >> I tried to rebuild kernel from >kernel-4.2.0-0.rc3.git3.1.fc23.src.rpm >> but I got following error. >> >> Applying: lib/cpumask: Make CPUMASK_OFFSTACK usable without debug >dependency >> Applying: amd-xgbe-a0: Add support for XGBE on A0 >> Applying: amd-xgbe-phy-a0: Add support for XGBE PHY on A0 >> Applying: arm64: avoid needing console= to enable serial console >> Applying: usb: make xhci platform driver use 64 bit or 32 bit DMA >> Applying: arm64: acpi drop expert patch >> Applying: ARM: tegra: usb no reset >> error: drivers/usb/core/hub.c: does not exist in index >> Patch failed at 0007 ARM: tegra: usb no reset >> The copy of the patch that failed is found in: >> >/home/masami/rpmbuild/BUILD/kernel-4.1.fc23/linux-4.2.0-0.rc3.git3.1.fc23.x86_64/.git/rebase-apply/patch >> When you have resolved this problem, run "git am --continue". >> If you prefer to skip this patch, run "git am --skip" instead. >> To restore the original branch and stop patching, run "git am >--abort". >> error: Bad exit status from /var/tmp/rpm-tmp.yWoA78 (%prep) >> >> Failed patch is this. >> >> masami@f23-test:~$ cat >> >rpmbuild/BUILD/kernel-4.1.fc23/linux-4.2.0-0.rc3.git3.1.fc23.x86_64/.git/rebase-apply/patch >> --- >> drivers/usb/core/hub.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c >> index 43cb2f2e3b43..7f838ec11c81 100644 >> --- a/drivers/usb/core/hub.c >> +++ b/drivers/usb/core/hub.c >> @@ -4996,6 +4996,13 @@ static void hub_event(struct work_struct >*work) >> (u16) hub->change_bits[0], >> (u16) hub->event_bits[0]); >> >> + /* Don't disconnect USB-SATA on TrimSlice */ >> + if (strcmp(dev_name(hdev->bus->controller), "tegra-ehci.0") >== 0) { >> + if ((hdev->state == 7) && (hub->change_bits[0] == 0) >&& >> + (hub->event_bits[0] == 0x2)) >> + hub->event_bits[0] = 0; >> + } >> + >> /* Lock the device, then check to see if we were >> * disconnected while waiting for the lock to succeed. */ >> usb_lock_device(hdev); >> >> any idea? >> >> I did following command to rebuild on fedora 23(x86_64) environment. >> rpmbuild -bp --target=$(uname -m) kernel.spec > >We'd likely need to see the whole log. Also, why are you rebuilding >something that is already built on koji? Normally that is done if >someone makes modifications, so I'm curious if you have done so. > >josh possibly unrelated: I'm getting kernel panics when issuing legacy Fedora/Red Hat commands like and latest stable kernel in F22: service network restart - kernel panic Also with NetworkManager I get no kernel panics; however, it hoses my routing table when using a public VPN. init 5 back to init 3 back to init 5 i lose display (but if I systemctl isolate graphical.target, multi-user.target...I do not lose display. Maybe a document is needed for users to not use legacy tools? Lance >_______________________________________________ >kernel mailing list >kernel(a)lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/kernel

1 0

kernel panics 4.0.8-300.fc22.x86_64
by Lance Lassetter 22 Jul '15

22 Jul '15

I haven't debugged yet but I'm getting kernel panics on reboot of 4.0.8-300. The machine is a 2008 manufactured Dell XPS 625 (one of the first Dell Alienware machines). The OS is modified Fedora 22 server install. Also when issued command "init 5" then back "init 3" then back to "init 5" I get a black screen. I'm mostly doing this to utilize firewall-config because IMHO firewall-cmd is just too cryptic when adding direct rules. Also I attempted to unmask NetworkManager and it hosed my routing table. Would it be because I had NetworkManager-dispatcher active? I know the latter two issues aren't kernel-related but might be or just as a side note. Regards, Lance Lassetter

2 1

Building a custom kernel via cross compiling
by Andrew Wing 15 Jul '15

15 Jul '15

Hi all, I am a newbie with kernel matters so I apologize in advance for what is a newbie type setup question. My feeling is that if I send this query to the more general Arm Fedora forum, the mere mention of kernel will provoke glazed eyes :-) The background is that I have an OEM board based on a TI AM3352 OMAP family SoC looking somewhat like a Beaglebone black. Recently I've been exploring getting this running under Fedora. In order to get it working I've cobbled together the F22 minimal image along with a device tree blob created by a colleague for this board, and a customised MLO/u-boot. My next task is to look through and understand the arm kernel sources, customize various aspects of the kernel config for my board and re-build. It seems that instructions are here: https://fedoraproject.org/wiki/Building_a_custom_kernel However, I want to cross compile on a host system. To ease this process I have set up a Fedora x86 box, also running f22, which is going to be the host build machine. I decided I should build from source rpm and was following the wiki instructions(rpmdev-setuptree etc.) up to the point here... *cd ~/rpmbuild/SPECS* *rpmbuild -bp --target=$(uname -m) kernel.spec* At this point I'd like to actually have a target of arm7l for my target but entering this gets me an unknown target error (possibly not surprising given the build machine/target architecture difference!). My build machine does have a suitable linaro Arm compiler in place. It occurs to me that I need a different kernel spec and to indicate to my build system to use my compiler. Hopefully this can be achieved via some slightly modified step from that given in the wiki page? Or should I be tackling this in a completely different way? Thanks in advance for any clarification. regards, Andrew

2 3

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

experimental scripts for bisecting the kernel
by Laura Abbott 08 Jul '15

08 Jul '15

Hi all, I expanded on some of the scripts that Josh wrote and came up with a set of scripts to aid in bisecting the kernel project. The idea here is to replay the Fedora patches on top of each step of a kernel bisect. Ultimately, I'd like to have something to give to bugzilla reporters to be able to narrow down which change caused their issue. The scripts are in a repo at https://pagure.io/fedbisect (HTML readme didn't come out well, the text version looks better) If you want to play around with it: git clone git@pagure.io:fedbisect.git ./setup-pkg-git.sh <name for your kernel subdirectory> Wait for kernel tree to finish syncing cd <subdir>/fedora ./fedbisect.sh start <good version> <bad version> this will kick of a kernel build and make install a kernel. You can then do ./fedbisect.sh good ./fedbisect.sh bad to indicate if a particular kernel is good or bad according to your tests. These scripts are very experimental right now but go ahead and try them out and report bugs (or give patches!). Thanks, Laura

1 0

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

minor updates for ARM and Power
by Peter Robinson 03 Jul '15

03 Jul '15

Just some small cleanups and updates for ARM* and Power. Cheers, Pete

2 4

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel July 2015