Re: Bug#872664: linux-image-4.9.0-3-686-pae: Resume from hibernate fails on Thinkpad T60
It's a bug on 4.9.0-3 Debian's kernel ! I upgrade kernel to 4.13 and hibernate work on Lenovo B 590 ! With Debian 8 also hibernate work ( kernel 3.16 ) so there is a bug on 4.9.0-3 kernel !
Bug#881830: linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel
Since I was a little puzzled as to why keyutils built previously on mips, I found this commit to 4.8 which caused the need for KEYS_COMPAT: commit 20f06ed9f61a185c6dabd662c310bed6189470df Author: David Howells Date: Wed Jul 27 11:43:37 2016 +0100 KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than calling sys_keyctl. The latter will work in a lot of cases, thereby hiding the issue. Now I'm thinking maybe this can be argued as a bugfix for the above commit and put in upstream 4.9? James signature.asc Description: OpenPGP digital signature
Bug#881830: linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel
Source: linux Version: 4.9.51-1 Severity: wishlist Control: fixed -1 4.12.2-1~exp1 Hi, Is it possible to cherry-pick the following upstream commit into the stable kernel so it is available on the buildds? commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20 Author: Bilal Amarni Date: Thu Jun 8 14:47:26 2017 +0100 security/keys: add CONFIG_KEYS_COMPAT to Kconfig This commit moves KEYS_COMPAT to an architecture independent location and enables it on all architectures where COMPAT is enabled. This should allow 64-bit MIPS kernels to handle 32-bit applications using the keyctl syscall (currently they fail with ENOSYS - see keyutils package). I think this will also help with compiling armhf on arm64 kernels. Thanks, James signature.asc Description: OpenPGP digital signature
Processed: linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel
Processing control commands: > fixed -1 4.12.2-1~exp1 Bug #881830 [src:linux] linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel Marked as fixed in versions linux/4.12.2-1~exp1. -- 881830: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881830 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#881813: marked as done (linux-image-4.13.0-1-amd64: Linux 4.13.0 cannot run squeeze chroot environment)
Your message dated Wed, 15 Nov 2017 15:39:59 +0100 with message-id <20171115143958.wppch22or4765...@lorien.valinor.li> and subject line Re: Bug#881813: linux-image-4.13.0-1-amd64: Linux 4.13.0 cannot run squeeze chroot environment has caused the Debian Bug report #881813, regarding linux-image-4.13.0-1-amd64: Linux 4.13.0 cannot run squeeze chroot environment to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 881813: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881813 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:linux Version: 4.13.10-1 Severity: important Current (2017-11-14 - 2017-11-15) sid with up-to-date kernel (4.13.0) cannot "chroot" into squeeze chroot environment. What I did? * I started qemu-system-x86_64 (debian package qemu-system-x86 1:2.8+dfsg-6+deb9u3) from my host system (debian stretch amd64) * 2017-11-14 I downloaded current buster installer from here: http://cdimage.debian.org/cdimage/buster_di_alpha1/amd64/iso-cd/debian-buster-DI-alpha1-amd64-netinst.iso * I installed it to the qemu virtual machine * I upgraded it to current sid (2017-11-14 - 2017-11-15) * I created (in this qemu virtual machine, of course) squeeze chroot environment using command (I use debootstrap 1.0.92): # debootstrap --variant=minbase --no-check-gpg squeeze /tmp/target http://archive.debian.org/debian * It failed: W: Failure trying to run: chroot /tmp/target dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.22_amd64.deb W: See /tmp/target/debootstrap/debootstrap.log for details * /tmp/target/debootstrap/debootstrap.log is here: warning, in file '/var/lib/dpkg/status' near line 4 package 'dpkg': missing description Segmentation fault * Then I tried to run "chroot /tmp/target /bin/bash" and got "Segmentation fault" So, it seems current sid simply cannot run squeeze chroot environment: it gots segmentation fault when triyng to run /bin/bash . * Then I removed /tmp/target and created it again using command: # debootstrap --variant=minbase --no-check-gpg --foreign squeeze /tmp/target http://archive.debian.org/debian * Now the command worked well. But then I tried "chroot /tmp/target /bin/bash" and got "Segmentation fault" again * Then I copied that /tmp/target to outside of my qemu virtual machine and run it on my host. My host is debian stretch with kernel linux-image-4.9.0-4-amd64 4.9.51-1. And /bin/bash worked successfully. So, squeeze chroot environment doesn't work on sid with kernel 4.13.0, but works with stretch with kernel 4.9.0 * Then I run my host OS in qemu using well known "qemu -snapshot /dev/sda" trick. And then I did run "chroot /tmp/target /bin/bash" in this qemu instance. /bin/bash worked well again. So, it seems qemu doesn't influence bug reproducebility. I. e. it seems the problem is not qemu-related. So, I am pretty sure problem is not in debootstrap. I also think the problem is not in qemu (I already wrote why I did so). I think problem is this: modern kernel cannot run old squeeze chroot environment. So I fill this bug to "linux-image" package. I think this is very important bug, so I give it "important" priority. Linux kernel is very conservative when we speak about API and ABI. Modern debian releases typically can run very old chroot environments. I can successfully create debian hamm chroot environment on my stretch host using my own script. Yes, hamm!!! Which is released 1998-07-24!!! And I can successfully run /bin/bash from it. So, debian (until recently) successfully did run very old chroot environments. And now you broke this tradition, this is very bad. This bug report is sent from mentioned sid qemu virtual machine. -- Package-specific info: ** Version: Linux version 4.13.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 6.4.0 20171026 (Debian 6.4.0-9)) #1 SMP Debian 4.13.10-1 (2017-10-30) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.13.0-1-amd64 root=UUID=8e27eccf-cc87-4c57-8bb6-7d3da96097e3 ro quiet ** Not tainted ** Kernel log: [0.606044] Write protecting the kernel read-only data: 12288k [0.606615] Freeing unused kernel memory: 1592K [0.608452] Freeing unused kernel memory: 1128K [0.609313] x86/mm: Checked W+X mappings: passed, no W+X pages found. [0.657316] SCSI subsystem initialized [0.658541] piix4_smbus :00:01.3: SMBus Host Controller at 0x700, revision 0 [0.659811] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI [0.659811] e1000: Copyright (c) 1999-2006 Intel Corporation. [0.668058] libata version 3.00 loaded. [0.671377
Bug#881813: linux-image-4.13.0-1-amd64: Linux 4.13.0 cannot run squeeze chroot environment
Same for buster. I. e. if I replace sid virtual machine with buster virtual machine, I got the same bug. I mean that I created buster from the same alpha 1 installer, but this time I didn't upgrade it to sid. == Askar Safin http://vk.com/safinaskar
Bug#881425: Info received (Bug#881425: linux-image-4.13.0-1-amd64: "rm -rf " fails with ENOTEMPTY (Directory not empty))
Hmmm, using a VM I can't reproduce with 4.13.10-1... The "rm /*" is too fast, perhaps I need more background IO noise?
Re: Secure boot signing infrastructure - feedback request
Hi, On 10/31/2017 01:58 PM, Steve McIntyre wrote: Nearly three weeks later with no responses. Let's see if we get things moving... On Wed, Oct 11, 2017 at 09:48:46PM -0300, Helen Koike wrote: I did a summary about the current discussion here: https://wiki.debian.org/SecureBoot#Wrap-up_of_the_discussions_so_far Feel free to edit this wiki or let me know if I forgot something. I think it's a fair summary, yes. Questions: * About item 2.1. (reproducible builds), if we strip the signatures from the binaries before doing the comparison is the reproducible build criteria acceptable? Can we just strip the signatures and if the result is the same we consider it reproducible? Or is changing the criteria ok? I *personally* believe that being able to remove the signatures and compare binaries is fine for reproducibility purposes. Arguments otherwise would help here. * About item 2.2. Would it be ok if we just have a easy revoke mechanism? In Shim there is already a MokListX (a blacklist of keys or binary hashes), but the current way to update this list is if the user has physical access to the machine, but I was talking with the Shim upstream maintainer and we agreed that we could implement a solution where we could feed a blacklist to shim, and if this list is signed by the vendor_cert (aka Debian's key in our case), and if it is a newer version of the list, shim would update MokListX without requiring user intervention (it would be an equivalent to KEK for UEFI) ACK. Is this solution acceptable? If we have an easy way to revoke, then we can easily undo an attacker's work. We can sign everything automatically (if the package is in a whitelist) without the need for the ftp masters to review each upload manually. Right. Wanting to go the revocation route would depend on the development of yet more new software features. But: this is not something that any of the other SB-supporting distros seem to be caring about so far so I don't think it's something we should have to implement as a pre-requisite. * Item 2.4 seems the strongest argument to me against the buildd approach, but the byhand approach seems to complicated, or we need to reformulate it, any suggestions? We've been discussing Secure Boot for ~5 years now, and I think it's an important feature that we should support in Debian. Does anybody here disagree with that? Multiple people have spent time designing and implementing pieces of the solution to make it work in Debian's infrastructure, but we've yet to make any progress in actually *doing* it. We've had a suggestion (and initial patches) to do this via "autobyhand" scripts on ftp-master, but we've finally seen public objections to that design from ftpmaster. Ben's hopes for that route seem unrealistic too, in terms of manual processing and checking. As a second option, in a discussion with Joerg (remotely) and Luke at DebConf, we thrashed out what we thought was a reasonable alternate solution to drive signing via the buildds instead. Ben has voiced some concerns about the security of that path (extending the attack surface for signed binaries) and reproducibility. So, we're at an impasse. We've had multiple attempts to get this going, with various subsets of this group discussing designs but not *all* the interested parties at each point. We've seen (effective) vetos of each of those designs, meaning we're stalled. Where do we go from here? I appreciate that some folks might feel slighted that they've been left out of some of the discussions. If so, sorry - that was not intentional. :-( Can we put that behind us and work together to make a workable solution please? I propose a sprint to get things moving. I'm prepared to organise it, and facilitate as much as I can. I recognise that not everybody might be able to (or willing to) attend in person, but I don't think that should be a barrier to constructive discussions. Thoughts? I think a Sprint about Secure Boot would be great, we just need to make sure that at least the people who disagree with one approach or the other will be present. @ftpmasters and @Ben, if you could reply if you would be willing to attend it would be great, so we can start organizing it and work together to find a good solution. Thanks Helen
Bug#871608: linux-image-4.9.0-3-amd64: Linux kernel should handle decreasing cpu steal clock counter gracefully
Hi, I ran into the same issue with 4.9.51-1 in the guest. My dom0 in this case is still Jessie with its xen 4.4 version. Users (rightfully) worry about what's suddenly wrong with their virtual machine, since the steal values mess up the cpu graphs. I see that all the discussions linked above have gone silent quickly without a solution. A post to the Xen mailing list on Aug 31th did not get any answer yet: https://lists.xen.org/archives/html/xen-users/2017-08/msg00092.html I see that the issue got fixed by replacing the code with a new implementation of the same functionality. I guess this is a scenario that sometimes happens, not having a ready to go fix available for the previous LTS kernel. So, what would be the best step forward here? Should we poke the Xen people a bit more to find out how to approach this, or get an opinion on the best and smallest patch to go with? I'm not an expert in the cpu time accounting area, but I can help testing etc... Thanks, -- Hans van Kranenburg
Bug#881813: linux-image-4.13.0-1-amd64: Linux 4.13.0 cannot run squeeze chroot environment
Package: src:linux Version: 4.13.10-1 Severity: important Current (2017-11-14 - 2017-11-15) sid with up-to-date kernel (4.13.0) cannot "chroot" into squeeze chroot environment. What I did? * I started qemu-system-x86_64 (debian package qemu-system-x86 1:2.8+dfsg-6+deb9u3) from my host system (debian stretch amd64) * 2017-11-14 I downloaded current buster installer from here: http://cdimage.debian.org/cdimage/buster_di_alpha1/amd64/iso-cd/debian-buster-DI-alpha1-amd64-netinst.iso * I installed it to the qemu virtual machine * I upgraded it to current sid (2017-11-14 - 2017-11-15) * I created (in this qemu virtual machine, of course) squeeze chroot environment using command (I use debootstrap 1.0.92): # debootstrap --variant=minbase --no-check-gpg squeeze /tmp/target http://archive.debian.org/debian * It failed: W: Failure trying to run: chroot /tmp/target dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.22_amd64.deb W: See /tmp/target/debootstrap/debootstrap.log for details * /tmp/target/debootstrap/debootstrap.log is here: warning, in file '/var/lib/dpkg/status' near line 4 package 'dpkg': missing description Segmentation fault * Then I tried to run "chroot /tmp/target /bin/bash" and got "Segmentation fault" So, it seems current sid simply cannot run squeeze chroot environment: it gots segmentation fault when triyng to run /bin/bash . * Then I removed /tmp/target and created it again using command: # debootstrap --variant=minbase --no-check-gpg --foreign squeeze /tmp/target http://archive.debian.org/debian * Now the command worked well. But then I tried "chroot /tmp/target /bin/bash" and got "Segmentation fault" again * Then I copied that /tmp/target to outside of my qemu virtual machine and run it on my host. My host is debian stretch with kernel linux-image-4.9.0-4-amd64 4.9.51-1. And /bin/bash worked successfully. So, squeeze chroot environment doesn't work on sid with kernel 4.13.0, but works with stretch with kernel 4.9.0 * Then I run my host OS in qemu using well known "qemu -snapshot /dev/sda" trick. And then I did run "chroot /tmp/target /bin/bash" in this qemu instance. /bin/bash worked well again. So, it seems qemu doesn't influence bug reproducebility. I. e. it seems the problem is not qemu-related. So, I am pretty sure problem is not in debootstrap. I also think the problem is not in qemu (I already wrote why I did so). I think problem is this: modern kernel cannot run old squeeze chroot environment. So I fill this bug to "linux-image" package. I think this is very important bug, so I give it "important" priority. Linux kernel is very conservative when we speak about API and ABI. Modern debian releases typically can run very old chroot environments. I can successfully create debian hamm chroot environment on my stretch host using my own script. Yes, hamm!!! Which is released 1998-07-24!!! And I can successfully run /bin/bash from it. So, debian (until recently) successfully did run very old chroot environments. And now you broke this tradition, this is very bad. This bug report is sent from mentioned sid qemu virtual machine. -- Package-specific info: ** Version: Linux version 4.13.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 6.4.0 20171026 (Debian 6.4.0-9)) #1 SMP Debian 4.13.10-1 (2017-10-30) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.13.0-1-amd64 root=UUID=8e27eccf-cc87-4c57-8bb6-7d3da96097e3 ro quiet ** Not tainted ** Kernel log: [0.606044] Write protecting the kernel read-only data: 12288k [0.606615] Freeing unused kernel memory: 1592K [0.608452] Freeing unused kernel memory: 1128K [0.609313] x86/mm: Checked W+X mappings: passed, no W+X pages found. [0.657316] SCSI subsystem initialized [0.658541] piix4_smbus :00:01.3: SMBus Host Controller at 0x700, revision 0 [0.659811] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI [0.659811] e1000: Copyright (c) 1999-2006 Intel Corporation. [0.668058] libata version 3.00 loaded. [0.671377] Floppy drive(s): fd0 is 2.88M AMI BIOS [0.674626] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input3 [0.674745] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input2 [0.690794] FDC 0 is a S82078B [0.698539] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 [1.025342] e1000 :00:03.0 eth0: (PCI:33MHz:32-bit) 52:54:00:12:34:56 [1.025348] e1000 :00:03.0 eth0: Intel(R) PRO/1000 Network Connection [1.025367] ata_piix :00:01.1: version 2.13 [1.026725] e1000 :00:03.0 ens3: renamed from eth0 [1.027495] scsi host0: ata_piix [1.027584] scsi host1: ata_piix [1.027608] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc040 irq 14 [1.027609] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc048 irq 15 [1.184305] ata1.01: NODEV after polling detection [1.184501] ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100 [1.18450
