Bug#1054514: linux-image-6.1.0-13-amd64: Debian VM with qxl graphics freezes frequently
Package: src:linux Version: 6.1.55-1 Severity: normal Steps to reproduce: 1) Install Debian 12 as a virtual machine using virt-manager, choose qxl graphics card. You only need basic installation without wayland or X. 2) Login from the console and save thë following to reproduce.bash: #!/bin/bash chvt 3 for j in $(seq 80); do echo "$(date) starting round $j" if [ "$(journalctl --boot | grep "failed to allocate VRAM BO")" != "" ]; then echo "bug was reproduced after $j tries" exit 1 fi for i in $(seq 100); do dmesg > /dev/tty3 done done echo "bug could not be reproduced" exit 0 3) Run chmod a+x reproduce.bash 4) Run ./reproduce.bash and wait for up to 20 minutes. Expected results: 4) The system prints a steady flow of text without kernel error messages Actual messages: 4) At some point the text stops flowing and the script prints "bug was reproduced". If you run "journalctl --boot" you see kernel: [TTM] Buffer eviction failed kernel: qxl :00:02.0: object_init failed for (3149824, 0x0001) kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate VRAM BO More info: 1) The bug does not occur if I downgrade the kernel to linux-image-5.10.0-26-amd64_5.10.197-1_amd64.deb from Debian 11. 2) I used the following test_linux.bash to bisect this issue against upstream source: #!/bin/bash set -x gitversion="$(git describe HEAD|sed 's@^v@@')" git checkout drivers/gpu/drm/ttm/ttm_bo.c include/drm/ttm/ttm_bo_api.h git show bec771b5e0901f4b0bc861bcb58056de5151ae3a | patch -p1 # Build cp ~/kernel.config .config # cp /boot/config-$(uname -r) .config # scripts/config --enable LOCALVERSION_AUTO # scripts/config --disable DEBUG_INFO # scripts/config --disable SYSTEM_TRUSTED_KEYRING # scripts/config --set-str SYSTEM_TRUSTED_KEYS '' # scripts/config --disable STACKPROTECTOR_STRONG make olddefconfig # make localmodconfig make -j$(nproc --all) bindeb-pkg rc="$?" if [ "$rc" != "0" ]; then exit 125 fi git checkout drivers/gpu/drm/ttm/ttm_bo.c include/drm/ttm/ttm_bo_api.h package="$(ls --sort=time ../linux-image-*_amd64.deb|head -n1)" version=$(echo $package | cut -d_ -f1|cut -d- -f3-) if [ "$gitversion" != "$version" ]; then echo "Build produced version $gitversion but got $version, ignoring" #exit 255 fi # Deploy scp $package target:a.deb ssh target sudo apt install ./a.deb ssh target rm -f a.deb ssh target ./grub_set_default_version.bash $version ssh target sudo shutdown -r now sleep 40 detected_version=$(ssh target uname -r) if [ "$detected_version" != "$version" ]; then echo "Booted to $detected_version but expected $version" exit 255 fi # Test exec ssh target sudo ./reproduce.bash Bisect printed the following log: git bisect start # bad: [ed29c2691188cf7ea2a46d40b891836c2bd1a4f5] drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v7. git bisect bad ed29c2691188cf7ea2a46d40b891836c2bd1a4f5 # bad: [762949bb1da78941b25e63f7e952af037eee15a9] drm: fix drm_mode_create_blob comment git bisect bad 762949bb1da78941b25e63f7e952af037eee15a9 # bad: [e40f97ef12772f8eb04b6a155baa1e0e2e8f3ecc] drm/gma500: Drop DRM_GMA600 config option git bisect bad e40f97ef12772f8eb04b6a155baa1e0e2e8f3ecc # bad: [5a838e5d5825c85556011478abde708251cc0776] drm/qxl: simplify qxl_fence_wait git bisect bad 5a838e5d5825c85556011478abde708251cc0776 # bad: [d2b6f8a179194de0ffc4886ffc2c4358d86047b8] Merge tag 'xfs-5.13-merge-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux git bisect bad d2b6f8a179194de0ffc4886ffc2c4358d86047b8 # bad: [68a32ba14177d4a21c4a9a941cf1d7aea86d436f] Merge tag 'drm-next-2021-04-28' of git://anongit.freedesktop.org/drm/drm git bisect bad 68a32ba14177d4a21c4a9a941cf1d7aea86d436f # bad: [0698b13403788a646073fcd9b2294f2dce0ce429] drm/amdgpu: skip PP_MP1_STATE_UNLOAD on aldebaran git bisect bad 0698b13403788a646073fcd9b2294f2dce0ce429 # bad: [e1a5e6a8c48bf99ea374fb3e535661cfe226bca4] drm/doc: Add RFC section git bisect bad e1a5e6a8c48bf99ea374fb3e535661cfe226bca4 # bad: [ed29c2691188cf7ea2a46d40b891836c2bd1a4f5] drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v7. git bisect bad ed29c2691188cf7ea2a46d40b891836c2bd1a4f5 # bad: [2c8ab3339e398bbbcb0980933e266b93bedaae52] drm/i915: Pin timeline map after first timeline pin, v4. git bisect bad 2c8ab3339e398bbbcb0980933e266b93bedaae52 # bad: [2eb8e1a69d9f8cc9c0a75e327f854957224ba421] drm/i915/gem: Drop relocation support on all new hardware (v6) git bisect bad 2eb8e1a69d9f8cc9c0a75e327f854957224ba421 # bad: [b5b6f6a610127b17f20c0ca03dd27beee4ddc2b2] drm/i915/gem: Drop legacy execbuffer support (v2) git bisect bad b5b6f6a610127b17f20c0ca03dd27beee4ddc2b2 # bad: [06debd6e1b28029e6e77c41e59a162868f377897] Merge tag 'drm-intel-next-2021-03-16' of git://anongit.freedesktop.org/drm/drm-intel into drm-next git bisect bad 06debd6e1b28029e6e77c41e59a162868f377897 # good: [e19eede54240d64b4baf9b0df4dfb8191f7ae48b] Merge branch 'dmi-for-lin
Bug#1054514: linux-image-6.1.0-13-amd64: Debian VM with qxl graphics freezes frequently
Hi, On Tue, 24 Oct 2023, Salvatore Bonaccorso wrote: Thanks for the excelent constructed report! I think it's best to forward this directly to upstream including the people for the bisected commit to get some idea. Thanks for the quick reply! Can you reproduce the issue with 6.5.8-1 in unstable as well? Unfortunately yes: ansible@target:~$ uname -r 6.5.0-3-amd64 ansible@target:~$ time sudo ./reproduce.bash Wed 25 Oct 2023 12:27:00 AM EEST starting round 1 Wed 25 Oct 2023 12:27:24 AM EEST starting round 2 Wed 25 Oct 2023 12:27:48 AM EEST starting round 3 bug was reproduced after 3 tries real0m48.838s user0m1.115s sys 0m45.530s I also tested upstream tag v6.6-rc6: ... + detected_version=6.6.0-rc6 + '[' 6.6.0-rc6 '!=' 6.6.0-rc6 ']' + exec ssh target sudo ./reproduce.bash Wed 25 Oct 2023 12:37:16 AM EEST starting round 1 Wed 25 Oct 2023 12:37:42 AM EEST starting round 2 Wed 25 Oct 2023 12:38:10 AM EEST starting round 3 Wed 25 Oct 2023 12:38:36 AM EEST starting round 4 Wed 25 Oct 2023 12:39:01 AM EEST starting round 5 Wed 25 Oct 2023 12:39:27 AM EEST starting round 6 bug was reproduced after 6 tries For completeness, here is also the grub_set_default_version.bash script that I had to write to automate this (maybe these could be in debian wiki?): #!/bin/bash set -x version="$1" idx=$(expr $(grep "menuentry " /boot/grub/grub.cfg | sed 1d |grep -n "'Debian GNU/Linux, with Linux $version'"|cut -d: -f1) - 1) exec sudo grub-set-default "1>$idx" -Timo
Bug#900821: linux-image-4.9.0-6-amd64: apache reads wrong data over cifs filesystems served by samba
Hi, just as a random exercise to learn debbisect I tried it against this bug. I hope this might be useful, or not :) Early on I noticed that the issue can demonstrate itself in two different ways: 1) wget fails with "200 No headers, assuming HTTP/0.9". The original steps to reproduce included "2>/dev/null" which was hiding this. This is apparently bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930574 2) kernel reports a bug in dmesg and sets /proc/sys/kernel/tainted to a non-zero value. This is the case I started to investigate. Using $ debbisect --qemu=defaults --depends=linux-image-amd64 --verbose --cache=./cache 2019-06-01 2022-06-05 ./script2.sh I see that the issue occurs with 4.19.0-5-amd64 but does not occur anymore with 5.2.0-2-amd64. The helper scripts I used are below. Note that I had to negate the "good" status to find the version that fixes the bug instead of finding the version that introduces it. script2.sh #!/bin/sh echo "script2.sh starting as $(whoami)" ssh_config="$1" scp -F "$ssh_config" script3.sh qemu: ssh -F "$ssh_config" qemu ./script3.sh script3.sh #!/bin/sh set -exu echo "script3.sh starting as $(whoami)" env APT_LISTCHANGES_FRONTEND=none DEBIAN_FRONTEND=noninteractive apt-get -o Dpkg::Options::="--force-confold" -o Dpkg::Options::="--force-confdef" install -y -q samba apache2 cifs-utils curl tee -a /etc/samba/smb.conf
#960195 linux-image-5.6.0-1-amd64: Please enable CONFIG_INTEL_TXT=y
Hi, tboot is now in testing, is there anything I could do to make it easier to enable this config option in src:linux? It's such hassle for the sysadmin to build their own kernels that it would be really nice to be able to use tboot with official Debian kernels. (It would be especially nice since the cryptographic hashes would be verifiable by a third-party more easily). -Timo
Bug#960195: linux-image-5.6.0-1-amd64: Please enable CONFIG_INTEL_TXT=y
Package: src:linux Version: 5.6.7-1 Severity: wishlist Hi, can you please enable CONFIG_INTEL_TXT=y on x86? I am in the process of packaging tboot for Debian (#803180) and it would be nice if users would not need to rebuild their kernels for this. I have used Debian kernels rebuilt with CONFIG_INTEL_TXT=y on both servers and laptops for around three years now without noticing any drawbacks at all. Here's a work-in-progress README.Debian file for tboot that might give you some perspective on how tboot is used. tboot for Debian --- Background -- Trusted computing is a broad and complex topic but here is a short summary on how tboot fits to the picture. There are two main ways of performing measured boot. In SRTM (Static Root of Trust Measurement) each component measures the subsequent component in the boot chain to the TPM chip. The TPM chip cannot stop the boot process but you can store secrets (e.g. disk encryption keys) to the TPM such that they can only be accessed if the TPM has observed unmodified measurements of the boot chain. In DRTM (Dynamic Root of Trust Measurement) a special CPU instruction (SENTER) is used to enter a measured launch environment that cannot be affected by the software that was running earlier during the boot process. Similarly to SRTM this environment is measured to the TPM. The main benefit of DRTM is that bugs in your BIOS or boot loader cannot be used to send fake measurements to the TPM. The main drawbacks are that it requires a CPU that supports the SENTER instruction and that it is vulnerable to malicious code running in SMM (System Management Mode) or ME (Management Engine). It is possible to combine SRTM and DRTM. It is also possible to use them together with Secure Boot to prevent loading untrusted code. The tpm.mod module in the Debian package grub-efi-amd64-bin can be used for SRTM. This package can be used for DRTM. AMD has its own instruction for DRTM, called SKINIT, but tboot does not support it at the moment. Getting started --- If you want to boot Linux with tboot you need a kernel built with CONFIG_INTEL_TXT=y. Currently Debian kernels are not built with this option so you need to rebuild the kernel. One way to do that is as follows: 1) $ sudo apt-get install devscripts 2) $ apt-get source linux 3) Edit debian/config/config and add CONFIG_INTEL_TXT=y 4) Edit debian/config/defines and add "+txt.1" to abiname. If you don't need real-time kernels and want to save build-time you can also set "enabled: false" for featureset-rt_base 5) $ dch -i 6) Add "+txt.1" to the version number and save the file. 7) $ sudo apt-get build-dep linux 8) $ env DEB_BUILD_OPTIONS="parallel=$(nproc)" dpkg-buildpackage -rfakeroot -us -uc 9) Run the previous command again since it intentionally fails on the first run. The build should take around 2-3 hours. Note that you also either need to specify the boot option intel_iommu=on or use a kernel that has CONFIG_INTEL_IOMMU_DEFAULT_ON=y set. The boot firmware should provide the ACMs (authenticated code modules) needed for Intel TXT to function. If the boot firmware does not do this then it might still be possible to use TXT if tboot loads the ACM modules from the filesystem. These ACM modules are non-free and not recommended. For more information, see for example https://doc.coreboot.org/security/intel/acm.html Common misconfigurations This package does not provide a complete solution for e.g. TPM-based disk encryption. However, regardless of what solution you end up using you should make sure that it avoids at least the following common misconfigurations: 1) If you use a normal Debian initramfs you can easily get a root shell without affecting TPM measurements e.g. by disconnecting the hard disk during the boot process. One way to solve this issue is to use the boot parameter panic=86400. 2) If you use LVM inside your encrypted LUKS volume it is possible to trick LVM into activating an LVM PV from unencrypted media. If you provide your own /sbin/init on that media you can execute arbitrary code as root. One way to solve this to use e.g. filter = [ "a|/dev/mapper/md1_crypt|" ] in /etc/lvm/lvm.conf. 3) If you use an UUID or GUID to find the root partition an attacker can similarly trick the boot process into running their own /sbin/init. The default configuration in Debian with LVM on LUKS avoids this issue by specifying the boot parameter root=/dev/mapper/HOSTNAME--vg-root. 4) It is possible to trick systemd-gpt-auto-generator into activating an unencrypted swap device and mounting an unencrypted /srv partition. This can lead into arbitrary code execution. One way to solve this problem is to use the boot parameter systemd.gpt_auto=no. 5) An attacker can tamper with the files that are stored on the unencrypted /boot partition. If you support automatic updates with forward-sealing of data for new
