Bug#733826: crazy loop xhci_hcd Too many fragments
From: Alan Stern Subject: Re: Bug#733826: crazy loop xhci_hcd Too many fragments On Mon, 6 Jan 2014, Ben Hutchings wrote: On Sat, 2014-01-04 at 05:44 +0800, jida...@jidanni.org wrote: ... # cat /var/log/syslog Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 5 lo ::1 UDP 123 Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 6 eth0 fe80::2289:84ff:fe28:ad9 UDP 123 Jan 1 06:57:38 jidanni5 ntpd[2822]: peers refreshed Jan 1 06:57:38 jidanni5 ntpd[2822]: Listening on routing socket on fd #23 for interface updates Jan 1 07:04:49 jidanni5 kernel: [ 559.624680] xhci_hcd :00:14.0: Too many fragments 79, max 63 Jan 1 07:04:49 jidanni5 kernel: [ 559.624695] xhci_hcd :00:14.0: Too many fragments 79, max 63 Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd :00:14.0: Too many fragments 79, max 63 10 lines later... oops I mean an actual MILLION lines later Assuming my fix for the repetition is correct, the remaining problem is why usb-storage is generating such large/fragmented urbs. usb-storage doesn't generate large or fragmented anything. It merely passes on the scatter-gather information it gets from the block layer. Although not a real fix to the underlying problem, it seems that the default ring size is far too small. Any amount of network traffic also activates the ring expansion code. IIRC each ring entry is 16 bytes, so increasing the ring size to 256 still keeps the rings to a single 4k page. Whether anything regularly exceeds 255 fragments is a another matter. David -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/063d6719ae5e284eb5dd2968c1650d6d29d...@acuexch.aculab.com
Bug#733826: [PATCH] xhci: Set scatter-gather limit to avoid failed block writes.
It only happens to me once in a full moon too. Not something I can reproduce at will. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwj8urid@jidanni.org
Bug#734172: similar to
I didn't say it was the same, just that is has some similarities. Both have GFS2 on top of active/active drbd and both break when there is some load in the GFS2 filesystem (my first crash a few weeks ago was with a rm -rf) I agree they affect different functions but they still have some things in common. Anyway, the important thing is that there was a comment on that redhat bug pointing to some GFS2 fixes. I looked into that and found that many GFS2 fixes were included in the latest RC kernel (3.13-rc7) so I compiled 3.13-rc7 and I'm running that kernel since yesterday and so far it did not crash. If it doesn't crash by tomorrow I'll try some activities that made it crash over the last few days (like taking a backup... using tar...) 3.13-rc7 includes these (among others): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0b3a2c9968d453d5827e635a6f3d69129f70af66 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=152b734a9e38aa2e9668fa072cf66625383ca865 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capc93_kijb5au0bx+smxsakfvsth+fjveuaogbjqp7rgq-s...@mail.gmail.com
Bug#733551: Sanitation of CPU-state when switching from virtual-8086 mode to other task incomplete
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Hutchings wrote: On Fri, 2014-01-03 at 23:20 +, halfdog wrote: Here is some more information from my latest tests: * Although first observed with virtual-8086 mode, the bug is not specific to virtual-8086 mode, it can be triggered with normal x86 userspace code also, even with better reproducibility. * It seems, that when changing the FPU control word with fstcw just before exit of the process, then another process could suffer when doing __do_switch * By having two rogue processes writing data to each other via a socket, time and code-position of OOPS can be influenced. * When deactivating mmap_min_addr, the NULL-dereferences during task-switch are exploitable, if kernel memory layout is known from System.map, privilege escalation might be quite likely. This is why no-one sets mmap_min_addr to 0 any more... Yes, I know. It's just for learning purposes ... * I've not yet tried to build a 64-bit version, but since vm86-syscall is not required any more, there could be problems there also. You can find the new improved test code without virtual-8086 mode here: http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/FpuStateTaskSwitchOops.c I commented-out the mmap-ing as I just want to see the oops rather than work out how exploitable it might be. But I didn't get an oops when running on either the -486 or -686-pae kernel flavour, in a VM on an Intel or AMD 64-bit CPU, or directly on an Intel 64-bit CPU. (The AMD system is a server I don't want to take down.) Can you confirm that you are able to reproduce this without a VM, and send the contents of /proc/cpuinfo on the affected system(s)? So, after completing my privilege escalation-POC, I'm back on searching for the root cause. I've run tests without and within VirtualBox, the results were the same. The local-root also works on the native CPU without virtualization. So if you can't reproduce, the CPU or some CPU-related kernel features might be the problem: My CPU is a dual-core AMD, but the Debian 486-kernel does use only one of those: processor : 0 vendor_id : AuthenticAMD cpu family : 20 model : 1 model name : AMD E-350 Processor stepping: 0 microcode : 0x528 cpu MHz : 1596.563 cache size : 512 KB fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc nonstop_tsc extd_apicid aperfmperf pni monitor ssse3 cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch ibs skinit wdt arat hw_pstate npt lbrv svm_lock nrip_save pausefilter bogomips: 3193.12 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate Another hot candidate might be the noxsave switch: [BUGS=X86] Disables x86 extended register state save and restore using xsave. The kernel will fallback to enabling legacy floating-point and sse state. While reading the Intel architecture manuals to develop the POC, I stumbled multiple times over relations between the problematic emms instruction, the FPU control word handling and the xsave instruction, but do not have a complete picture on that yet. - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLMkKoACgkQxFmThv7tq+5JBwCeNYfa/QmHq3sI2O45fDcwd62j Tb8An3iIs5yPFxIFBCIUGXX/PVrzB4xu =KZ07 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52cc90bd.3040...@halfdog.net
Processing of linux-tools_3.12.6-1~bpo70+1_multi.changes
linux-tools_3.12.6-1~bpo70+1_multi.changes uploaded successfully to localhost along with the files: linux-tools_3.12.6-1~bpo70+1.dsc linux-tools_3.12.6-1~bpo70+1.debian.tar.xz libusbip-dev_1.1.1+3.12.6-1~bpo70+1_i386.deb linux-kbuild-3.12_3.12.6-1~bpo70+1_i386.deb usbip_1.1.1+3.12.6-1~bpo70+1_i386.deb linux-tools-3.12_3.12.6-1~bpo70+1_i386.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1w0jby-0002d6...@franck.debian.org
Processing of linux-latest_55~bpo70+1_multi.changes
linux-latest_55~bpo70+1_multi.changes uploaded successfully to localhost along with the files: linux-latest_55~bpo70+1.dsc linux-latest_55~bpo70+1.tar.gz linux-doc_3.12+55~bpo70+1_all.deb linux-source_3.12+55~bpo70+1_all.deb linux-tools_3.12+55~bpo70+1_all.deb linux-image-486_3.12+55~bpo70+1_i386.deb linux-headers-486_3.12+55~bpo70+1_i386.deb linux-image-686-pae_3.12+55~bpo70+1_i386.deb linux-headers-686-pae_3.12+55~bpo70+1_i386.deb linux-image-686-pae-dbg_3.12+55~bpo70+1_i386.deb linux-image-amd64_3.12+55~bpo70+1_i386.deb linux-headers-amd64_3.12+55~bpo70+1_i386.deb linux-image-rt-686-pae_3.12+55~bpo70+1_i386.deb linux-headers-rt-686-pae_3.12+55~bpo70+1_i386.deb linux-image-rt-686-pae-dbg_3.12+55~bpo70+1_i386.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1w0jlf-0003vm...@franck.debian.org
linux-latest_55~bpo70+1_multi.changes is NEW
binary:linux-image-rt-686-pae-dbg is NEW. Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1w0jgb-uu...@franck.debian.org
linux-tools_3.12.6-1~bpo70+1_multi.changes is NEW
binary:linux-tools-3.12 is NEW. binary:linux-kbuild-3.12 is NEW. Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1w0jgi-vz...@franck.debian.org
Re: Plan of action for Secure Boot support
* Ben Hutchings: However, there is now a blog post from Microsoft that supports what Matthew Garrett has been saying for a while - they may revoke the signature on a boot loader if signature verification is not extended to the kernel, including any mechanism to chain-load another kernel: http://blogs.msdn.com/b/windows_hardware_certification/archive/2013/12/03/microsoft-uefi-ca-signing-policy-updates.aspx (specifically point 5(b)) This implies that when Secure Boot is enabled, only signed kernels and modules can be loaded and other features that allow code injection such as kexec, hibernation and /dev/mem must be disabled. We also need to use an EV certificate in the shim—not just for submission to Microsoft, but also for the certificate that signs GRUB and the kernel (item 6 (a)). The Terms Conditions of existing EV code-signing CAs do not permit a code-signing end-entity certificate to be used for signing another certificate, so we'd directly have to embed the end-entity certificate used to sign GRUB and the kernel into the shim—or we'd have to ship the EV root CA, but that would extend complete trust to that CA. If we embed the end-entity certificate, we need to submit a new shim to Microsoft for signing each time the certificate changes (say, because the previous certificate expired after a year). Furthermore, we need to store the keys for all EV certificates (both the certificate used for submission, and the certificate embedded in the shim) in devices that meet at least FIPS 140 Level 2. Such devices that are affordable, support secure, remote operation, and are compatible with free software environments are difficult to find. (But perhaps we can find a DD who agrees to keep the keys in his or her home and manually signs our kernels, using Windows if necessary.) I'm not sure if we can sign sid kernels because of the requirement to sign production quality code only. With KVM, we can boot another operating system after executing unauthenticated (userspace) code, so the new policy seems to force us to disable KVM per item 5 (b) (or extended Secure Boot to qemu-kvm, which is practically impossible at present because we do not have a signed userspace). Obviously, one can still start a virtualized environment without hardware support, and I don't know what this means for compliance. I wonder why Microsoft no longer wants to sign GPLv3 code (such as GRUB 2). It could be due to plans to make Secure Boot mandatory eventually. Right now, it is possible to comply with the GPLv3 license requirements because users can switch off Secure Boot, either at the BIOS level or through the MokManager loophole. This does not affect us because we rarely ship hardware with Debian pre-installed, and if we do, we can make use of the general GPLv3 opt-out clause. But it would affect some of our users. There is also a significant technical limitation: The current shim/grub/kernel combination is totally untested as far as revocation is concerned. Fedora does not blacklist kernels with known root-to-ring-0 escalation vulnerabilities. This means that you can just downgrade the kernel to a known-vulnerable version and lose all protections allegedly provided by Secure Boot (as far as the Linux side is concerned). On the other hand, no one really wants to fix this because it would mean that users cannot downgrade kernels anymore to deal with regressions. In short, I think it is very hard for us to comply with the new Microsoft guidelines. It is also politically problematic because once we comply, Microsoft could try to claim that mandatory Secure Boot is not locking out anyone (because it's not just Fedora anymore). We could still do our own thing under a root we control, but then we have to decide if we want to cross-certify everyone else. We should probably continue the discussion on debian-project because it's not just about the kernel or technical issues. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878uurexq8@mid.deneb.enyo.de
