Bug#999551: Support Landlock by default in Debian kernels
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey Mickaël, kernel team, On Fri, 2021-11-12 at 12:23 +0100, Mickaël Salaün wrote: > - > CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack > ,to > moyo" > +CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,sel > in > ux,smack,tomoyo" > At first sight the change looks reasonable, but just to check: right now there is there is no userland stuff using Landlock LSM packaged in Debian? So nothing is currently broken by not having the above, it's just more practical when testing or using the feature? (not saying we shouldn't enable it, it's just so we know what exactly we gain or not). Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmGOX14ACgkQ3rYcyPpX RFuWRQf7B96Z1IoKkm7qbHswja4TmPuM2cJcBzXJLX0t591MO2D/GdAS08w+/kTL ALUJSXKiDvcC9AmzKD4tFszs13NJwSXlhUB4sflqLk2TBltDEhSdlVSwAw2UGHxx /NJRqH7nMWvMeghO/SLkaoXDEOAIQUR75cyQs1/oQIcfmYx+A68cr0DarEJKWUM8 SrLWTvY90IKKyBwKEY3hT/qFtb+YhPRp76tykT0J25b55EmkPO/f3p5vz+uUBG+N WaKS+KKI1D4XubcmOOfa09XMh1OnZ1u3Jd6WZopcB7G2I18j/ejDXiz1pPDC7BrF 7nh/V2L7YRv0r4ppP5QwglLgRF5SOQ== =xSao -END PGP SIGNATURE-
Bug#816176: linux-image-4.3.0-0.bpo.1-amd64: xhci_hub_control causes abnormally high CPU usage when no USB devices attached
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2021-05-06 at 20:11 +0200, Moritz Mühlenhoff wrote: > Is that still an issue with current kernels? Hi Moritz, I don't think so. It's been a while since that original bug report, but I don't think I've recently seem some high CPU usage related to the usb drive (I can't believe I have that laptop since 6y already :) Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmCUOEIACgkQ3rYcyPpX RFtlLwf+N2xMDGSm+11cYH51sXF5jLry9R6/QaIz50WyGAy+JtPyzTFJ/+TLaI9r n6qCUhFul0WJME8c5IQPEq5PP8r0rQkgmkczUmcF+tIAkUFd2T4g0tWbEqp+MJqc GeUhwCSgRQ+41frz1BKsmUjTsLfLCgQxVR1KuttFQM8rkVPbYDWnd7WdKtr5Y+DC QQUA5IIiOuU4OM9sttkiYu/aEE2nL93xXKA8WOjWjCluIIRhe6mNg+bqhiIxmTYm IBpHkR17Bj+hdypprBR2hOT3+0uQtIc9c03FqF5SqGzhIkg8M5zZRoN81vmP+q1z rHF1kubxQYEp5ic1wKGYIWEDkcEWvg== =b2Et -END PGP SIGNATURE-
Bug#924545: linux-image-4.19.0-4-amd64: many errors "PKCS#7 signature not signed with a trusted key"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 control: tag -1 pending On Thu, 2019-03-14 at 12:38 +0100, Yves-Alexis Perez wrote: > Hi everyone, we're aware of the situation and will try to fix it as soon as > possible. It should be harmless when not running with Secure-Boot enabled. The issue should be fixed with the next upload (4.19.28-2). Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlyLca4ACgkQ3rYcyPpX RFtxiwgAzLqe95L3cXCwSuByd73VtKsoSCrH90zY5edHrerOiZvmOiuvPtinEBEL rDMIRJeW4KDIrnOo7kPPjTsrUqEkm8LJ+gQlLA59qoP2QVsegeD+ohqTSsAucnQ4 CmjCs+8hBCM+Jz4U+D4eAe51OH976a3LqI+EOnz8j8qCaSJ5eD6X3N/E9YWmBspG 2qJAFLPZHC11zEuazYekfSz2smX8Mjz7/QduJI4c2P/RU0+C3vBW58qFrbiluh9C C3Hit9aivT2Z99xyRAcP1XqeLQpFUFdbwNaFVjw4/vhQLN4tg/F/Cw1ae1vUSRYg 9A2cZ0A+buXajHfKp0c9Wr1UdG1rug== =2hBL -END PGP SIGNATURE-
Bug#924545: linux-image-4.19.0-4-amd64: many errors "PKCS#7 signature not signed with a trusted key"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: forcemerge 924545 924549 924553 On Thu, 2019-03-14 at 11:03 +0100, Vincent Lefevre wrote: > Package: src:linux > Version: 4.19.28-1 > Severity: important > > With this new kernel, I get the following error 487 times! > > PKCS#7 signature not signed with a trusted key > > cventin:~> journalctl -b | grep -c 'PKCS#7 signature not signed with a > trusted key' > 487 > > There were no such errors with previous kernels. Hi everyone, we're aware of the situation and will try to fix it as soon as possible. It should be harmless when not running with Secure-Boot enabled. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlyKPRkACgkQ3rYcyPpX RFuNygf/bdkYZykbPqNZ9bmFZIsdXeRsaAR0AD3O68DM6oIwR2xSh8y/ip5u+ciF 4Aud1xq6vndf0inOE6+vUfzIFf1wRyX06PdELK6MB3G9XAZ5DgddEup6Rry2ryVF MvwYOgbJc7FQZuIj0Y4NNBwp3NF7OUvDcJDMhRXnnuOVu/+JZb+mjXiNFqW3Pf8n h1SNrxF6f3MQDkKxXZygrcUuD9aKUr2GWNRPO7b14xIabHEeEnWnnYGnNIleqoST TnOthA9X7B0+1ZbLxTLRPyo2E7sYfSa2eR4FBqOEiNVV8FvEWMgIPi1yNL427JN7 1wR8pt2PBv/zfGHW0DESdwZ/Gh52UA== =p+yi -END PGP SIGNATURE-
Re: Upcoming stable point release (9.8)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2019-02-01 at 03:20 +, Ben Hutchings wrote: > As there isn't much time left before the point release, I am inclined > to make one more upload based on 4.9.144 that just fixes the ceph > regression and any other known recent regressions. > > Does anyone want to argue for updating further? Hi, I'm usually in favor of updating, but here we have a large delta between proposed-updates and current (.150/.153). There are 319 commits between .144 and .150 (and 431 for .153) which would be nice to have since they likely fix quite some stuff (although they might as well introduce regression and we don't have a lot of time to test it). If we go for .144 + ceph fix, how do we handle the git part (since stretch is already at .150)? We create a stretch-9.8 branch or something? In any case, I'd say we try to upload .153 (or .154) to proposed-updates just after the point release. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlxUFJIACgkQ3rYcyPpX RFswvggAxEpFBnG68D2yTkNRlkwPVcmT+YfAurt5Z7ghCFNou7EfXU/YV8Q94qUd 4nmaZJIovv5qIWRK8k1nFkvpV+9R9lZb02K/n/FB1L/KBHjXOQWx3gj50vXiwAoR oQvlhv/fXi6WLTqxfeV+bxDpWpUxlmGWV1ZcuAZs8P7aXEdrcjyes6IoCXcCHkby 8hbMHkeW7LX26f105qFS9XmKK7bNogiP/LsGdrsgAVFY4ghxkpZ+wwEcpiYl8F3c cpo0RNHhcqffyHziSmDZMd0MUSdUfMy33d3q9FjQKzZndjVBm+dlO6WnAsDgs7xd 3Gxrx1BwHrbwkEIuetCDkpC42xDmRg== =pZ73 -END PGP SIGNATURE-
Re: Buster: 4.19?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2019-01-18 at 10:58 +0100, Harald Dunkel wrote: > is it safe to assume that Buster goes with kernel 4.19.x? Yes - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlxBvnMACgkQ3rYcyPpX RFv2QAgA2DQk1Is0vcxtey5A27Yj4i5CQAxP5DBMDYIqrMTllIb1upMQoMeSFFdL yYXwDdL/nzvFXtaYqjh6hQIlrOvZW6ArMyszk0IAz+DFjGs9nOouExZ9olH5AMGH Ygj3FDb93V06P9BxQZq463IsGkZA/Phx2tZo6Eq6KL2wUbZAfI6mULWYHNfkSWRb Zk6NvrAbLQW2xRTMQ/N8M4bOoBv/VrgaM16dsSF3zw3cvDbGFekYcchjYZrzetVV CGUB5XUm0bF9IXJ+npqwCMuwuQ3jnKLEiejzxPb/rhOgnVXvO6BqdAm7qww0Rley TW9tot/ALnDwQyIlDsFyjbYVLiymrw== =n/1n -END PGP SIGNATURE-
Re: Request to update megaraid_sas driver in Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2019-01-17 at 12:44 +0530, Shivasharan Srikanteshwara wrote: > Currently the GCA kernel in Debian 9 is based on Linux 4.9 kernel which > does not have inbox support for new MegaRAID Gen 3.5 controllers. > Is there a way to include the driver update patches that add support for > these controllers in the Debian 9 kernel update? > FWIW these patches are already present in Linus' upstream kernel tree as > well. Hi, the “easiest” way would be to have that updated included in a 4.9 point release, which would in turn be integrated in a later Debian package version. It might be possible to include that backport (it's been done in the past) but it really depends on the size of that backports, the dependency on other subsystems in Linux and the amount of work required to keep it updated later. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlxARm0ACgkQ3rYcyPpX RFvXXwf/UeR0zx5gdAt9ltBL7veX+kAT5WTHdLGFMrFY5bURMvuTDvQg1mL89tsP qMyStl5mgyU6rHbVrLjUVRWdBCZ1cGfwRUyCDO0Agqc2i8fUG7Fc7jX0X4bgoqHi /Le2aVpgaEyWMZVM5OOeqEW9UPAEDsVK3xfgmiOf4MmjEdDlgJttRuXSzyECC76i vPEfFP/9J2cuWuvVUX245yv5RGTXnwCgrqTmbr1rxCpQjC4ReSh0S1kYKX/aWpyv sPJVYTc3OtErssAd4seo/zdKbRM35NZoz5LKNDYZBGMcLaQ8ECFTRVvbT9OZG//y m2aP+WDUEgu6JfIll1iHz9cbEiQfnw== =zLZK -END PGP SIGNATURE-
Re: hardening-check can detect whether kernel is protected or not
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2019-01-02 at 17:37 +0100, Mikhail Morfikov wrote: > I have one question. Let's say I set the kernel options that are described > here[1]. Do I have to use DEB_BUILD_MAINT_OPTIONS or set any additional flags > in the debian/rules file to get some extra protection? Does the > DEB_BUILD_MAINT_OPTIONS variable do something in the case of building the > linux kernel? No, DEB_BUILD_MAINT_OPTIONS is not used for that. If you want to tune the kernel configuration you need to follow the kernel handbook ( https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.3 ) Most of the kernel options recommended on the KSPP page are either enabled or not relevant for a distribution kernel. There are some left which would be nice to have (like some gcc plugins) and unsupported for now, but that's all. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlws628ACgkQ3rYcyPpX RFuq7wgAjwEGti43/zBpdxYSodwujnyh5CGN9k2KDpKtd4UtEJRP9+jWOT3eFuo3 8lKN+nojE7DuxYSJmW9NgXV95DNh1mx191ADRs3brbtV30dSoVP46EfypD/w4rVR u2QJEEZueQiR7y1qE1nqfhuNY+OTSTlgeYsHbOQ4S5hyn7Yvu3gUf3QXaMOVybnu +7sbfc62mnXuvwywYU2H891SSjjDd4yf0YUkr1uWWdhWHMvzBulEsj6s8b0QBvWq DPJAGKd/CUp66R8DVyfY68G7rCam+lrX4DeK3gpPR1npFyIptMdXin64vXRhkaJr 1vZ0ct5r2p8GB0Un7371YEJOIvaQGw== =1cPi -END PGP SIGNATURE-
Re: hardening-check can detect whether kernel is protected or not
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2019-01-02 at 03:08 +0100, Mikhail Morfikov wrote: > So does the kernel is protected or not? If yes, why hardening-check can't > detect it? > Also how to get "not stripped" instead of "stripped" kernel? Hi, the kernel is not a standard ELF binary, so you can't really run hardening- check on it and expect sound results. Yes, the kernel has some protection/hardening (see for example the work done by the Kernel Self Protection Project). Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwsyqUACgkQ3rYcyPpX RFtdiAgAvD9bj/rTlhbHMOkSQQbgoAcpksqIFJQ9HaCMVjDwb6RWc3Dz0IQItJnu nj2tLZ6An8LJXo5oAoMTCBvBvWGt4/NsedYdVa1Q/610llWJqHg/VfMR4TZaoN8J 0ZWCGD2qwAMx5MZYJ7GQYlXqRpBp+aRvdHd3+DlDo7O+vEKuoQb0bXYolqkgnV4L UQGgtbCjVfE7V3/pmfBOMBk6ZhpxilLROmFTtL5abtNh81T6P+sOaFKfOjRcufE3 Tmb7qqK9IRJLL48WUtwX5mXyWl/TOTaig23ESfwWOvmCy1pGvh4fERpY9k3W9Y2T D9iXxQ4nN6yBUu9PXxs76h/IglBEVg== =ORnQ -END PGP SIGNATURE-
Re: why is the build so complex ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2018-12-14 at 14:13 +0100, Enrico Weigelt, metux IT consult wrote: > When I look at the build rules, I really wonder why it's all so complex. Hi, there is no simple answer to that. /Maybe/ the build system could be simplified a bit, but in the end the src:linux needs to build a lot of complex stuff, needs to be generic/modular etc. If you really want a simple way to rebuild one kernel, maybe you can just look at make bindeb-pkg target of the upstream kernel Makefile? I don't really think it makes sense for an end-user to maintain a local fork of src:linux. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwTxTYACgkQ3rYcyPpX RFs0AggAmltKGCjTf6mFwRHxCpF1pqnMhmWzMkKUMUIL5MBGar3OtJECT2tPtJ3X u0HkSygxUS8t0V5X5Atz3B1SLLeGe//OlOFKfCn4rdFaF7rPC+nFaZI4X0dg/kja qmo13wdmeNtlFu92YGr5DEgdaHTGSL3nsuG+PNTmYp6yR/geC+T1sHwyE1gHuumC t5PJKtOiwFhHhVv4m9bU8q4jbkELjfrt4X07v5jemh+JxMuH4JNgTu/CS03kWzXL 780kVLd4+KcdqbE/yopYYIWMti8Pk1D1LIVlRae9PzxYcXIxTCmmIzJu5ulAlkQb qjlzupUytAPxC4zQ+DMj0kyu/8j2ww== =0tR4 -END PGP SIGNATURE-
Bug#898814: When I log in, it hangs until crng init done
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 2018-12-14 at 10:24 +0100, Yves-Alexis Perez wrote: > Something puzzles me with all those issues: as far as I can tell, on most > install, systemd-random-seed.service should save a seed at shutdown and > restore it at startup, and this (I think) should be enough to properly init > the RNG. > > Can you check if the service has been run in your case? Hi again, actually don't bother, I was pointed to [1] which has explanations. The random seed load is done by just writing to /dev/urandom which doesn't credit entropy [2]. But there's apparently an RFC [3] for crediting that. It's just a bit complicated to impose trust on downstream users. [1] https://bugs.debian.org/912087#118 [2] https://sources.debian.org/src/systemd/239-15/src/random-seed/random-seed.c/#L108 [3] https://github.com/systemd/systemd/pull/10621 I don't have good solutions right now. With 4.19 and if your CPU has an RNG you're willing to trust, you'll be able to pass random.trust_cpu=yes to the kernel command line, which should help seeding the RNG. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwTgDgACgkQ3rYcyPpX RFsyoAgAkbtHav7ce39vm+XnPJJeH7mBNRd3ff28Uy3JMQcweet1jKcqMDm0po/T 4f+zCGhHuR6/spuO+esHF7/jSRG8QW00jSqW7+9HW8EdUu8MdYMyg6/119U7RLXm BqrjcXlWgpDYS+QcTGV939EAlhhA1QvpftuZ5stzLnl1Q4OTiMEfSCubFACB0knl q7tpEUQTFywFD4oSAXiShLacUwSbxDkBbUcjZFHiFVpUDCs6JHdZvCt+giNxZrF0 8niQlxzlhaML2976lZQbfOjOVWVY8o2oVdDlr/7KhE1uivXpE82A/LZNCZwM1Dm5 c4OwK5tBoBGSgcTSJw8j9BvtL+ZvWQ== =NQnp -END PGP SIGNATURE-
Bug#898814: When I log in, it hangs until crng init done
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2018-12-12 at 14:25 -0800, Xilin Sun wrote: > On Wed, 16 May 2018 14:55:07 +0800 =?utf-8?B?56mN5Li55bC8?= Dan > Jacobson wrote: > > Package: linux-image-4.16.0-1-amd64 > > > > I am also experiencing: > > https://unix.stackexchange.com/questions/442698/when-i-log-in-it-hangs-until-crng-init-done > > I am also experiencing this bug on my sid amd64 on a laptop (Acer Aspire > S3). > > Linux 4.18.0-3-amd64 #1 SMP Debian 4.18.20-2 (2018-11-23) x86_64 GNU/Linux > > Installing and enabling haveged (http://www.issihosts.com/haveged/) > solved this issue for me. Something puzzles me with all those issues: as far as I can tell, on most install, systemd-random-seed.service should save a seed at shutdown and restore it at startup, and this (I think) should be enough to properly init the RNG. Can you check if the service has been run in your case? - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwTduMACgkQ3rYcyPpX RFtASggAxyL/vgfbbHNTsWpyXKuTlXmPJFTWGYTsZ8uVB0t+8ndehIyr4XHihEpe 3F9VyqRtBXqNN4wtsw0rb199lXZTkxJJ5DOHWRKR5fnlsVYo2hv2PJtchNM89OpK jXyuNuIooAZjpQf+xan3JSJRSEHhaBqcNp1AzQy8I3Sbw+rFil19jVLja7orOrbr ODR0zZyjQCtE5W7Q8yjiFE/JrnvvATQ8fndGrVA3gjydRx53gMqgvVvE+hOwySqL z8jdmgUeh2mtj/z/XdGeDM8cavqOLFzI1NBGiF0iJJlDuJR3ljYzqaskVIyy8ezr ZlQ3IOPkbdteOOtQq5ri5ClHK/FLcw== =5t4I -END PGP SIGNATURE-
Re: Bug#912977: iptables: nftables layer breaks ipsec/policy keyword
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2018-11-05 at 13:08 +0100, Pierre Chifflier wrote: > Package: iptables > Version: 1.8.1-2 > Severity: grave > Tags: security > Justification: breaks rules, inserts pass-all rules > X-Debbugs-Cc: t...@security.debian.org, > secure-testing-t...@lists.alioth.debian.org > > Hi, > > The debian package for iptables now transparently converts inserted > rules to nftables, which is great. > > However, some keywords are not supported (like the 'policy' keyword for > IPsec transforms). The bad part is, these rules are inserted > *without* the matches, which makes in some cases your firewall useless. > > For ex: > # iptables -F > # iptables -A OUTPUT -m policy --dir out --pol ipsec --strict --mode tunnel > -o eth0 -j ACCEPT > # echo $? > 0 > # nft list ruleset > > chain OUTPUT { > type filter hook output priority 0; policy accept; > oifname "eth0" counter packets 90 bytes 26085 accept > } > } > > As you can see, the inserted rule allows everything, while the expected > behavior would be 'only if going through an IPsec tunnel'. > Even worse: inserting the rule did not fail. > > Until the 'ipsec' (or 'secpath') keyword works properly (and supports > all options), an acceptable behavior would be to reject the rule if one > or more keywords are not supported by nftables. Hi all, actually, I think it would make sense to actually bail out early with and error if any rule or keyword is unsupported by the nftable backend. I've noticed the behavior because it was announced in NEWS.Debian (and I have apt- listchanges) and I assume it'll be put in the Buster release notes, but I think the executable itself (or maybe the kernel part) shouldn't silently ignore stuff, because indeed it can open holes in the firewall and break user/admin expectations. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlvhgm8ACgkQ3rYcyPpX RFvd8AgA61EMEQiHhYmV+5I8DvUCuOaHQkW23pQQeN5jYMc8qE3QW3BX7NDhvOFc xeKSeft4zc5uzGV4K3UvaD0g3F1rq1FqaSLpUYWxO27B59y5etvMz8x9k+GZn2gh 3ZHOb2PmnwTl3sj99F5gdzTI6aDU/50ceHPC1C+Z0fBL5aXElAcO9tzvxP1oGMr/ u1t3teLPNPuuuM4s32s8IUaiiUvJ3IBAuv4J/h3qzMixWyki+XNq3slrxHGARLL3 KY78QAfu7MkvJ6B3iiMuDzgfRYyYy/PZJl9B4aqX+rmRE4mFKAftGCvFix+0EGBB EPzws0ExVehsLkOBCgTAj0OQeuVXNA== =XxmO -END PGP SIGNATURE-
Bug#910765: very slow boot with backport kernel (+workaround)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2018-10-10 at 22:49 +0200, stefano gozzi wrote: > Debian stable (updated) with kernel 4.18.0-0.bpo.1-amd64 #1 SMP Debian > 4.18.6-1~bpo9+1 (2018-09-13) x86_64 GNU/Linux > > updating from standard kernel to backports, the boot is very slow (gdm > login appears after ~3 minutes) Hi, can you confirm that reverting to 4.17 fixes the issue? It looks similar to #910631 (except with LightDM, and I'm waiting confirmation on the kernel involvement on that one). LightDM seems to use /dev/urandom which shouldn't block at all, I wonder if there's something else involved calling getrandom() without O_NONBLOCK, or if there's indeed a regression in 4.18 rng. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlu/A+IACgkQ3rYcyPpX RFviZAgAtbkjzapCuWOTvO6rJ5WseDMr5Z88dblxnGyqY7wdh+H2BrwYRyxiZZXw vyHhXJDInh+Zfii+cQiZ9derVZwLFkuNULagUNbJDbAWceMYqw1fgctIurRvCWJ0 XBBsj/KMuzSMu6d5bw7X3P4t9nnPAxoBnlipV3eKdoau8rTqDygeViHBrZtAlMa1 DvNv2UZ2wicd3H0jnDbm0gAlrh89ZdD9nQ4nASr5kfg29z8F0t7/wFrWefdnbU8j DfkcxmB4Ok4C9Sx/etooxVcJAFvPQe6LaN1Ytu+Yr9vd3NcWKBteblXH30Boqmn4 QOa3f20tdOViYCAdu2vJZD7+TYF/bQ== =nbiP -END PGP SIGNATURE-
Bug#816176: linux-image-4.3.0-0.bpo.1-amd64: xhci_hub_control causes abnormally high CPU usage when no USB devices attached
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, 28 Feb 2016 12:19:43 +0100 Anders Nylander wrote: > Following the removal of of the USB device, I noticed very high CPU usage > being caused by kworker and ksoftirqd. > Using perf to log 10s of data and then reading the report, I noticed that > xhci_hcd/xhci_hub_control was generating a LOT of work for the kworker > (~42%). I'm experiencing a very similar behavior on my ThinkPad X250 attached to a dock. It doesn't happen every time I resume, but quite often these days (on 4.18.8-1). Unplugging an USB3 disk plugged to the dock fixed the problem for me, and replugging it worked as well, so maybe there's some kind of loop I managed to break with that. I also noticed https://bugzilla.redhat.com/show_bug.cgi?id=1325488 on the exact same setup, but there's no other info there. I'll try to dig upstream, but unfortunately it's not that easily reproducible here. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAluqfCEACgkQ3rYcyPpX RFtQ6ggA36IjHB87mtIr2ciKDn2DY5afR2oWQ1zlmKXBRQBwVTSxxVFOJ/HP8Mhi flNOTgChEDjs9+cZiWAPxfJkEpbJBkXxVrios0/eRaV5drpCh5oo3h40ln1E4H+M 6ouvDvKtOo8szqJppE2ATYIZ3uXknaN53b2bDAUvjuPHTp688vk47hTCL3rPjVTL LQifiMHWQcqixodBZTh+uQxdDDjKrQ7bVY0gUjAEEkQq/2wgAm1RFtYtHAMfvfek 6gWmQ58mRsaEVTWPaLqSBhybEfvw8djlNo4sp2F/rT/0Hzp1OCIrzbQDUnGB9ttP VF//XAvs8/5ChbhMPNXNRCkS6CFxBw== =EgQP -END PGP SIGNATURE-
[stretch-pu] Upload of 4.9.128
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, [in case not everyone follow IRC] As far as I can tell, we are currently on sync with upstream for 4.9 (at 4.9.128) and it seems that we don't have ABI breaks handling (at least on amd64). Would it make sense to upload right now so we update -pu (which is at 4.9.110 for now) and get a chance to test the whole build accross all architectures? As far as I can tell next point release has not been scheduled yet so there's no urgency, but I think it'd be nice if we could generally have more testing of the kernel in -pu before the point release is done. I can take care of the upload if needed but it's merely about the decision I guess. Thoughts? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAluop0oACgkQ3rYcyPpX RFtSIwgAzKE0goZlAeYeaauh0Xarl47EBJTwOfOzMcadNN9+Xv5InN7kQFY2fk6z EgOx5ayAhxd46iWz++Kfh5/Nq5hH5UepazGfvsiEdtQnRVD5++/ezq8LZACIPiSH L/gvJNfMpaSf93Nk6OBsuthyzLFzuRMaonYmYSM+g579BnnerI5GfN5WGdLRjZxz bo288y4rNwCjvIPdPYS9gLjC6d+mqT7HtbraSnalwoxr9xUfGB+vVMLIVhQu3CQs b8ZdqvfCFg8FzgoJ/uS/JvWz7CrEnbZqOixw+NcnQUf+kZmkMpP9U7Ip34IwuNY/ 34F0JxSt6ab8ra5Cf8v6+OOy4SG8cQ== =HHjS -END PGP SIGNATURE-
Re: Kernel team meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2018-09-17 at 09:52 +0200, Romain Perier wrote: > I had in mind an online IRC meeting, so logs of the meeting can be > saved and retrieved > later by anyone. Sounds good to me then. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlufarAACgkQ3rYcyPpX RFvlKwgAyD1e19fZrNDpUpXkv6X75ReKjtYuR/YBRKniDr/YgL0fsrH9BJXHmgcR 1Q9arDIfYN8TCiWyAmO88mXnukdQARapKZs/By3LPLDc4waAaugtduK55eo4MWdQ xC1HsHNXyQdydDlHRsNbryb/0qQpE8swA21QirUv17HEf6TJDaI4Vt3nC8NnznG6 x1eFuH6YLk5r+KYNrE/Ib9VFlaR1QEPr/hHsrc9GS6LzHzOkQcgVhp9YhaYZjWuH MPL6MKxOOjFya04T8+jvNBt6AcupZtF51Dkakpk4ZXhW/zJHNw5PZqpWdhftW9jk FcWzSd7TEuf5YeWLBVjwuHL/l+WyYQ== =yFpK -END PGP SIGNATURE-
Re: Kernel team meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2018-09-15 at 17:37 +0100, Ben Hutchings wrote: > Yes, let's do this. I would be happy to meet for up to an hour with a > defined agenda. Can you set up a poll for when people are available, > and an etherpad or other shared document for the agenda? Quick question for both: are we speaking physical or online meetings? Seems that “an hour” and “multiple time per year” indicate online, but a confirmation would be nice. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlufVjwACgkQ3rYcyPpX RFu7MggArLUIAjrxQEpsEM+ap2bcXEnHMoiGdbx5XpVpoMHi4xvEZeiakxEpq9xg jQJftcArt6YTVt0Wmr8nT4K3nrpthYp3tFyYyaJWJSRjrppXG7CMmlB1lHqJuZJN ckf00Vqtkfrcjvp2/6tfWXQNaaK6aAzCBT++zgMk2Mmczedwp7QomDrvD3FuIW4m zytIGpH7O39CvrrTFeFObkjKeTuTlnYqJHTIzxDxmNzq0VLncg/MG8gBMIvDXncu D4Ck9LJcx95/Pdd+9VGnXTR8Gz/6AsJAuVt8A5Z1AajVM3XRI3rBKQnaeTzrQ27o Ap9VHTShwQfyLLRO6mfzE/MctjxuXA== =TnOn -END PGP SIGNATURE-
Bug#908570: linux 4.18: dmesg readable as normal user
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2018-09-11 at 12:01 +0200, Philipp Kern wrote: > Source: linux > Version: 4.18.6-1 > > Unfortunately I have experienced this on a rebuilt package and cannot > easily test with the one actually in Debian unstable, but for me dmesg > seems to work as a normal user again. "cat /dev/kmsg" just works: > > [...] > open("/dev/kmsg", O_RDONLY|O_NONBLOCK) = 3 > lseek(3, 0, SEEK_DATA) = 0 > read(3, "5,0,0,-;Linux version 4.18.0-1ro"..., 8191) = 157 > [...] > > % grep DMESG /boot/config-4.18.0-1rodete1-amd64 > CONFIG_SECURITY_DMESG_RESTRICT=y > > (We do very, very minimal patching to the kernel to make it work for us, > hence the different ABI version. And it'd really help us if the ABI > version were to be bumped with every upload.) Hi, what's the content of kernel.dmesg_restrict sysctl? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAluXoQEACgkQ3rYcyPpX RFvgjAf9Eved9RcnEV9wTL7afPosjoM0VdVBKZ80e9uYCTJHQ3zTkVkpBXAEVMgO uGkqDhqImtnPp4bR9bHFFwXMnCOHbJL/GKEZQ9CikNZmUuj3OUgs7+jonJL3z+tP XZCmU/A/BnHmuGLwc8wctS6Nz7rMROhOmdd/NAtsLtK0So6xS+s/T1rGq2HGdsrs X6ltIqXoe/5FECbejurPR7GoeQuDULxK91NAoc6YeNu/ZmyD9A5vQdc5x9MPw4zg kO6Z/S1qYuwjzqNpSr+0HYKg4kU3EqJLxyfLUC4ojGIdHg0Q17JmAy5h9cUW5PpS lE+WhCsVNyhfjBQjZU5HmcrJ8KPOjQ== =Jn7s -END PGP SIGNATURE-
Re: Debian Kernel info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2018-09-05 at 19:43 +, Tomas Bortoli wrote: > > I noted that some hardening options are disable, by testing it against: You can check https://salsa.debian.org/kernel-team/linux/merge_requests/26 for various hardening options. > > https://github.com/a13xp0p0v/kconfig-hardened-check > > such as: > > CONFIG_SLAB_FREELIST_HARDENED SLAB_FREELIST_HARDENED is enabled: https://sources.debian.org/src/linux/4.17.17-1/debian/config/config/#L5977 > > CONFIG_REFCOUNT_FULL > REFCOUNT_FULL is enabled on x86, not yet on other arches: https://sources.debian.org/src/linux/4.17.17-1/debian/config/kernelarch-x86/config/#L5 Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAluRCyUACgkQ3rYcyPpX RFv7jwgA2s2AQsHlJX3Vl/G+ORoKmYb8Xy2Bpdiuwe/cxE5k/l6odj5BsuIS9T1S sA/3PBO89hLL+09r1Hs6q6rB7alLnaYlVEqQbWl7S1T6GzOIWQPNBA5CztdjJBTV /friUrayA4BgyAVgWo0lwzEiDazjLpQJ0PSG5PdH6yonMwcG7Aq3ieG1w9MG3p7V DoVluOhT8vcsWCj8d6g1LMloibq9buaU/vFcP4Uw9LacFEHcl3SvJiwALP5/QsvU Fr+fAZLSRR4JDP9a3uXPznGdjuTlZCv6vsB6RfNihmv6CdxNd09fe9eqLdpSzBG3 amXJEFsoX5VKeNvxtFHKm3MMxhg65w== =XcUR -END PGP SIGNATURE-
Re: Debian Kernel info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2018-09-05 at 06:48 +, Tomas Bortoli wrote: > Hi all, > > > is there a place where I find the config used to compile Linux for the > latest Debian ? > > > The alternative idea I had is to `apt source linux-image-version` but that > requires to download the whole package. > In the future (in experimental right now), you will have the linux-config- $major binary package, shipping the relevant configurations. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAluQKXsACgkQ3rYcyPpX RFst7gf5AQLgYulEG+vbVTnRZUVMTCZpWf55ncjsjIsGPepDDpEPZ6weDtVhk2ua 9F+8DTLw9soqhK4pwrSc1L3Fk1jpfCNPX9vZy4rtbSiHQscJMaB6ucylVcz+oFKn Rup7EyWUVgcwGbdsj1C+UBAerpQ3/2RXOgm9QRrRAVOqZbsIdkXGQPtGga0qJWL0 4Fjxc6qEUmoIYW9CT/+BsdMjaDL778g2MB2+SJiMf3JVaqum30imXWhJvEWbMpgw 5SgQ8jCWV01M7HBcvTSnmhPEGesD/l89+JwHwoGm7yOyPEl0MQXfjyEJZZNps+96 pcgcWw5fPCMSTWk4jBSlzirHmU8Gfg== =gLWa -END PGP SIGNATURE-
Re: Regression in 4.17 Kernels (?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2018-08-23 at 14:20 +0200, Rainer Dorsch wrote: > Feel free to ask, I am sorry that I did not provide more information, but > since there is nothing in the log files, nothing on the screen, it is hard > for > me to provide anything useful. I could switch to a VT which the scanner is > running shortly before the crash, but not sure if that helps. If you manage to reproduce the crash that way, I guess it would help yes. It might help to increase the dmesg log verbosity too. If vt switch is not enough, you might want to try using ssh or netconsole. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlt/y/8ACgkQ3rYcyPpX RFt0/wf/aDkcDb15t7iM/8KVAOBBFJl8slxxXX3CeJMM4jyb4rcicU5ovPzkI0le uRidL+xJN4ovWlR+8Jm+dwvZ0s2c5lNwpTwpRnspn6GF4UEil1+TzLequDyVxgHc jE1L7vXX0jyPcFSWLEs7lpmVbxrr/w2T2sxLBRJG9/C22qjqpdJccC/5EfHWHBPI mc17Cin+7g2l+wsX+yzph+uxwS/s82glyDls872iMBnw0MtW5NieuhFOCP2LJBTD 5D62bC3qvP7k0Ma+APlcRutfC27tzVr79i3QnAkMoqHiFyUd3oz3c8HVlbOXIjn7 jehTB+x+flhEN0WKwAHuZtMrIYL3fw== =CHjj -END PGP SIGNATURE-
Re: Regression in 4.17 Kernels (?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2018-08-23 at 23:46 -0700, jose R Rodriguez wrote: > FYI I also experienced one sudden reboot yesterday with Linux kernel > built 'the Debian way' from debian source 4.17.17-1. Only difference is > my kernels are reiser4 -patched and modified to be built with GCC6 for > stretch-backports. Hi Jose, I'm sorry but I don't think we can do anything with that, especially without any log from the reboot. It's different enough from our kernels that it's basically unsupported. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlt/r8MACgkQ3rYcyPpX RFsYnwgAu4qtjiDjZNqPmd5WGi7wuDQX86OeqVtWEK8jSq2CLfqHkc8/PErlj68b N6WAarVgs7Xrow9nIKGWqoSSwp3pbuRaKeOIEDZ6reVru+NyfQnI57BbXozeNkeH nojxlcRWP0MGgU0dHJ4/FkXkdVE4FObPCexlxPTn8t2Bn9XSfW/4XsliOoG0peTD is3GYpJsIDWxrlp0SrNtgJIg7aXi6rPnWKs6KMqZnM9dgwYBgkeG/tRk9GM4xRGJ POMC2eAORGrht0c4xB33fB/RkC2aVebwsjIFd7gqO4jMPjv+nB4IqKpeOmz+SHYY lB33+RlmcfQHkxYBqFM5WUrUOHOcrw== =tWh7 -END PGP SIGNATURE-
Re: Regression in 4.17 Kernels (?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2018-08-23 at 13:17 +0200, Rainer Dorsch wrote: > Yes, I have never seen that with 4.16 and any kernel I used before. I run not > 4.16. Sorry I'm a bit unsure how to read the last sentence. Can you retry right now with 4.16 kernel (and changing only that) and report back? It's possible that there is a regression in the USB handling in the 4.17 kernel but we'd need a bit more information to confirm that. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlt+oDwACgkQ3rYcyPpX RFvuLAf/f8qVwnDNzB4z0B3/Q93Uc7JQlJsLqAcstdWLgxYgoiO0+m4LuwHscfde bWLF+MxSfU3+LsgzbzfPPHohUfxdQ4VYa5bD0BUzgowBBuKy0IvFytIwN8b0lH4r 3FCRenR8MK9f+ic0UvPTIS/T9Rg24xrbL6A96RIYKfiByuicKzG0rPW5SbVTgXnL QxzRcxNw3+uhus0S8SGtiT7G+rYi+27agCcrC0EYPyZP6HSrYV1YybPn7W5FmToB OQJLEij3OmSO44Qraohga6P5IsOD6/I+bkmkmkT6sSv8qT+1t60unx281K5KA9d9 MIUIwl1i47gSvCBxdpgBIf3gO5Y/DA== =I5LU -END PGP SIGNATURE-
Re: Regression in 4.17 Kernels (?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2018-08-22 at 18:57 +0200, Rainer Dorsch wrote: > The issue seems to be 100% reproducible with the 4.17 kernels I tried on my > system: Hi, is it OK with other kernels? Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlt+hP0ACgkQ3rYcyPpX RFuFzggAy+U/KGJJf3Tv+aFcrYkYpq5UsEaI7hjHzsnpfgqwwpM51ErIqi8HeTO6 M652r0Ha9tsbvsyIq7Wa7Fu7Z9VjZ23mM+SKiLDve3jiM8nIYmjX9JFyjcFq0Smb g8baM7qs3MmodFMH/RqlXFxp3HqPIKph4NnaYBFjbvKop3PfKzRItzpqFtGW3jJn zXRJwbBEgNASwJhuwY78dsBsBx4/m+MFGRb6ME+8Ol+lKayAx7F7L24xmFm5vLg6 8f3oebZ+JHQhJvFn8MrBOfnBlxOCmM9O8dbu0g+TvRKc3B1rN5trKzzpY59pLkPA LY3+YEll2W6BM4uZm+2Uo7NzVUwvTQ== =YnA3 -END PGP SIGNATURE-
Re: Scheduling 9.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2018-06-05 at 15:44 +0200, Cyril Brulebois wrote: > > Context: https://salsa.debian.org/kernel-team/linux/merge_requests/30 > > Many thanks for the heads-up. I'll be on the lookout for a possible > late ABI bump then. Feel free to poke me when that gets accepted into > p-u so that I can adjust our git branch and perform a few build and > runtime tests. This is now up to 4.9.106 and there will definitely be an ABI break. I missed the thread start (I'm not subscribed to -release anymore), but in the quoted text I can see there were three proposed dates for the 9.5 point release. May 26th and June 2nd are out of the equation now but is June 9th already targeted? If so, we really need to move forward on this (and it might be a bit late already) if we want to make sure it builds everywhere. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlsWuPEACgkQ3rYcyPpX RFs/qgf/QnAItR/yQtgU9bl7ab4YGSaKgeW98dVeray761S6G0hQVJRF4UvqsUk4 /ZWj2jsZbMFviGD0WbKHncsRzaY0rj9aRk19LPpSpyDLbkFvDaPYmVvHJ7f+3kbJ IAdN/5O2kq61qoUBdR/LqlSkugzl0Hn8U+ETKzWzkLnNcLYl/A9k2vEBDs+WkSeV /XQFyKYr21hfYxEA7ZZUT4DvcDVbFbEqdcIkADoH96TiMg1gwKYOHh+l2u1Cc9TC XY6DS1hpZi9Iakl2hf+VQmNuW4QM9V0D711L8b17mI+4loH4fDW7bmdgKnm+tTYD 52T9NAd/v5Ym0IU5iOJyEoAtKtDuqQ== =JxL5 -END PGP SIGNATURE-
Re: Fixing Linux getrandom() in stable
On Wed, 2018-05-09 at 23:46 +0100, Ben Hutchings wrote: > It is unlikely that any further fix will be forthcoming on the kernel > side, so I believe that we need to do one of: > > 1. Add entropy to the kernel during boot; either: >a. Improve systemd-random-seed >b. Recommend use of haveged There's also something which might be worth trying in coordination with upstream: credit entropy for platform RNG like RDRAND/RDSEED. It obviously won't fix the problem everywhere, but at least on “recent” Intel platforms there should be an entropy source available without any further initialization (unlike the TPM for example). I know about the trust issues wrt. Intel, but maybe that should be revisited? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#897572: urandom hang in early boot
On Tue, 2018-05-08 at 13:23 +0200, Bjørn Mork wrote: > And sd_id128_randomize() is called from all over the place. I haven't > bothered looking at all the call sites, but would be surprised if not at > least one of them is unconditionally called at boot. > > If I am correct, then I guess this is a systemd bug? It might be (I took the liberty to add your findings to https://github.com/sys temd/systemd/issues/4167). In our case, as far as I can tell since we're still in the initramfs, systemd is not yet PID1, but we do use udev which might have the same issue. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)
On Mon, 2018-03-12 at 00:02 +1300, Menno Finlay-Smits wrote: > Bingo. The problem doesn't seem to happen using linux-image-4.14.0-3- > marvell_4.14.17-1 from sid. I've now successfully transferred 1.5TB from an > external USB drive onto the internal hard disk. Previously the problem would > show up within the first few 100MB of the transfer. > > Do you want me to help figure out which change to the kernel fixed the > problem? As far as I can tell and if I'm not mistaken, the fix is already identified and is included in 4.9.86. I've started working on it for Stretch, and at one point it will be uploaded to -proposed-updates for inclusion in the next point release (9.5). When it's done I'll probably ask you to try a test kernel to make sure it's really fixed. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)
On Fri, Mar 09, 2018 at 10:53:07PM +1300, Menno Finlay-Smits wrote: > Can do. Should I just use the kernel packages from sid or update the whole > system to sid? I think you should be able to just pick the kernel from sid. I'm starting to work on updating 4.9 to later kernels but it's not really a priority right now since we'll just have a point release this week-end. Regards, -- Yves-Alexis Perez signature.asc Description: PGP signature
Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)
On Mon, 2018-03-05 at 15:28 +0100, Andrew Lunn wrote: > Would it be possible to try to reproduce this problem with 4.9.86 on > the hardware reporting the issue? 4.9.82-1+deb9u3 is currently in the archive. Menno, could you give it a shot? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Accepted linux-latest 80+deb9u4 (all source) into proposed-updates->stable-new, proposed-updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 22 Feb 2018 08:32:44 +0100 Source: linux-latest Binary: linux-source linux-doc linux-perf linux-image-alpha-generic linux-headers-alpha-generic linux-image-alpha-generic-dbg linux-image-alpha-smp linux-headers-alpha-smp linux-image-alpha-smp-dbg linux-image-amd64 linux-headers-amd64 linux-image-amd64-dbg linux-image-rt-amd64 linux-headers-rt-amd64 linux-image-rt-amd64-dbg linux-image-arm64 linux-headers-arm64 linux-image-arm64-dbg linux-image-marvell linux-headers-marvell linux-image-marvell-dbg linux-image-armmp linux-headers-armmp linux-image-armmp-dbg linux-image-armmp-lpae linux-headers-armmp-lpae linux-image-armmp-lpae-dbg linux-image-parisc linux-headers-parisc linux-image-parisc-dbg linux-image-parisc64-smp linux-headers-parisc64-smp linux-image-parisc64-smp-dbg linux-image-686 linux-headers-686 linux-image-686-dbg linux-image-686-pae linux-headers-686-pae linux-image-686-pae-dbg linux-image-rt-686-pae linux-headers-rt-686-pae linux-image-rt-686-pae-dbg linux-image-m68k linux-headers-m68k linux-image-m68k-dbg linux-image-4kc-malta linux-headers-4kc-malta linux-image-4kc-malta-dbg linux-image-5kc-malta linux-headers-5kc-malta linux-image-5kc-malta-dbg linux-image-octeon linux-headers-octeon linux-image-octeon-dbg linux-image-loongson-3 linux-headers-loongson-3 linux-image-loongson-3-dbg linux-image-powerpc linux-headers-powerpc linux-image-powerpc-dbg linux-image-powerpc-smp linux-headers-powerpc-smp linux-image-powerpc-smp-dbg linux-image-powerpc64 linux-headers-powerpc64 linux-image-powerpc64-dbg linux-image-powerpcspe linux-headers-powerpcspe linux-image-powerpcspe-dbg linux-image-powerpc64le linux-headers-powerpc64le linux-image-powerpc64le-dbg linux-image-s390x linux-headers-s390x linux-image-s390x-dbg linux-image-sh7751r linux-headers-sh7751r linux-image-sh7751r-dbg linux-image-sh7785lcr linux-headers-sh7785lcr linux-image-sh7785lcr-dbg linux-image-sparc64 linux-headers-sparc64 linux-image-sparc64-dbg linux-image-sparc64-smp linux-headers-sparc64-smp linux-image-sparc64-smp-dbg linux-tools linux-image-586 linux-headers-586 linux-image-kirkwood linux-headers-kirkwood linux-image-orion5x linux-headers-orion5x xen-linux-system-amd64 Architecture: all source Version: 80+deb9u4 Distribution: stretch-security Urgency: high Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org> Changed-By: Yves-Alexis Perez <cor...@debian.org> Description: linux-doc - Linux kernel specific documentation (meta-package) linux-headers-4kc-malta - Header files for Linux 4kc-malta configuration (meta-package) linux-headers-586 - Header files for Linux 586 configuration (dummy package) linux-headers-5kc-malta - Header files for Linux 5kc-malta configuration (meta-package) linux-headers-686 - Header files for Linux 686 configuration (meta-package) linux-headers-686-pae - Header files for Linux 686-pae configuration (meta-package) linux-headers-alpha-generic - Header files for Linux alpha-generic configuration (meta-package) linux-headers-alpha-smp - Header files for Linux alpha-smp configuration (meta-package) linux-headers-amd64 - Header files for Linux amd64 configuration (meta-package) linux-headers-arm64 - Header files for Linux arm64 configuration (meta-package) linux-headers-armmp - Header files for Linux armmp configuration (meta-package) linux-headers-armmp-lpae - Header files for Linux armmp-lpae configuration (meta-package) linux-headers-kirkwood - Header files for Linux kirkwood configuration (dummy package) linux-headers-loongson-3 - Header files for Linux loongson-3 configuration (meta-package) linux-headers-m68k - Header files for Linux m68k configuration (meta-package) linux-headers-marvell - Header files for Linux marvell configuration (meta-package) linux-headers-octeon - Header files for Linux octeon configuration (meta-package) linux-headers-orion5x - Header files for Linux orion5x configuration (dummy package) linux-headers-parisc64-smp - Header files for Linux parisc64-smp configuration (meta-package) linux-headers-parisc - Header files for Linux parisc configuration (meta-package) linux-headers-powerpc64 - Header files for Linux powerpc64 configuration (meta-package) linux-headers-powerpc64le - Header files for Linux powerpc64le configuration (meta-package) linux-headers-powerpc - Header files for Linux powerpc configuration (meta-package) linux-headers-powerpc-smp - Header files for Linux powerpc-smp configuration (meta-package) linux-headers-powerpcspe - Header files for Linux powerpcspe configuration (meta-package) linux-headers-rt-686-pae - Header files for Linux rt-686-pae configuration (meta-package) linux-headers-rt-amd64 - Header files for Linux rt-amd64 configuration (meta-package) linux-headers-s390x - Header files for Linux s390x configuration (meta-package) linux-headers-sh7751r - Header files for Linux sh7751r c
Accepted linux 4.9.82-1+deb9u2 (all source) into proposed-updates->stable-new, proposed-updates
-sh7751r linux-image-4.9.0-6-sh7751r-dbg linux-image-4.9.0-6-sh7785lcr linux-headers-4.9.0-6-sh7785lcr linux-image-4.9.0-6-sh7785lcr-dbg linux-headers-4.9.0-6-all-sparc64 kernel-image-4.9.0-6-sparc64-di nic-modules-4.9.0-6-sparc64-di ppp-modules-4.9.0-6-sparc64-di pata-modules-4.9.0-6-sparc64-di cdrom-core-modules-4.9.0-6-sparc64-di scsi-core-modules-4.9.0-6-sparc64-di scsi-modules-4.9.0-6-sparc64-di btrfs-modules-4.9.0-6-sparc64-di ext4-modules-4.9.0-6-sparc64-di isofs-modules-4.9.0-6-sparc64-di jfs-modules-4.9.0-6-sparc64-di ufs-modules-4.9.0-6-sparc64-di xfs-modules-4.9.0-6-sparc64-di fat-modules-4.9.0-6-sparc64-di md-modules-4.9.0-6-sparc64-di multipath-modules-4.9.0-6-sparc64-di usb-modules-4.9.0-6-sparc64-di usb-storage-modules-4.9.0-6-sparc64-di input-modules-4.9.0-6-sparc64-di sata-modules-4.9.0-6-sparc64-di crc-modules-4.9.0-6-sparc64-di crypto-modules-4.9.0-6-sparc64-di crypto-dm-modules-4.9.0-6-sparc64-di ata-modules-4.9.0-6-sparc64-di nbd-modules-4.9.0-6-sparc64-di squashfs-modules-4.9.0-6-sparc64-di virtio-modules-4.9.0-6-sparc64-di zlib-modules-4.9.0-6-sparc64-di udf-modules-4.9.0-6-sparc64-di fuse-modules-4.9.0-6-sparc64-di linux-image-4.9.0-6-sparc64 linux-headers-4.9.0-6-sparc64 linux-image-4.9.0-6-sparc64-dbg linux-image-4.9.0-6-sparc64-smp linux-headers-4.9.0-6-sparc64-smp linux-image-4.9.0-6-sparc64-smp-dbg linux-compiler-gcc-6-arm linux-compiler-gcc-6-s390 linux-compiler-gcc-6-x86 Architecture: all source Version: 4.9.82-1+deb9u2 Distribution: stretch-security Urgency: high Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org> Changed-By: Yves-Alexis Perez <cor...@debian.org> Description: acpi-modules-4.9.0-6-686-di - ACPI support modules (udeb) acpi-modules-4.9.0-6-686-pae-di - ACPI support modules (udeb) acpi-modules-4.9.0-6-amd64-di - ACPI support modules (udeb) affs-modules-4.9.0-6-4kc-malta-di - Amiga filesystem support (udeb) affs-modules-4.9.0-6-5kc-malta-di - Amiga filesystem support (udeb) affs-modules-4.9.0-6-loongson-3-di - Amiga filesystem support (udeb) affs-modules-4.9.0-6-octeon-di - Amiga filesystem support (udeb) affs-modules-4.9.0-6-powerpc64-di - Amiga filesystem support (udeb) affs-modules-4.9.0-6-powerpc-di - Amiga filesystem support (udeb) ata-modules-4.9.0-6-4kc-malta-di - ATA disk modules (udeb) ata-modules-4.9.0-6-5kc-malta-di - ATA disk modules (udeb) ata-modules-4.9.0-6-686-di - ATA disk modules (udeb) ata-modules-4.9.0-6-686-pae-di - ATA disk modules (udeb) ata-modules-4.9.0-6-alpha-generic-di - ATA disk modules (udeb) ata-modules-4.9.0-6-amd64-di - ATA disk modules (udeb) ata-modules-4.9.0-6-arm64-di - ATA disk modules (udeb) ata-modules-4.9.0-6-armmp-di - ATA disk modules (udeb) ata-modules-4.9.0-6-loongson-3-di - ATA disk modules (udeb) ata-modules-4.9.0-6-parisc64-smp-di - ATA disk modules (udeb) ata-modules-4.9.0-6-parisc-di - ATA disk modules (udeb) ata-modules-4.9.0-6-powerpc64-di - ATA disk modules (udeb) ata-modules-4.9.0-6-powerpc64le-di - ATA disk modules (udeb) ata-modules-4.9.0-6-powerpc-di - ATA disk modules (udeb) ata-modules-4.9.0-6-sparc64-di - ATA disk modules (udeb) btrfs-modules-4.9.0-6-4kc-malta-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-5kc-malta-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-686-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-686-pae-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-alpha-generic-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-amd64-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-arm64-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-armmp-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-loongson-3-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-m68k-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-marvell-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-octeon-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-parisc64-smp-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-parisc-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-powerpc64-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-powerpc64le-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-powerpc-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-s390x-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-sh7751r-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-sh7785lcr-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-6-sparc64-di - BTRFS filesystem support (udeb) cdrom-core-modules-4.9.0-6-4kc-malta-di - CDROM support (udeb) cdrom-core-modules-4.9.0-6-5kc-malta-di - CDROM support (udeb) cdrom-core-modules-4.9.0-6-686-di - CDROM support (udeb) cdrom-core-modules-4.9.0-6-686-pae-di - CDROM support (udeb) cdrom-core-modules-4.9.0-6-alpha-generic-di - CDROM support (udeb) cdrom-core-modules-4.9.0-6-amd64-di - CDROM support (udeb) cdrom-core-modules-4.9.
Re: Migrating to Salsa
On Fri, 2018-02-23 at 01:13 +0100, Ben Hutchings wrote: > We need to move everything from Alioth to Salsa some time before the > end of May. > > There is already a "kernel-team" group on Salsa, and the members of the > "kernel" group on Alioth have been added to this group. > > Since all our live version control repositories use git, it should be a > simple and quick process to replicate them on Salsa. I think what we > need to do is: > > 1. Agree the date and time to start migration. > 2. At that time, add hooks on Alioth to disable further writes. > 3. Start migration. > 4. Update all references to Alioth: >- Configure anonscm.debian.org to forward to Salsa >- Update package Vcs fields >- Update kernel-handbook text Looks good to me. > > I don't think we use many other features of Alioth. The features I > know about are: > > * kernel-svn-changes mailing list and hook. I think this will be > redundant. Any Salsa user can "watch" a repository or group to > receive email notifications about commits. As Bastian said, notifications for pushes don't work. For the stuff I migrated myself I added email integration to the previous lists, which should work for a time until proper notification are supported. > * IRC notification hook (KGB client). Salsa has an "integration" for > the Irker notification service. This needs to be enabled and > configured with the server and channel details for each repository. > I don't know whether anything needs to be done on the Irker server > side. Yes, it works just fine. By the way there's a bunch of salsa scripts at https: //salsa.debian.org/mehdi/salsa-scripts which are helpful to setup a salsa project. > > Have I missed anything? > > I propose that we start the migration after the point release is done, > so on Sunday 11th March, starting at 16:00 UTC. It's fine by me. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Patch for Backport of the Linux MegaRAID driver for SAS based RAID controllers for Debian Stretch
control: tag -1 -patch On Thu, 2018-02-22 at 09:20 +0100, Geert Stappers wrote: > Bugreport tagged with 'patch', hope this helps. Hi, There is no patch in that bug report. While copying the whole directory might be doable, it's not the first solution we would consider, and it would definitely need a lot more testing. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: [stretch] ABI bump for 4.9 with retpoline support?
On Sat, 2018-02-17 at 19:51 +, Ben Hutchings wrote: > I think we should bump ABI again. Thanks for the feedback. I'll do that and remove all the ABI reverts and ignores. > We should also do the equivalent of > these changes in sid, with s/gcc-7/gcc-6/. > > * [x86] Add versioned build-dependency on gcc-7 for retpoline support > * [x86] linux-compiler-gcc-7-x86: Add versioned dependency on gcc-7 for > retpoline support > * [x86] linux-headers: Depend on updated linux-compiler-gcc-7-x86 I did the linux-compiler-gcc-6-x86 one but not the other two, Will do as well. Should we upload this one through security-master (for the CVE-2017-5715 fix) or through stretch-pu again? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: [stretch] ABI bump for 4.9 with retpoline support?
On Fri, 2018-02-16 at 11:54 +0100, Yves-Alexis Perez wrote: > > There's a bunch of ABI breaks in 4.9.81 again, and we ignored/reverted a lot > of them since 4.9.65+kaiser, so maybe it'll be a good idea at one point, but I > don't have a strong opinion on this right now. I've pushed my work to the stretch branch. It builds fine on x86 and powerpc after some fixes. When built with gcc-6 just uploaded to security-master, retpoline is enabled: /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline Depending on the opinion, we can either revert the various ABI fixes and bump the ABI, or try an upload as-is. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
[stretch] ABI bump for 4.9 with retpoline support?
Hi kernel team I am currently working on 4.9.81 (and will work on 4.9.82 when it's out) for stretch-pu. Fixes for Spectre started appearing in recent versions (especially retpoline) and Moritz has worked a lot on gcc with retpoline support, so it looks that we'll be able to ship a kernel with retpoline enabled and functional in stretch-pu before the next point release. It doesn't seem that building with a retpoline-aware gcc will bump the ABI by itself, but do we still want to do it? There's a bunch of ABI breaks in 4.9.81 again, and we ignored/reverted a lot of them since 4.9.65+kaiser, so maybe it'll be a good idea at one point, but I don't have a strong opinion on this right now. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#885570: After upgrade I can continue to reproduce this
On Sun, 2018-02-11 at 13:33 -0600, Andrew Latham wrote: > Related info in dmesg > [0.00] Linux version 4.9.0-5-amd64 (debian-kernel@lists.debian.org) > (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65- > 3+deb9u2 (2018-01-04) > [ 273.787162] [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO > underrun This is not the fixed version. You want to upgrade to 4.9.80-1 (or -2) which is currently sitting in stable-proposed-updates and will be available in the next point release. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Accepted linux 4.9.80-2 (source) into proposed-updates->stable-new, proposed-updates
-sh7751r linux-image-4.9.0-5-sh7751r-dbg linux-image-4.9.0-5-sh7785lcr linux-headers-4.9.0-5-sh7785lcr linux-image-4.9.0-5-sh7785lcr-dbg linux-headers-4.9.0-5-all-sparc64 kernel-image-4.9.0-5-sparc64-di nic-modules-4.9.0-5-sparc64-di ppp-modules-4.9.0-5-sparc64-di pata-modules-4.9.0-5-sparc64-di cdrom-core-modules-4.9.0-5-sparc64-di scsi-core-modules-4.9.0-5-sparc64-di scsi-modules-4.9.0-5-sparc64-di btrfs-modules-4.9.0-5-sparc64-di ext4-modules-4.9.0-5-sparc64-di isofs-modules-4.9.0-5-sparc64-di jfs-modules-4.9.0-5-sparc64-di ufs-modules-4.9.0-5-sparc64-di xfs-modules-4.9.0-5-sparc64-di fat-modules-4.9.0-5-sparc64-di md-modules-4.9.0-5-sparc64-di multipath-modules-4.9.0-5-sparc64-di usb-modules-4.9.0-5-sparc64-di usb-storage-modules-4.9.0-5-sparc64-di input-modules-4.9.0-5-sparc64-di sata-modules-4.9.0-5-sparc64-di crc-modules-4.9.0-5-sparc64-di crypto-modules-4.9.0-5-sparc64-di crypto-dm-modules-4.9.0-5-sparc64-di ata-modules-4.9.0-5-sparc64-di nbd-modules-4.9.0-5-sparc64-di squashfs-modules-4.9.0-5-sparc64-di virtio-modules-4.9.0-5-sparc64-di zlib-modules-4.9.0-5-sparc64-di udf-modules-4.9.0-5-sparc64-di fuse-modules-4.9.0-5-sparc64-di linux-image-4.9.0-5-sparc64 linux-headers-4.9.0-5-sparc64 linux-image-4.9.0-5-sparc64-dbg linux-image-4.9.0-5-sparc64-smp linux-headers-4.9.0-5-sparc64-smp linux-image-4.9.0-5-sparc64-smp-dbg linux-compiler-gcc-6-arm linux-compiler-gcc-6-s390 linux-compiler-gcc-6-x86 Architecture: source Version: 4.9.80-2 Distribution: stretch Urgency: medium Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org> Changed-By: Yves-Alexis Perez <cor...@debian.org> Description: acpi-modules-4.9.0-5-686-di - ACPI support modules (udeb) acpi-modules-4.9.0-5-686-pae-di - ACPI support modules (udeb) acpi-modules-4.9.0-5-amd64-di - ACPI support modules (udeb) affs-modules-4.9.0-5-4kc-malta-di - Amiga filesystem support (udeb) affs-modules-4.9.0-5-5kc-malta-di - Amiga filesystem support (udeb) affs-modules-4.9.0-5-loongson-3-di - Amiga filesystem support (udeb) affs-modules-4.9.0-5-octeon-di - Amiga filesystem support (udeb) affs-modules-4.9.0-5-powerpc-di - Amiga filesystem support (udeb) affs-modules-4.9.0-5-powerpc64-di - Amiga filesystem support (udeb) ata-modules-4.9.0-5-4kc-malta-di - ATA disk modules (udeb) ata-modules-4.9.0-5-5kc-malta-di - ATA disk modules (udeb) ata-modules-4.9.0-5-686-di - ATA disk modules (udeb) ata-modules-4.9.0-5-686-pae-di - ATA disk modules (udeb) ata-modules-4.9.0-5-alpha-generic-di - ATA disk modules (udeb) ata-modules-4.9.0-5-amd64-di - ATA disk modules (udeb) ata-modules-4.9.0-5-arm64-di - ATA disk modules (udeb) ata-modules-4.9.0-5-armmp-di - ATA disk modules (udeb) ata-modules-4.9.0-5-loongson-3-di - ATA disk modules (udeb) ata-modules-4.9.0-5-parisc-di - ATA disk modules (udeb) ata-modules-4.9.0-5-parisc64-smp-di - ATA disk modules (udeb) ata-modules-4.9.0-5-powerpc-di - ATA disk modules (udeb) ata-modules-4.9.0-5-powerpc64-di - ATA disk modules (udeb) ata-modules-4.9.0-5-powerpc64le-di - ATA disk modules (udeb) ata-modules-4.9.0-5-sparc64-di - ATA disk modules (udeb) btrfs-modules-4.9.0-5-4kc-malta-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-5kc-malta-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-686-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-686-pae-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-alpha-generic-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-amd64-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-arm64-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-armmp-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-loongson-3-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-m68k-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-marvell-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-octeon-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-parisc-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-parisc64-smp-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-powerpc-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-powerpc64-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-powerpc64le-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-s390x-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-sh7751r-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-sh7785lcr-di - BTRFS filesystem support (udeb) btrfs-modules-4.9.0-5-sparc64-di - BTRFS filesystem support (udeb) cdrom-core-modules-4.9.0-5-4kc-malta-di - CDROM support (udeb) cdrom-core-modules-4.9.0-5-5kc-malta-di - CDROM support (udeb) cdrom-core-modules-4.9.0-5-686-di - CDROM support (udeb) cdrom-core-modules-4.9.0-5-686-pae-di - CDROM support (udeb) cdrom-core-modules-4.9.0-5-alpha-generic-di - CDROM support (udeb) cdrom-core-modules-4.9.0-5-amd64-di - CDROM support (udeb) cdrom-core-modules-4.9.0-5-arm64-di - CDROM s
Re: Re: Bug#888263: Spectre : release kernel 4.9.77 to stretch before p-u
On Fri, 2018-02-09 at 14:00 +0100, Julien Aubin wrote: > I guess the kernel will be rebuilt due to the ARM64 breakage Yes, I'll push a -2 with ABI change ignored on arm64. > > but I confirm it works fine on the following machines : > Intel Core i7 4790 w/ GeForce GTX 1070 and NVidia BLOB 384.111 > Intel Core i7 4800 MQ > Intel Pentium N3700 > AMD Phenom x4 9840 w/ GeForce GTX 970 and NVidia BLOB 384.111 Thanks for the report. > > However it seems that the updated kernel does not fix against variant 1 and > 2 of Spectre. :'( Yes indeed. Retpoline is included in the kernel but there is not gcc support yet. And IBRS/IBPB is not there yet, nor the microcodes updates. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Regression for ip6-in-ip4 IPsec tunnel in 4.14.16
On Wed, 2018-02-07 at 20:46 +0100, Yves-Alexis Perez wrote: > Maybe. I tried with removing the MTU setting, and I get (on ping again) > > févr. 07 20:44:01 scapa kernel: mtu: 1266 > > which means I would get -EINVAL on standards kernels, which is not really good > either. Actually after rebooting on the Debian 4.14.17 kernel, with the outter MTU unset (or set to 1360), I don't get the -EINVAL anymore, so maybe it'd be OK. Unfortunately I have the feeling that debugging this will be a bit tricky for other people. MTU tuning for tunnels are always a bit confusing, but having the kernel return EINVAL on a ping doesn't really help narrowing it down to that MTU setting. Not sure if some kind of logging could be added to help? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Regression for ip6-in-ip4 IPsec tunnel in 4.14.16
On Wed, 2018-02-07 at 13:50 -0500, Mike Maloney wrote: > On Wed, Feb 7, 2018 at 12:23 PM, Yves-Alexis Perez <cor...@debian.org> > > Hi Yves-Alexis - > > I apologize for the problem. It seems to me that tunneling with an > outer MTU that causes the inner MTU to be smaller than the min, is > potentially problematic in other ways as well. Maybe. I tried with removing the MTU setting, and I get (on ping again) févr. 07 20:44:01 scapa kernel: mtu: 1266 which means I would get -EINVAL on standards kernels, which is not really good either. > But also it could seem unfortunate that the code with my fix does not > look at actual packet size, but instead only looks at the MTU and then > fails, even if no packet was going to be so large. The intention of > my patch was to prevent a negative number while calculating the > maxfraglen in __ip6_append_data(). An alternative fix maybe to > instead return an error only if the mtu is less than or equal to the > fragheaderlen. Something like: > > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c > index 3763dc01e374..5d912a289b95 100644 > --- a/net/ipv6/ip6_output.c > +++ b/net/ipv6/ip6_output.c > @@ -1214,8 +1214,6 @@ static int ip6_setup_cork(struct sock *sk, > struct inet_cork_full *cork, > if (np->frag_size) > mtu = np->frag_size; > } > - if (mtu < IPV6_MIN_MTU) > - return -EINVAL; > cork->base.fragsize = mtu; > if (dst_allfrag(rt->dst.path)) > cork->base.flags |= IPCORK_ALLFRAG; > @@ -1264,6 +1262,8 @@ static int __ip6_append_data(struct sock *sk, > > fragheaderlen = sizeof(struct ipv6hdr) + rt->rt6i_nfheader_len + > (opt ? opt->opt_nflen : 0); > + if (mtu < fragheaderlen + 8) > + return -EINVAL; > maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen - > sizeof(struct frag_hdr); > (opt ? opt->opt_nflen : 0); > > But then we also have to convince ourselves that maxfraglen can never > be <= 0. I'd have to think about that. > > I am not sure if others have thoughts on supporting MTUs configured > below the min in the spec. > Here, the MTU is not below, so I'm not sure what happens. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Regression for ip6-in-ip4 IPsec tunnel in 4.14.16
On Wed, 2018-02-07 at 18:05 +0100, Yves-Alexis Perez wrote: > I'll try to printk the mtu before returning EINVAL to see why it's lower than > 1280, but maybe the IP encapsulation is not correctly handled? I did: diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 3763dc01e374..d3c651158d35 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1215,7 +1215,7 @@ static int ip6_setup_cork(struct sock *sk, struct inet_cork_full *cork, mtu = np->frag_size; } if (mtu < IPV6_MIN_MTU) - return -EINVAL; + printk("mtu: %d\n", mtu); cork->base.fragsize = mtu; if (dst_allfrag(rt->dst.path)) cork->base.flags |= IPCORK_ALLFRAG; and I get: févr. 07 18:19:50 scapa kernel: mtu: 1218 and it doesn't depend on the original packet size (same thing happens with ping -s 100). It also happens with UDP (DNS) traffic, but apparently not with TCP. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Regression for ip6-in-ip4 IPsec tunnel in 4.14.16
On Wed, 2018-02-07 at 17:38 +0100, Yves-Alexis Perez wrote: > Starting with 4.14.16, IPv6 traffic is broken. When trying a simple ping > to an IPv6 address I get: > > ping: sendmsg: Invalid argument I forgot an important bit of information: due to the way routers usually broke path MTU discovery by filtering ICMP, I'm lowering the MTU to 1280 (so exactly IPV6_MIN_MTU) when using IPsec. The MTU is configured by the IKE daemon (strongSwan, thus adding Tobias to CC:) in routing table 220: default via 192.168.28.254 dev eth0 proto static src 192.168.0.129 mtu 1280 advmss 1320 I'll try to printk the mtu before returning EINVAL to see why it's lower than 1280, but maybe the IP encapsulation is not correctly handled? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Regression for ip6-in-ip4 IPsec tunnel in 4.14.16
Hi Mike, I noticed a regression in 4.14.16 stable kernel (I assume it's also present in mainline). I'm using an IPsec setup where I tunnel all my IP trafic to a gateway. The tunnel can use either IPv6 or IPv4 (depending on what's available locally) and will route both IPv4 and IPv6 (my gateway will assign both family addresses). The tunnel doesn't use ESP directly but rather encapsulates in UDP. Starting with 4.14.16, IPv6 traffic is broken. When trying a simple ping to an IPv6 address I get: ping: sendmsg: Invalid argument I bisected 4.14.15 to 4.14.16 and got the attached bisect log, which ends with 8278804e05f6bcfe3fdfea4a404020752ead15a6 as the offending commit. The -EINVAL is consistent with the “Invalid argument” return from ping. I didn't try yet on a pure IPv6 setup (without IPsec tunneling) but will followup when I have a chance to test it. Reverting that commit on top of 4.14.17 fixes the problem. If you need more info, please ask. Regards, -- Yves-Alexis# bad: [6c70076667f246dc200c7a3e9aeabd2f8f388416] Linux 4.14.16 # good: [a16134b082346b7e7c34f594a0763eafacdcea92] Linux 4.14.15 git bisect start 'v4.14.16' 'v4.14.15' # bad: [72d4f3abd6d3521f5cd978b63f9301051f127812] r8169: fix memory corruption on retrieval of hardware statistics. git bisect bad 72d4f3abd6d3521f5cd978b63f9301051f127812 # good: [295bcfbbcf5a741e9103605c3252276ed21433bb] ARM: net: bpf: correct stack layout documentation git bisect good 295bcfbbcf5a741e9103605c3252276ed21433bb # bad: [8278804e05f6bcfe3fdfea4a404020752ead15a6] ipv6: fix udpv6 sendmsg crash caused by too small MTU git bisect bad 8278804e05f6bcfe3fdfea4a404020752ead15a6 # good: [9ad970c8a13595e38d3af98114bcbbec6d8a5be4] drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state() git bisect good 9ad970c8a13595e38d3af98114bcbbec6d8a5be4 # good: [42d68bf2a42381642ea5ae460c6a5d86a56213f0] ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY git bisect good 42d68bf2a42381642ea5ae460c6a5d86a56213f0 # good: [2295b3dd543f9a5a1834e4265d506a5bc0819983] ipv6: Fix getsockopt() for sockets with default IPV6_AUTOFLOWLABEL git bisect good 2295b3dd543f9a5a1834e4265d506a5bc0819983 # first bad commit: [8278804e05f6bcfe3fdfea4a404020752ead15a6] ipv6: fix udpv6 sendmsg crash caused by too small MTU signature.asc Description: This is a digitally signed message part
Re: Bug#888263: Spectre : release kernel 4.9.77 to stretch before p-u
On Sun, 2018-01-28 at 20:34 +0100, Yves-Alexis Perez wrote: > > No, that's not necessary. But could you wait a day or two so I have a > > chance to review your work? > > Sure, I'd welcome a review on this actually :) Hi Ben, 4.9.80-1 is ready for me. I'm not totally sure how to interpret: 2018/02/02 - [12:40:22] (bwh): Corsac: Sorry, no, why don't you go ahead anyway Is it go for upload, even without review? If so, I'll do the 4.9.80 upload tonight and watch the list for any bug from stretch-pu. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#878221: linux-image-4.9.0-4-amd64: Screen flickers randomly with Radeon R9 270X since upgrade from 4.9.0-3 to 4.9.0-4
On Wed, 2017-10-11 at 11:05 +0200, Benjamin Sygnat wrote: > - The screen (Dell U2415, resolution 1920x1200) which is connected to my AMD > Radeon R9 270X (on DisplayPort-0) occasionally flickers every few seconds. The > flickering appears to be random. It seems that a lot of people experienced a similar experience with an Intel card using i915. For all those people, please see #884001 which should be fixed in stretch-pu soon. Please keep this bug for amd/radeon issue only. Benjamin, does this still happens on current version (4.9.65-3+deb9u2)? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Bug#888263: Spectre : release kernel 4.9.77 to stretch before p-u
On Sun, 2018-01-28 at 18:45 +, Ben Hutchings wrote: > > So you want to include the patch even if it's reverted upstream? > > Oh, I misunderstood what you were saying. No I don't. But I think it > makes sense to trigger a rebuild of modules once the retpoline compiler > support is in place. Agreed. > Do > > I need to ping someone before doing the upload? > > No, that's not necessary. But could you wait a day or two so I have a > chance to review your work? Sure, I'd welcome a review on this actually :) Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Bug#888263: Spectre : release kernel 4.9.77 to stretch before p-u
On Sun, 2018-01-28 at 18:24 +, Ben Hutchings wrote: > > So I went ahead an updated to 4.9.78 and added the revert for the VERMAGIC > > stuff (which is queued for 4.9.79). > > This makes sense. I think once an updated gcc is available in stretch > we should bump the ABI number and Build-Depends at the same time as un- > reverting that. So you want to include the patch even if it's reverted upstream? > > > I'm currently running a full build in pbuilder in a stretch chroot, so it > > should be ready for upload if it's ok for you. > > > > I'm unsure about stable-uploads procedure for the kernel (SRM and debian- > boot > > notifications for example) so pointer to any specific stuff would be > welcome. > > I've tended to upload shortly before point releases, but I think we > should really be uploading earlier and more often so regressions are > more lilely to be caught before a point release. Yes I think it'd be a good idea to let this one stay a bit longer in s-p-u. Do I need to ping someone before doing the upload? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Bug#888263: Spectre : release kernel 4.9.77 to stretch before p-u
On Wed, 2018-01-24 at 13:52 +0100, Yves-Alexis Perez wrote: > > work on 4.9.77 is mostly done, so yes I'd like to push it to stretch before > next point relase. 4.9.78 is just out but I'm unsure if we want to hold it or > not. Hi Ben, So I went ahead an updated to 4.9.78 and added the revert for the VERMAGIC stuff (which is queued for 4.9.79). I'm currently running a full build in pbuilder in a stretch chroot, so it should be ready for upload if it's ok for you. I'm unsure about stable-uploads procedure for the kernel (SRM and debian-boot notifications for example) so pointer to any specific stuff would be welcome. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#888263: Spectre : release kernel 4.9.77 to stretch before p-u
On Wed, 2018-01-24 at 14:03 +0100, Julien Aubin wrote: > I know it... :'( But as you rebuild the kernel image the updated compiler > may come a bit later w/o needing another kernel update ? I'm not really sure we will do a kernel binNMU in stretch-pu, but in any case that's a discussion for when we will actually have a fix. > > Anyway if you want someone to test the updates please push the updated > packages to stretch-p-u and I'll tell you if it works on my four boxes which > are : > - An Intel Core i7 4790 w/ NVidia blob 384.111 > - An AMD Phenom 9850 w/ NVidia blob 384.111 > - An Intel Core i7 4800MQ laptop > - An Intel NUC Atom Apollo Lake You'll be notified when the upload is done and this bug is closed, so you'll be able to test at that point. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#888263: Spectre : release kernel 4.9.77 to stretch before p-u
On Wed, 2018-01-24 at 13:43 +0100, Julien Aubin wrote: > Package: linux-image-4.9.0-5-amd64 > Version: 4.9.65-3+deb9u2 > Severity: serious > Tags: security > Justification: root security hole > > Hi, > > Now that kernel release 4.9.77 has been released and contains the full > retpoline fixes, could you please bring it to stretch before the next p-u ? Hi, work on 4.9.77 is mostly done, so yes I'd like to push it to stretch before next point relase. 4.9.78 is just out but I'm unsure if we want to hold it or not. > > I know this situation is quite exceptionnal, but all the Spectre story is. > I'm not sure backporting only the required changes for retpoline would be > that easy. That beeing said, retpoline support in the kernel is not enough. It also needs gcc fixes, which are not yet available, as far as I can tell. So while we can push an updated kernel to stretch, spectre won't be mitigated. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#882414: [src:linux] Oops: NULL pointer dereference - RIP: isci_task_abort_task+0x30/0x3e0 [isci]
On Thu, 2018-01-04 at 09:53 +0100, Yves-Alexis Perez wrote: > I'm experiencing the same issue on a workstation here (Dell Precision T5600) > with: > > 00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA > AHCI Controller (rev 05) > 05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset > 4-Port > SATA Storage Control Unit (rev 05) > > I've built a 4.15-rc6 kernel with that patch reverted and the system seems to > boot fine. After porting the issue upstream, a patch has been submitted upstream (and CC: stable): https://marc.info/?l=linux-scsi=151557324907914 Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#885570: Duplicate of 884061 ?
control: forcemerge 884061 885570 884116 884001 On Sun, 2017-12-31 at 01:35 +0100, Adrien Plan wrote: > Hi, > > I got the same issue on my i915 notebook (Dell E7450) and I had to boot > on previous kernel (linux-image-4.9.0-3-amd64) > > This bug report seems the same and suggest a tested revert on commit > 7de694782cbe7840f2c0de6f1e70f41fc1b8b6e8 : > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884061 > Thanks, I'm merging the bugs. I'm currently working on 4.9.75 but I'll investigate reverting this or identify a more proper fix when it's done. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#886554: linux-image-4.9.0-5-amd64: OOcannot connect into a wifi network
On Sun, 2018-01-07 at 18:21 +0200, Karagkiaouris Diamantis wrote: > After the latest upgrade i cannot connect to a wifi network. > The dmesg output is: Hi, there is no wifi-related changes in 4.9.65-3+deb9u2, can you revert back to 4.9.65-3+deb9u1 with no other changes and report back if wifi work or no? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#886417: linux-source-4.9: Kernel sources do not compile
On Sat, 2018-01-06 at 00:12 +0100, Salvatore Bonaccorso wrote: > There is indeed > https://git.kernel.org/linus/ce4a4e565f5264909a18c733b864c3f74467f69e > backported as 3e5daacf65173987436bad6ab9039a05f9545cdd in v4.9.74 > which AFAICS did remove the surrounding directives. Thanks for the identification. David and other, we are currently working on 4.9.75 which should fix this. It's not decided right now if we will go with a 4.9.65-3+deb9u3 including selected patches for identified regressions or go straight to 4.9.75. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#886485: linux-image-4.9.0-5-686-pae: Hangs on boot at ".... node #0, CPUs: #1"
On Sat, 2018-01-06 at 18:04 +, LJ wrote: > > Looking at the lspci output you have a Xeon E3 from the 1200 series, but > > you > > could provide your full /proc/cpuinfo? > > Hi, sure... Thanks > > root@sam:~# cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 60 > model name : Intel(R) Celeron(R) CPU G1840 @ 2.80GHz So definitely not a Xeon E3, but Haswell generation. > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx pdpe1gb > rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc > aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 > sdbg cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer > xsave rdrand lahf_lm abm tpr_shadow vnmi flexpriority ept vpid fsgsbase > tsc_adjust erms invpcid xsaveopt dtherm arat pln pts So with pcid/invpcid. Right now I'm unsure what to do. If you manage to get a kernel log (using a serial port or maybe netconsole if it's not too early in the boot) it'd help I guess. Try also booting without 'quiet' and with 'debug earlyprintk'. If you have the possibility to build a 4.9.75 kernel and try booting it might help (at one point I might have a Debian build for you but that's not the case right now). Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#886485: linux-image-4.9.0-5-686-pae: Hangs on boot at ".... node #0, CPUs: #1"
On Sat, 2018-01-06 at 15:46 +, LJ wrote: > Booting in recovery mode the final lines are: > > [ 0.058600] x86: Booting SMP configuration: > [ 0.058632] node #0, CPUs: :1 > > The cursor is flashing after the "#1" and the system hangs at that point. > > I have video and a screenshot of boot if that helps. Looking at the lspci output you have a Xeon E3 from the 1200 series, but you could provide your full /proc/cpuinfo? You're running the system in 32bit mode, which KAISER/KPTI doesn't touch (so meltdown is *not* fixed), so I guess it comes from the preparation patches for KAISER rather than KAISER itself. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64
control: reassign -1 xen-hypervisor-4.8-amd64 On Sat, 2018-01-06 at 15:23 +0100, Valentin Vidic wrote: > On Sat, Jan 06, 2018 at 03:08:26PM +0100, Yves-Alexis Perez wrote: > > According to that link, the fix seems to be configuration rather than > > code. > > Does this mean this bug against the kernel should be closed? > > Yes, the problem seems to be in the Xen hypervisor and not the Linux > kernel itself. The default value for the gnttab_max_frames parameter > needs to be increased to avoid domU disk IO hangs, for example: > > GRUB_CMDLINE_XEN="dom0_mem=10240M gnttab_max_frames=256" > > So either close the bug or reassign it to xen-hypervisor package so > they can increase the default value for this parameter in the > hypervisor code. > Ok, I'll reassign and let the Xen maintainers handle that (maybe in a stable update). @Xen maintainers: see the complete bug log for more information, but basically it seems that a domu freezes happens with the “new” multi-queue xen blk driver, and the fix is to increase a configuration value. Valentin suggests adding that to the default. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64
On Fri, 2017-11-17 at 07:39 +0100, Valentin Vidic wrote: > Hi, > > The problem seems to be caused by the new multi-queue xen blk driver > and I was advised by the Xen devs to increase the gnttab_max_frames=256 > parameter for the hypervisor. This has solved the blocking issue > for me and it has been running without problems for a few months now. I'm not really fluent in Xen, but does this relate to the kernel in dom0 or one of the domU then? > > I/O to LUNs hang / stall under high load when using xen-blkfront > https://www.novell.com/support/kb/doc.php?id=7018590 According to that link, the fix seems to be configuration rather than code. Does this mean this bug against the kernel should be closed? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#886417: linux-source-4.9: Kernel sources do not compile
On Fri, 2018-01-05 at 17:08 +0100, Robert Senger wrote: > Package: linux-source-4.9 > Version: 4.9.65-3+deb9u2 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > Dear Maintainer, > > compilation of Kernel sources 4.9.65-3+deb9u2 fails: > > [snip] > CC arch/x86/mm/gup.o > CC arch/x86/mm/setup_nx.o > CC arch/x86/mm/tlb.o > arch/x86/mm/tlb.c: In function ‘switch_mm_irqs_off’: > arch/x86/mm/tlb.c:160:3: error: implicit declaration of function > ‘load_new_mm_cr3’ [-Werror=implicit-function-declaration] >load_new_mm_cr3(next->pgd); >^~~ > cc1: some warnings being treated as errors Hi, this is a bit confusing. Are you trying to rebuild a kernel using the linux- source-4.9 package with a custom config, or are you trying to rebuild the src:linux package with no change at all? If the former, could you provide the configuration you use? Can you also check if upstream just-released 4.9.75 builds with that .config? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Intel Vulnerability
On Fri, 2018-01-05 at 10:07 +0300, Ozgur wrote: > I talked yesterday Debian kernel team and was a work on Debian kernel for > the latest stable, I think all users add to "x86_64_BUG_CPU_INSECURE" > parameter .config file and add "= y" added and recompiled. Hi Ozgur, that's completely irrelevant. For Meltdown fix on Stretch/amd64, please upgrade to the just published linux-image-4.9.0-5-amd64 version 4.9.65-3+deb9u2. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Intel Vulnerability
On Thu, 2018-01-04 at 20:51 +, joe.gha...@dell.com wrote: > Does anyone have any information about plans for releasing patches for the > Intel vulnerability issues for Debian Jessie and/or Stretch? Any information > would be really appreciated. Hi Joe, we are currently in the process of releasing updates addressing CVE-2017-5754 (meltdown) for Stretch. Jessie will follow later, as well as fixes for Spectre if/when they are available. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#882414: [src:linux] Oops: NULL pointer dereference - RIP: isci_task_abort_task+0x30/0x3e0 [isci]
On Sun, 26 Nov 2017 11:02:04 +0100 Salvatore Bonaccorsowrote: > Hi Martin, > > On Wed, Nov 22, 2017 at 02:04:48PM +0100, Martin Scharm wrote: > > Package: src:linux > > Version: 4.12.0-1 > > Severity: serious > > > > --- Please enter the report below this line. --- > > > > My Debian does not boot anymore since linux image 4.12.0-1. It runs > > right into a NULL pointer dereference and is apparently not even able to > > log the problem, so I just took a few photos with my phone. > > > > I experience the problem with 4.12.0-1, 4.12.0-2, and 4.13.0-1. I > > attached 3 photos of the bug messages. The messages seem to have the > > following in common (typed out of the pictures, for searching): > > Can you check if the issue goes away if you build with > 909657615d9b3ce709be4fd95b9a9e8c8c7c2be6 reverted? > > https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s4.2.2 Hi, I'm experiencing the same issue on a workstation here (Dell Precision T5600) with: 00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 05) 05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 05) I've built a 4.15-rc6 kernel with that patch reverted and the system seems to boot fine. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Disable intel management engine
On Fri, 2017-12-01 at 09:22 -0800, piruthiviraj natarajan wrote: > I see that system 76 disables intel management engine for a potential > security breach. > Does Debian has any plans similar to this? > > http://blog.system76.com/post/168050597573/system76-me-firmware-updates-plan System76 manages the hardware and firmware of their machines. Debian is a distribution, we have no control over what machine our users uses. Disabling the management using (using the HAP bit) is not something which can be attempted without deep knowledge of the machine it runs on. So the short answer would be no, because we can't. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
[RFC] Verify tag with gpg before extracting orig tarball
Hi there, as discussed this afternoon on IRC with Ben, I'd took a look at PGP-checking the tags when using genorig.py for extracing the kernel sources. I'm unsure how people (and especially Ben) do it nowadays, but for linux-grsec I mostly use genorig.py with git, and usually checks the tag signature before running genorig. I thought it might be a good idea to enforce this verification as part of the script, and fail if the signature fails. I've setup a branch in my own repository [1] if someone wants to take a look (I guess I can also resend with git send-email or something). [1] https://anonscm.debian.org/cgit/collab-maint/linux-grsec.git/log/?h=gpg-ta g-check Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#815125: Boot failure with Debian linux 4.4.2 package
On sam., 2016-02-20 at 17:43 +, Ben Hutchings wrote: > I apologise for this regression, which of course didn't affect any of > the several machines I was able to test on. Hi Ben, no issue, that's why it's called “unstable” :) > > Please can you each reply to the bug address with the following > details: > > - Does the affected system boot using the BIOS boot protocol > (including CSM) or UEFI boot protocol? UEFI, no CSM. > > - If you boot with the added kernel parameter "earlyprintk=vga" or > "earlyprintk=serial" (and without "quiet"), do any boot messages > appear before the hang/reboot? PLease send them (a photo is fine). Nothing > > - If it boots with UEFI, does the kernel parameter "efi=noruntime" > work around the problem? It does. Anything you want from that boot? > > - If you haven't already reported this, does the Linux 4.5-rc4 package > from experimental have the same problem? Same thing happens. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#815125: linux-image-4.4.0-1-amd64 fails to load initrd - no booting
On Fri, 19 Feb 2016 16:24:06 +0900 Norbert Preiningwrote: > Package: src:linux > Version: 4.4.2-1 > Severity: critical > Justification: breaks the whole system > > Dear all, > > till now I was running > linux-image-4.4.0-trunk-amd64 (from experimental) > without any problem. Today I installed > linux-image-4.4.0-1-amd64 (version 4.4.2-1) > and tried to boot into it. Booting stopped at > Loading initrd > and remains there. > I'm experiencing this issue too, on a 2015 Lenovo ThinkPad X250, using UEFI boot. I've tried to boot a vanilla 4.4.2 kernel with custom configuration, which boots fine. I'm rebuilding a vanilla 4.4.2 kernel with the Debian configuration to check wether it boots fine or not. It might be related to the UEFI patches added on top of the 4.4.2 kernel, not sure when they appeared. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#810129: linux-source-4.3 and linux-grsec-source-4.3: error when trying to install together
control: reassign -1 linux-grsec-source-4.3 On mer., 2016-01-06 at 19:54 +0100, Ralf Treinen wrote: > Here is a list of files that are known to be shared by both packages > (according to the Contents file for sid/amd64, which may be > slightly out of sync): > > /usr/src/linux-source-4.3.tar.xz > > This bug has been filed against both packages. If you, the maintainers of > the two packages in question, have agreed on which of the packages will > resolve the problem please reassign the bug to that package. You may then > also register in the BTS that the other package is affected by the bug. Indeed, it's a problem in linux-grsec, I'll fix it for the next upload. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#605090: [RFC] Proposal for a new linux-grsec source package
control: reassign -1 wnpp control: retitle -1 ITP: linux-grsec -- Linux kernel with grsecurity patch On mer., 2015-09-30 at 12:53 +0200, Yves-Alexis Perez wrote: > I should be able to push something for review pretty soon So here we are. I've pushed a git tree [1] of a linux-grsec source package, heavily based on src:linux (it's actually a clone of linux.git and I've worked in a grsec/sid branch). I've kept the featureset idea, and on top of that: - disabled all regular packages from src:linux (linux-libc-dev and friends) - disabled all non grsecurity featureset - renamed the source package to linux-grsec You can build it the same way you build the src:linux from git. I've also uploaded packages for sid and Jessie to my repository [2], including a .dsc [3] so rebuild should be easy. This is really a work in progress and this mail a request for comment. Especially missing is: - various updates to the the debian/control templates (like Maintainers/Uploaders etc.) - updates to debian/copyright - stuff I missed. I started this with 4.1.7, updated from the v4.1.6-1 tag in the linux.git. I've then pulled the 4.2.3-1 tag and it seemed to not break that much, so it might indeed be workable (but we'll see in the long run). In any case, everything is in the git folder, and feel free to ask questions if needed. I don't intent to upload this to Debian right away, obviously :) Regards, [1] https://anonscm.debian.org/cgit/collab-maint/linux-grsec.git [2] http://perso.corsac.net/~corsac/debian/kernel-grsec/packages/ [3] http://perso.corsac.net/~corsac/debian/kernel-grsec/packages/sid/linux-grsec_4.2.3-1.dsc -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#605090: update?
On Tue, Sep 15, 2015 at 12:20:06PM -0400, Erinn Clark wrote: > * Yves-Alexis Perez <cor...@debian.org> [2015:09:15 08:12 +0200]: > > I quickly discussed about that with Jacob on IRC following your ping, > > and yes, my current plan is to start from the current src:linux git > > repository (trying to avoid too much duplicate work), remove uneeded > > stuff for us and add the grsecurity patch on top. > > > > That way we might be able to sync / cherry-pick stuff from src:linux > > every once in a while. If that's unmaintainable then we'll just > > completely fork. > > > > I didn't yet start the actual work, but I intend to do that in the > > following days/weeks depending on my work schedule. > > Awesome! Please update the ticket with a git repo where the development is > happening once you begin, I'd love to be able to follow along and contribute > if > possible. I'm currently building my own grsec kernel packages as it is and > would be happy to at least test. Hi, I should be able to push something for review pretty soon, I've restarted working on this. Also I just gave my talk at kernel recipes 2015 [1]. Slides and video should be avaiable at one point on the website, but in the meantime the former is available at [2]. Regards, [1] https://kernel-recipes.org/en/2015/hardened-kernels-for-everyone/ [2] http://perso.corsac.net/~corsac/debian/kernel-grsec/PEREZ_Yves-Alexis_hardened-kernels.pdf -- Yves-Alexis Perez signature.asc Description: PGP signature
Bug#605090: update?
On mar., 2015-09-15 at 00:12 +0100, Ben Hutchings wrote: > There were several discussions with various people involved; the result > as I understand it was that a linux-grsecurity package is likely to be > acceptable in unstable (only) and Jacob would be ready to work on such a > package in Debian. I offered to help him with initial packaging, but > not to be a maintainer. I quickly discussed about that with Jacob on IRC following your ping, and yes, my current plan is to start from the current src:linux git repository (trying to avoid too much duplicate work), remove uneeded stuff for us and add the grsecurity patch on top. That way we might be able to sync / cherry-pick stuff from src:linux every once in a while. If that's unmaintainable then we'll just completely fork. I didn't yet start the actual work, but I intend to do that in the following days/weeks depending on my work schedule. Regads, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#605090: update?
On lun., 2015-09-14 at 14:15 -0400, Erinn Clark wrote: > Hi, > > I'm just wondering if there are any updates to this bug and in particular I'm > curious what could happen now that the grsecurity stable patches are only > available to sponsors. I still think getting grsec into Debian is a very > important and worthwhile goal, but we should begin discussing it again since I > believe there is more momentum. (I'd like to participate if possible, as > well.) > Hey Erinn, I somehow stopped updating this bugs, but my latest attempts are more or less documented on my blog [1]. I'm also giving a talk about all this in Kernel Recipes 2015 [2]. Right now the “easy” solution (make deb-pkg) is the best I can provide, and it's definitely not suitable for inclusion in Debian. But I'm planning to restart attempts to have something worth including in Debian. Regards, [1]: http://www.corsac.net/?cat=3 [2]: https://kernel-recipes.org/en/2015/hardened-kernels-for-everyone/ -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: [2/2] deb-pkg: add source package
On jeu., 2015-05-28 at 12:11 +0300, Riku Voipio wrote: + dpkg-genchanges ../linux-upstream_${packageversion}_ ${debarch}.changes +else + dpkg-genchanges -b ../linux-upstream_${packageversion}_ ${debarch}.changes ${debarch} seems empty here when using make deb-pkg, not too sure why (I'm building using KBUILD_OUTPUT, not sure if it's related). Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#785422: amd64: Please enable CONFIG_SND_SOC_INTEL_BROADWELL_MACH
On Sat, 16 May 2015 05:41:40 +0200 Sebastian Reichel s...@debian.org wrote: Source: linux Version: 4.0.2-1 Severity: wishlist Hi, Please enable CONFIG_SND_SOC_INTEL_BROADWELL_MACH. Broadwell processors are built into e.g. the Lenovo Thinkpad X250, which is available since February. I'm not speaking for the kernel team (which I'm not part of) but I own a X250 and wrote a page [1] about Linux support. I'm unsure what CONFIG_SND_SOC_INTEL_BROADWELL_MACH is supposed to be used for, but it's not needed for sound support on X250. At first sight this option looks related to Intel Smart Sound Technology (Intel SST) which looks to be a specific DSP for usages a bit like Siri on the iOS platforms. I don't think the CPU in the X250 has this technology, althought it might be useful for Core M Broadwell ultrabooks. In any case, loading the modules on my X250 doesn't do anything and don't show anything in dmesg either. So I don't say enabling it is bad, but I don't think it'll improve the experience on your ThinkPad. [1] http://www.corsac.net/X250/ Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#780862: [PATCH v2 0/7] New Lenovos 2015 touchpads: party time!
Control: tag -1 +patch I'm adding the Debian bug number on To: so it gets the information, and I'm dropping other recipients to limit the noise. On jeu., 2015-04-09 at 09:56 -0400, Benjamin Tissoires wrote: I've opened a Debian bug [1] to request the patch serie to be backported to the 3.16 kernel used by Debian and Ubuntu, but Ben Hutchings asked for more information than just the merge commit id. The merge contains the following commits: 09d042a2eb90ee2c86d80c48ad096ae3f5776cef Revert Input: synaptics - use dmax in input_mt_assign_slots 6067fe5e0bf29f525561c8281d01011cfc9ebbd4 Merge branch 'synaptics' into for-linus 8f004f3f4daf5dc98dc78f8e62497ad834053855 Input: synaptics - remove X250 from the topbuttonpad list 860e6f7fcbe5653ec4e394f9ee335f2032398beb Input: synaptics - remove X1 Carbon 3rd gen from the topbuttonpad list cdd9dc195916ef5644cfac079094c3c1d1616e4c Input: synaptics - re-route tracksticks buttons on the Lenovo 2015 series 3adde1f59195df2965f632e22b31f97fb371612f Input: synaptics - remove TOPBUTTONPAD property for Lenovos 2015 06aa374bc70468b517dd36b95c48c8f391c08a27 Input: synaptics - retrieve the extended capabilities in query $10 b57a7128be24062b5b5b26032b7cd58f1651547e Input: synaptics - do not retrieve the board id on old firmwares ebc80840b850db72f7ae84fbcf77630ae5409629 Input: synaptics - handle spurious release of trackstick buttons dc5465dc8a6d5cae8a0e1d8826bdcb2e4cb261ab Input: synaptics - fix middle button on Lenovo 2015 products 02e07492cdfae9c86e3bd21c0beec88dbcc1e9e8 Input: synaptics - skip quirks when post-2013 dimensions 5b3089ddb540401c1ad2e385a03d7e89ff954585 Input: synaptics - support min/max board id in min_max_pnpid_table b05f4d1c332a22f98c037fa64f249aa30877adaf Input: synaptics - remove obsolete min/max quirk for X240 ac097930f0730a9b37de2b51e0fc49d2be7a Input: synaptics - query min dimensions for fw v8.1 9aff65982d0f58a78a27769fba7e97bc937b2593 Input: synaptics - log queried and quirked dimension values 8b04baba10b007f8b6c245a50be73cf09cc3a414 Input: synaptics - split synaptics_resolution(), query first Are they all needed or is there a more minimal but still working list? 8b04baba...b57a7128 are marked as stable@ and will/should be backported in debian too. Ben, I'm not sure if you handle the 3.16.x-ckt branch as well and how your prefer handling this case (let upstream/CKT handle those or include 8b04baba...b57a7128 in the Debian build)? This leaves us the minimum patches to backport in addition to those 9: 06aa374bc70468b517dd36b95c48c8f391c08a27 Input: synaptics - retrieve the extended capabilities in query $10 3adde1f59195df2965f632e22b31f97fb371612f Input: synaptics - remove TOPBUTTONPAD property for Lenovos 2015 cdd9dc195916ef5644cfac079094c3c1d1616e4c Input: synaptics - re-route tracksticks buttons on the Lenovo 2015 series Ok. 09d042a2eb (Revert Input: synaptics - use dmax in input_mt_assign_slots) is only required if the reverted commit is already in the debian tree, which I doubt given that it was introduced in v3.19 or v4.0. Ok, I don't think it's needed then. Thank your for your help! Ben, is that ok for you or can I help further? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#780862: linux-image-3.16.0-4-amd64: please backport 2015 ThinkPad Trackpoint/Touchpad support patches
Package: src:linux Version: 3.16.7-ckt7-1 Severity: normal Hi, as already reported on IRC, the trackpoint/touchpad in 2015 ThinkPads (X250 for example) is not really supported right now. A patchset was merged into Linus tree this morning (b314acaccd7e0d55314d96be4a33b5f50d0b3344), it'd be nice to have it included in the Debian kernel if/when possible. I'm currently running the 4.0-rc4+ kernel including the patch and it mostly seem to work fine. Feel free to ping me if anything else is needed. Regards, -- Yves-Alexis -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: LENOVO product_name: 20CMCTO1WW product_version: ThinkPad X250 chassis_vendor: LENOVO chassis_version: None bios_vendor: LENOVO bios_version: N10ET29W (1.06 ) board_vendor: LENOVO board_name: 20CMCTO1WW board_version: SDK0E50512 STD ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09) Subsystem: Lenovo Device [17aa:2226] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: access denied 00:02.0 VGA compatible controller [0300]: Intel Corporation Broadwell-U Integrated Graphics [8086:1616] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:2226] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 42 Region 0: Memory at e000 (64-bit, non-prefetchable) [size=16M] Region 2: Memory at c000 (64-bit, prefetchable) [size=512M] Region 4: I/O ports at 3000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller [8086:160c] (rev 09) Subsystem: Lenovo Device [17aa:2226] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 44 Region 0: Memory at e123 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: snd_hda_intel 00:14.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB xHCI Controller [8086:9cb1] (rev 03) (prog-if 30 [XHCI]) Subsystem: Lenovo Device [17aa:2226] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 45 Region 0: Memory at e122 (64-bit, non-prefetchable) [size=64K] Capabilities: access denied Kernel driver in use: xhci_hcd 00:16.0 Communication controller [0780]: Intel Corporation Wildcat Point-LP MEI Controller #1 [8086:9cba] (rev 03) Subsystem: Lenovo Device [17aa:2226] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx+ Latency: 0 Interrupt: pin A routed to IRQ 255 Region 0: Memory at e1239000 (64-bit, non-prefetchable) [size=32] Capabilities: access denied 00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection (3) I218-LM [8086:15a2] (rev 03) Subsystem: Lenovo Device [17aa:2226] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 47 Region 0: Memory at e120 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at e123e000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 3080 [size=32] Capabilities: access denied Kernel driver in use: e1000e 00:1b.0 Audio device [0403]: Intel Corporation Wildcat Point-LP High Definition Audio Controller [8086:9ca0] (rev 03) Subsystem: Lenovo Device [17aa:2226] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32, Cache Line Size: 64 bytes Interrupt: pin A routed to
Bug#780467: linux-image-3.16.0-4-amd64: Please backport thinkpad_acpi support for 2015 ThinkPads
Package: src:linux Version: 3.16.7-ckt7-1 Severity: wishlist Hi, thinkpad_acpi in 3.16 and 3.19 won't load on 2015 ThinkPads (for example on this X250) because of a changed pattern in the BIOS version string. Commit 1b0eb5bc241354aa854671fdf02132d2d1452bdf in 4.0 added support for those ThinkPads, so it'd be nice to have it in Jessie and Sid. That's not enough for full hardware support of 2015 ThinkPads, but it's a start. Thanks in advance, and regards, -- Yves-Alexis -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) ** Command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/balvenie-root ro quiet intel_iommu=on psmouse.proto=imps splash intel_iommu=off ** Not tainted ** Kernel log: ** Model information sys_vendor: LENOVO product_name: 20CMCTO1WW product_version: ThinkPad X250 chassis_vendor: LENOVO chassis_version: None bios_vendor: LENOVO bios_version: N10ET27W (1.04 ) board_vendor: LENOVO board_name: 20CMCTO1WW board_version: SDK0E50512 STD ** Loaded modules: ccm uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media ecb btusb bluetooth 6lowpan_iphc xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack deflate nf_conntrack ctr ip6table_filter ip6_tables twofish_generic x_tables twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_aesni_avx2 camellia_aesni_avx_x86_64 camellia_x86_64 serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 xts serpent_generic blowfish_generic blowfish_x86_64 blowfish_common cast5_avx_x86_64 cast5_generic cast_common des_generic cbc cmac xcbc rmd160 sha512_ssse3 sha512_generic sha256_ssse3 sha256_generic hmac crypto_null af_key xfrm_algo nls_utf8 nls_cp437 vfat fat arc4 iwlmvm mac80211 rtsx_pci_sdmmc rtsx_pci_ms iwlwifi mmc_core memstick rtsx_pci iTCO_wdt cfg80211 iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp intel_rapl coretemp kvm crc32_pclmul crc32c_intel ghash_clmulni_intel efi_pstore psmouse ehci_pci serio_raw efivars sg i2c_i801 ehci_hcd lpc_ich mfd_core shpchp xhci_hcd nvram rfkill tpm_tis battery tpm ac usbcore snd_hda_intel snd_hda_controller evdev snd_hda_codec snd_hwdep snd_pcm e1000e snd_timer snd soundcore mei_me usb_common ptp mei pps_core processor loop autofs4 ext4 crc16 mbcache jbd2 dm_crypt dm_mod sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd ahci libahci i915 i2c_algo_bit libata drm_kms_helper scsi_mod drm i2c_core thermal wmi video thermal_sys button ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09) Subsystem: Lenovo Device [17aa:2226] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: access denied 00:02.0 VGA compatible controller [0300]: Intel Corporation Broadwell-U Integrated Graphics [8086:1616] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:2226] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 59 Region 0: Memory at e000 (64-bit, non-prefetchable) [size=16M] Region 2: Memory at c000 (64-bit, prefetchable) [size=512M] Region 4: I/O ports at 3000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller [8086:160c] (rev 09) Subsystem: Lenovo Device [17aa:2226] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 64 Region 0: Memory at e123 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: snd_hda_intel 00:14.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB xHCI Controller [8086:9cb1] (rev 03) (prog-if 30 [XHCI]) Subsystem: Lenovo Device [17aa:2226] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr-
Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS
On dim., 2014-06-15 at 19:31 +0100, Ben Hutchings wrote: Please can you assign a CVE ID to this bug? Hi Ben, we usually don't assign CVE from our pool for public issues, and I'm especially reluctant here as I don't know if someone else aware of this issue could have assign one. So I'm asking on oss-sec to assign one so it gets some publicity for security people and someone has a chance to yell if a CVE has already been assigned. oss-sec / MITRE: it seems that SECCOMP on MIPS doesn't behave properly (see [1] for all the details). I'm unsure when it started (I guess when seccomp was first added to MIPS, it seems at least 3.2 is affected), and it's fixed in 3.15 (with 137f7df8cead00688524c82360930845396b8a21). Can someone assign a CVE is this is indeed a new issue? Regards, [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751417 -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#605090: Proposing amd64-hardened architecture for Debian
On Tue, Apr 22, 2014 at 08:30:01PM +0100, Ben Hutchings wrote: On Mon, 2014-04-21 at 05:28 +0200, Carlos Alberto Lopez Perez wrote: On 17/04/14 00:23, Aaron Zauner wrote: Now shipping grsec is a really good idea. I'd like to see that as well. There has been an attempt to provide an official grsec-flavour of the Debian kernel, but it didn't worked: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090 For those interested, Corsac provides packages: https://wiki.debian.org/grsecurity There was a recent discussion on -private where I think there was some consensus that a grsecurity kernel package could be included in Debian as a separate source package. I'm a bit unsure about that consensus. Right now there are two attempts to provide a grsecurity package for Debian: - mine, which is about adding a grsec featureset to the src:linux package (so basically adding grsec patch on top of the Debian patches, and re-using everything else). This attempt was already NACK-ed by the kernel team; - the Mempo/SameKernel attempt, which is about using a vanilla kernel and adding grsecurity on top of it (and, I guess, a .config which looks like the src:linux one) The latter is much easier in term of management since all the integration is done by spender (he's actually working on providing .deb builds of grsec packages), so I didn't really consider it worthy to investigate time on it since basically everyone can do it with a simple script. NOTE: I don't want to dismiss Mempo attempts, especially the reproducible build part, and I also think it's valuable to provide our users a grsec kernel as part of the distribution, just that I prefered to go the featureset way. I had the impression that adding a new copy of the linux sources was not really something appreciated by the project, and re-using linux-source (binary) package means the patch porting needs to be done anyway. But if I'm wrong or if things have changed since them, and there's indeed a consensus for the vanilla + grsecurity + make deb-pkg as an easy way to provide grsec kernels in the Debian archive, then I'm all for it. Regards, -- Yves-Alexis Perez signature.asc Description: Digital signature
Re: [Pkg-xfce-devel] Bug#738945: task-xfce-desktop: Hibernate doesn't work out of the box
Control: reassign -1 src:linux Control: tag -1 wheezy Kernel maintainers: it seems that Max has an issue with suspend to disk in Wheezy. He initially reported against tasksel because he thought it was related to the default install, but in the end it looks like it's more a kernel issue. On Tue, Mar 11, 2014 at 12:51:38PM +0100, Max Kubierschky wrote: Hi everybody, Ok, I was't informed, that hibernating should work without uswsusp. So I removed uswsusp again, for bug-hunting. I did try as suggested: - logout button, then hibernate - pm-hibernate (as root) - echo disk /sys/power/state (as root) All of the above have the same effect: The screen goes black, after some seconds, the computer switches off. When switching it on again, It boots normally instead of returning to the hibernated state. So this bug is indeed not related to Xfce. Thanks, I'm reassigning to the Linux kernel then. It might help to try to reproduce with a vanilla 3.2 kernel, but I'll let the Linux maintainers ask the information they need. For me personally, the problem is solved, as I am fine with uswsusp. But if it may benefit other users, I'm willing to cooperate in hunting it down further. As to my hardware: Its a Dell inspiron 1525 Notebook. To provide more information, below is the output from lspci. I have the non-free module iwl3945 installed for wifi, but rmmod iwl3945 iwl_legacy mac80211 cfg80211 before hibernating doesn't change anything. Yours, Max lspci 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c) 00:1a.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 02) 00:1a.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02) 00:1a.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02) 00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 02) 00:1d.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 02) 00:1d.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) 00:1f.0 ISA bridge: Intel Corporation 82801HM (ICH8M) LPC Interface Controller (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02) 02:09.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05) 02:09.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) 02:09.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12) 02:09.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12) 09:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller (rev 12) 0b:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) Am 11.03.2014 11:16, schrieb Yves-Alexis Perez: On Tue, Mar 11, 2014 at 01:13:59AM +0100, Cyril Brulebois wrote: Hi Xfce maintainers, please find below an installation report regarding Xfce. Feedback welcome. Thanks for the report, answers inline. Max Kubierschkym...@knirz.de (2014-02-14): Package: task-xfce-desktop Version: 3.14.1 Severity: normal Dear Maintainer, I installed debian wheezy with xfce desktop. hibernate was available in the energy settings, but did not work. Or more exactly, hibernate did work, but after switching on the computer again, it booted normally, instead of thawing. After some debugging and research, Installing uswsusp solved the problem. What kind of debug did you do? Do the following ways work: - logout button, then hibernate - pm-hibernate (as root) - echo disk /sys/power/state (as root) Also, it'd help to know the kind of hardware you have (and especially stuff like wireless and graphic cards). Suggestion: add dependency on uswsusp to package task-xfce-desktop No way. uswsusp is (imho) just plain useless. Hibernation
Re: [Pkg-xfce-devel] Bug#735080: xfce4-mixer: External amplifier checkbox missing after recent updates; cannot uncheck, so no audio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 control: reassign -1 src:linux On Sun, Jan 12, 2014 at 02:27:12PM -0500, I. Am wrote: It'd be nice to confirm is the setting existed in alsamixer before (try maybe to boot with an older kernel), but it might just be a kernel issue then. Indeed, booting 3.11-1-amd64 / 3.11.6-2 restores the checkbox option and sound. Then I guess it's a change in the kernel part. Not sure if it's really a bug or just an evolution though, but I'll reassign. Linux maintainers: The original reporter seems to have a regression with 3.12 kernel, where an alsa control disappeared on upgrade. I'm not sure if it's something which has been replaced or if it's real regression. Regads, - -- Yves-Alexis Perez -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJS0vSaAAoJEG3bU/KmdcClvXUH/0vh5XisZZhjiMyjsrkvPJcv TlMXo1+cks8ratK/W24JpybxsC+9KcFn30lPkBACvd2hgW7hle54/1kS4Gh5InJU LpNsnPa6MneGERQP1NHe7nms8Sy7H1l7sGbZ5L08v75C7G8fsq28027C3ypwUUif qTZWPrIEXz2kfoJYzk+lvMlbZqKG8smmU3Cn63VImLN2V45WZDn1FRBTK6GAlF5w 3i2/cs9xfag7eTEt30wv+Yp6+l4dYyO8wvh6qDSPE/+B+VO7uvRlx+pd/gpKg7pX +Fq1G4gzDOhTPXeJL4loD/GjT3Ov0BzjbZy85Y+hgvWosRunA8QAA//VPzFVDJg= =KUrd -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/20140112200134.ge30...@scapa.corsac.net
Bug#717590: [Fwd: Patch drm/nv50-/disp: Use output specific mask in interrupt has been added to the 3.10-stable tree]
For information Forwarded Message From: gre...@linuxfoundation.org To: emil.l.veli...@gmail.com, bske...@redhat.com, cor...@debian.org, gre...@linuxfoundation.org Cc: sta...@vger.kernel.org, stable-comm...@vger.kernel.org Subject: Patch drm/nv50-/disp: Use output specific mask in interrupt has been added to the 3.10-stable tree Date: Tue, 23 Jul 2013 10:06:43 -0700 X-spam-status: No, score=-1.9 tagged_above=- required=0.5 tests=[BAYES_00=-1.9] autolearn=ham This is a note to let you know that I've just added the patch titled drm/nv50-/disp: Use output specific mask in interrupt to the 3.10-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: drm-nv50-disp-use-output-specific-mask-in-interrupt.patch and it can be found in the queue-3.10 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let sta...@vger.kernel.org know about it. From 378f2bcdf7c971453d11580936dc0ffe845f5880 Mon Sep 17 00:00:00 2001 From: Emil Velikov emil.l.veli...@gmail.com Date: Tue, 2 Jul 2013 14:44:12 +0100 Subject: drm/nv50-/disp: Use output specific mask in interrupt From: Emil Velikov emil.l.veli...@gmail.com commit 378f2bcdf7c971453d11580936dc0ffe845f5880 upstream. The commit commit 476e84e126171d809f9c0b5d97137f5055f95ca8 Author: Ben Skeggs bske...@redhat.com Date: Mon Feb 11 09:24:23 2013 +1000 drm/nv50-/disp: initial supervisor support for off-chip encoders changed the write mask in one of the interrupt functions for on-chip encoders, causing a regression in certain VGA dual-head setups. This commit reintroduces the mask thus resolving the regression Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66129 Reported-and-Tested-by: Yves-Alexis cor...@debian.org CC: Ben Skeggs bske...@redhat.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com Signed-off-by: Ben Skeggs bske...@redhat.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- drivers/gpu/drm/nouveau/core/engine/disp/nv50.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c @@ -1107,6 +1107,7 @@ nv50_disp_intr_unk20_2(struct nv50_disp_ u32 pclk = nv_rd32(priv, 0x610ad0 + (head * 0x540)) 0x3f; u32 hval, hreg = 0x614200 + (head * 0x800); u32 oval, oreg; + u32 mask; u32 conf = exec_clkcmp(priv, head, 0xff, pclk, outp); if (conf != ~0) { if (outp.location == 0 outp.type == DCB_OUTPUT_DP) { @@ -1133,6 +1134,7 @@ nv50_disp_intr_unk20_2(struct nv50_disp_ oreg = 0x614280 + (ffs(outp.or) - 1) * 0x800; oval = 0x; hval = 0x; + mask = 0x; } else if (!outp.location) { if (outp.type == DCB_OUTPUT_DP) @@ -1140,14 +1142,16 @@ nv50_disp_intr_unk20_2(struct nv50_disp_ oreg = 0x614300 + (ffs(outp.or) - 1) * 0x800; oval = (conf 0x0100) ? 0x0101 : 0x; hval = 0x; + mask = 0x0707; } else { oreg = 0x614380 + (ffs(outp.or) - 1) * 0x800; oval = 0x0001; hval = 0x0001; + mask = 0x0707; } nv_mask(priv, hreg, 0x000f, hval); - nv_mask(priv, oreg, 0x0707, oval); + nv_mask(priv, oreg, mask, oval); } } Patches currently in stable-queue which might be from emil.l.veli...@gmail.com are queue-3.10/drm-nv50-disp-use-output-specific-mask-in-interrupt.patch -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#717590: linux: [nouveau] please backport drm/nv50-/disp: Use output specific mask ininterrupt
Source: linux Severity: normal [the bug is not reported on the machine actually having the hardware] Hi, 3.9 introduced a regression in nouveau driver. Basically, dual screen using DMS59 connector doesn't work anymore in 3.9 and 3.10. After a bit of debugging [1] it has been fixed [2] but apparently not yet backported to stable (nor 3.9 nor 3.10). Since it completely breaks dual screen setup on those boxes, it'd be nice to include the patch in the Debian package until they get properly included in a stable release. Thanks in advance, and regards, -- Yves-Alexis [1]: https://bugs.freedesktop.org/show_bug.cgi?id=66129 [2]: http://lists.freedesktop.org/archives/nouveau/2013-July/012895.html -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (450, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.10-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20130722191944.29511.61315.reportbug@scapa
[PATCH] Correctly handle $KCONFIG_CONFIG
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I noticed that the builddeb packaging script used by make deb-pkg didn't handle $KCONFIG_CONFIG environment for setting the config file. This patch adds support for the variable. Signed-off-by: Yves-Alexis Perez cor...@debian.org - --- scripts/package/builddeb | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/scripts/package/builddeb b/scripts/package/builddeb index 3c6c0b1..243d3c9 100644 - --- a/scripts/package/builddeb +++ b/scripts/package/builddeb @@ -41,9 +41,9 @@ create_package() { parisc*) debarch=hppa ;; mips*) - - debarch=mips$(grep -q CPU_LITTLE_ENDIAN=y .config echo el) ;; + debarch=mips$(grep -q CPU_LITTLE_ENDIAN=y $KCONFIG_CONFIG echo el) ;; arm*) - - debarch=arm$(grep -q CONFIG_AEABI=y .config echo el) ;; + debarch=arm$(grep -q CONFIG_AEABI=y $KCONFIG_CONFIG echo el) ;; *) echo 2 echo ** ** ** WARNING ** ** ** 2 @@ -105,12 +105,12 @@ fi if [ $ARCH = um ] ; then $MAKE linux cp System.map $tmpdir/usr/lib/uml/modules/$version/System.map - - cp .config $tmpdir/usr/share/doc/$packagename/config + cp $KCONFIG_CONFIG $tmpdir/usr/share/doc/$packagename/config gzip $tmpdir/usr/share/doc/$packagename/config cp $KBUILD_IMAGE $tmpdir/usr/bin/linux-$version else cp System.map $tmpdir/boot/System.map-$version - - cp .config $tmpdir/boot/config-$version + cp $KCONFIG_CONFIG $tmpdir/boot/config-$version # Not all arches include the boot path in KBUILD_IMAGE if [ -e $KBUILD_IMAGE ]; then cp $KBUILD_IMAGE $tmpdir/boot/vmlinuz-$version @@ -119,7 +119,7 @@ else fi fi - -if grep -q '^CONFIG_MODULES=y' .config ; then +if grep -q '^CONFIG_MODULES=y' $KCONFIG_CONFIG ; then INSTALL_MOD_PATH=$tmpdir make KBUILD_SRC= modules_install if [ $ARCH = um ] ; then mv $tmpdir/lib/modules/$version/* $tmpdir/usr/lib/uml/modules/$version/ @@ -240,7 +240,7 @@ fi # Build header package (cd $srctree; find . -name Makefile -o -name Kconfig\* -o -name \*.pl $objtree/debian/hdrsrcfiles) (cd $srctree; find arch/$SRCARCH/include include scripts -type f $objtree/debian/hdrsrcfiles) - -(cd $objtree; find .config Module.symvers include scripts -type f $objtree/debian/hdrobjfiles) +(cd $objtree; find $KCONFIG_CONFIG Module.symvers include scripts -type f $objtree/debian/hdrobjfiles) destdir=$kernel_headers_dir/usr/src/linux-headers-$version mkdir -p $destdir (cd $srctree; tar -c -f - -T $objtree/debian/hdrsrcfiles) | (cd $destdir; tar -xf -) - -- 1.7.10.4 - -- Yves-Alexis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCgAGBQJRca8FAAoJEG3bU/KmdcCl9HEH/AnfDEUw58DkxlNLARM8nkfO x7DRZmSL9eLeRbalhU1iMNxSKj7An62Z7mkGGDUBVppBu6EA1G+QIFn+n/KpJIg5 ufEODYphwY1dgy0fN/i336Hu3pb60KrhuPLBFIyoe8EQQWLyG9PvM5KvjNc7937A NZ4fhuxTdF7tm3TY0RkeaIglHCiwyYOpULtk67pRHhmedC5l1WuBspelPUj8GeH6 /8vciNnn+3cnhCPIo1YC+2784B9YWQoFEVciAkxCutzfS+UUplXya2E7J4OqDm4T wDqfGOtAH1WlXF0AhDuhv5Fnkc+ts4fuq7KmwqOJ+MVV1n+RUOcFj0ChwDm22lY= =wF+s -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/20130419205433.ga3...@scapa.corsac.net
Bug#639919: linux-2.6: please enable DEBUG_STRICT_USER_COPY_CHECKS
On dim., 2012-06-03 at 01:08 +0100, Ben Hutchings wrote: So sizeof(s) == 4 and count = 3, How do you know that? From the call stack? but the compiler is still too stupid to avoid generating a conditional call to copy_from_user_overflow(). And this would break the build if we did what you're asking. Well, I think the point is to manage to fix those (if it's now the default upstream, I guess there will be some more visibility and people trying to fix them). I still think it's useful to catch those at compile time instead of at runtime. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#639919: linux-2.6: please enable DEBUG_STRICT_USER_COPY_CHECKS
On dim., 2012-06-03 at 14:22 +0100, Ben Hutchings wrote: On Sun, 2012-06-03 at 09:07 +0200, Yves-Alexis Perez wrote: On dim., 2012-06-03 at 01:08 +0100, Ben Hutchings wrote: So sizeof(s) == 4 and count = 3, How do you know that? From the call stack? What? Did you even read the code? Sorry, I misunderstood that. Indeed, at runtime you know that count is checked before so copy_from_user() will have a correct size. but the compiler is still too stupid to avoid generating a conditional call to copy_from_user_overflow(). And this would break the build if we did what you're asking. Well, I think the point is to manage to fix those (if it's now the default upstream, I guess there will be some more visibility and people trying to fix them). I still think it's useful to catch those at compile time instead of at runtime. I think it's more useful to be able to build the kernel than to not be able to build the kernel. Well, sure, but that doesn't mean it shouldn't be fixed upstream (wether issues are false positive or real ones). But maybe that's not Debian role to check for those. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#605090: Grsec to follow 3.2 stable release
This might be relevant for interested people: Linux 3.2 chosen as new stable kernel, 2.6.32 support continues (Feb 04 2012) The PaX Team and I have decided on Linux 3.2 as the new stable kernel, joining with the choice made by Debian and Ubuntu. We will continue to support 2.6.32 until the end of this year, at least. (http://grsecurity.net/news.php#newstable) Regards, -- Yves-Alexis -- 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/1328523782.2931.0.camel@oban
Re: Bug#605090: Linux 3.2 in wheezy
On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote: On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez cor...@debian.org wrote: So I think it's perfectly clear that nor Debian nor Grsecurity are really interested in Debian shipping a Grsecurity kernel. Well, I don't think its fair to say Debian is not interested in shipping a Grsecurity kernel. I think its more accurate to say that the current configuration of the Debian kernel team doesn't find the time to deal with it... but I'm not sure that speaks for all of Debian. Well, in this case, that's mostly the same. I'm sure there are people in Debian which are interested (even outside of me). But here, the kernel team has the final word (well, or the tech ctte, but I really don't see the point of that). […] Anyway, I'll keep updating the current setup for interested people, but without any interest from either party, that definitely looks like a dead end. What is stopping you from creating another package, that provides the kernel with grsecurity patches applied? Don't bother the kernel team with it, and just maintain it yourself in the archive? Its free software afterall. Honestly, having multiple linux source package in the archive doesn't really sound like a good idea. I don't really think the kernel team would appreciate, I'm pretty sure ftpmasters would disagree, and as a member of the security team, It's definitely something I would object. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Bug#605090: Linux 3.2 in wheezy
On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote: On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote: On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote: What is stopping you from creating another package, that provides the kernel with grsecurity patches applied? Don't bother the kernel team with it, and just maintain it yourself in the archive? Its free software afterall. Honestly, having multiple linux source package in the archive doesn't really sound like a good idea. I don't really think the kernel team would appreciate, I'm pretty sure ftpmasters would disagree, and as a member of the security team, It's definitely something I would object. Well, that's what we have the 'linux-source' packages for: to allow other packages to build-depend on them. Hmhm, that might be a good idea indeed. I need to investigate and try that a bit. Ben, what would kernel team think of that? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Bug#605090: Linux 3.2 in wheezy
On mer., 2012-02-01 at 14:32 +, Ben Hutchings wrote: On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote: On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote: On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote: On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote: What is stopping you from creating another package, that provides the kernel with grsecurity patches applied? Don't bother the kernel team with it, and just maintain it yourself in the archive? Its free software afterall. Honestly, having multiple linux source package in the archive doesn't really sound like a good idea. I don't really think the kernel team would appreciate, I'm pretty sure ftpmasters would disagree, and as a member of the security team, It's definitely something I would object. Well, that's what we have the 'linux-source' packages for: to allow other packages to build-depend on them. Hmhm, that might be a good idea indeed. I need to investigate and try that a bit. Ben, what would kernel team think of that? I don't speak for the whole team, but I don't see that it solves any problem. You would have to Build-Depend on exact versions of linux-source, so that you know your external patches will apply. Then you would have to rebase the patches every time linux-2.6 is updated, making sure (without much help from upstream) that you don't introduce a subtle security problem. Well, that's already what I do and intended to do (and that's clear from the beginning of the bug report). Wrt not introducing subtle security problems, what I mostly do is remove the security backports from the grsec patch which are already applied to Debian kernel, so this part is fairly straightforward. Now indeed when doing the job for Squeeze kernel it's a bit less straightforward because of the huge amount of driver backports, but from my own experience, the conflicts are still mostly about changed context lines. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Bug#605090: Linux 3.2 in wheezy
On mer., 2012-02-01 at 19:14 +0100, Bastian Blank wrote: On Wed, Feb 01, 2012 at 10:34:28AM +0100, Wouter Verhelst wrote: Well, that's what we have the 'linux-source' packages for: to allow other packages to build-depend on them. Since 3.1 or so it is not longer possible to use this package as source in terms of the GPL like the udebs have done for several releases. Could you be a bit more specific? -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Bug#605090: Linux 3.2 in wheezy
On do, 2012-02-02 at 12:18 +1100, Russell Coker wrote: On Thu, 2 Feb 2012, dann frazier da...@dannf.org wrote: Whilte it may help the kernel team to not have to worry about problems in the grsec flavor when preparing uploads, preventing delays for the non-grsec images. But, that just pushes the coordination down a ways - for stable updates we would need to add the grsec build into the pipeline, and there'd be delays in grsec security updates that go in via linux-2.6. Not nak'ing the idea, but it does extend some critical paths. The current approach of having a kernel patch package seems to work well. It removes the need for involvement of the kernel and security teams (presumably security changes to the kernel will usually not require changes to the grsecurity patch) and allows the users to easily build their own kernels. If a user has a choice between using Spender's Debian package and a kernel- patch package to build their own kernel then I think that they should be able to do whatever they want. Spender suggested that people who want GRSecurity on Debian would be better off using a .deb he provides and working on user-space hardening. (please don't top-post) If people on the CC: list want to be dropped, please ask :) On jeu., 2012-02-02 at 07:18 +0100, Kees de Jong wrote: Perhaps you should contact Julien Tinnes of http://kernelsec.cr0.org/ He has been too busy to work on the kernels lately but maybe he wants to help. Well Julien was aware of my initiative and, afaict, he didn't really have time for that, nor was interested in the porting part. And as I said before, I'm not interested in shipping just a patch in Debian. If users want to patch the kernel, configure it and built it, I think they're better off getting the latest patch from grsecurity.net and kernel from kernel.org. The point was in shipping a binary package with a default setup secure enough, and a way to tune the features through sysctl. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Linux 3.2 in wheezy
(adding few CC:s to keep track on the bug) On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote: On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote: On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote: Featuresets --- The only featureset provided will be 'rt' (realtime), currently built for amd64 only. If there is interest in realtime support for other architectures, we may be able to add that. However, we do need to consider the total time taken to build binary packages for each architecture. If there are particular container features that should be enabled or backported to provide a useful replacement for OpenVZ or VServer, please let us know. We cannot promise that these will all be enabled but we need to know what is missing. So in the end what are the reasons for not trying the grsecurity featureset? #605090 lacks any reply from the kernel team since quite a while, and especially after answers were provided to question asked. You already know the main reason: Feature-wise, Brad Sprengler and the PaX team still add stuff, like the gcc plugins or hardening features like symbols hiding, fix bugs (for example in RBAC code), while few of them reach mainline. I realise that the mainline Linux developers have sometimes been unreasonably resistant to these changes and I'm not intending to assign blame for this. But practically this means that we have to either carry the featureset indefinitely or disappoint users by removing it in a later release. (See the complaints about removing OpenVZ in wheezy despite 4 years' advance notice of this.) I understand this, and I still see the grsec featureset as a valuable project. Indeed, reducing the diff wrt. upstream in Debian kernel is an important goal (especially considering the time involvement). Now, I still think having a hardened Debian kernel inside the distribution is helpful and needed for some people (some of them have said so on the bug report, some other directly told me). I can continue providing kernels for stable and sid outside of Debian, but that means it's painful to find them, so less people will use it. I'm sure I don't have to remind people, but having a hardened kernel can buy you some time when some vulnerabilities are found in the kernel, like the /proc/pid/mem one (even when it does not prevent completely the vulnerability, it can prevents the exploit to be successful, for example). It also appears that you never had any response to your question to upstream about minimising the patch set. Indeed. Brad, I'm not sure if you received the initial mail, so if you have any comment… Not doing anything is indeed a way to just get rid of the question, but I would have at least appreciated a definitive answer on the bug rather than via the dda mail. I'm sorry about that; it completely slipped my mind as there have been no discussions about it for some months. Well, the last mail from the kernel team on the bug was indeed months ago (nov 10th afaict), but I kept adding info and replies since. Anyway, thanks for your answer. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Bug#605090: Linux 3.2 in wheezy
On lun., 2012-01-30 at 14:08 +, Ben Hutchings wrote: On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote: (adding few CC:s to keep track on the bug) On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote: On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote: On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote: Featuresets --- The only featureset provided will be 'rt' (realtime), currently built for amd64 only. If there is interest in realtime support for other architectures, we may be able to add that. However, we do need to consider the total time taken to build binary packages for each architecture. If there are particular container features that should be enabled or backported to provide a useful replacement for OpenVZ or VServer, please let us know. We cannot promise that these will all be enabled but we need to know what is missing. So in the end what are the reasons for not trying the grsecurity featureset? #605090 lacks any reply from the kernel team since quite a while, and especially after answers were provided to question asked. You already know the main reason: Feature-wise, Brad Sprengler and the PaX team still add stuff, like the gcc plugins or hardening features like symbols hiding, fix bugs (for example in RBAC code), while few of them reach mainline. I realise that the mainline Linux developers have sometimes been unreasonably resistant to these changes and I'm not intending to assign blame for this. But practically this means that we have to either carry the featureset indefinitely or disappoint users by removing it in a later release. (See the complaints about removing OpenVZ in wheezy despite 4 years' advance notice of this.) I understand this, and I still see the grsec featureset as a valuable project. Indeed, reducing the diff wrt. upstream in Debian kernel is an important goal (especially considering the time involvement). Now, I still think having a hardened Debian kernel inside the distribution is helpful [...] I agree and I would like to see hardening of *all* our configurations, where the performance cost is not too much. That's going to protect all our users rather than just people who seek out a special paranoid configuration. So I think it's perfectly clear that nor Debian nor Grsecurity are really interested in Debian shipping a Grsecurity kernel. I find that sad, because I do think there are users of both which would benefit from that, and not only people who seek out a special paranoid configuration. Anyway, I'll keep updating the current setup for interested people, but without any interest from either party, that definitely looks like a dead end. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Linux 3.2 in wheezy
On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote: Featuresets --- The only featureset provided will be 'rt' (realtime), currently built for amd64 only. If there is interest in realtime support for other architectures, we may be able to add that. However, we do need to consider the total time taken to build binary packages for each architecture. If there are particular container features that should be enabled or backported to provide a useful replacement for OpenVZ or VServer, please let us know. We cannot promise that these will all be enabled but we need to know what is missing. So in the end what are the reasons for not trying the grsecurity featureset? #605090 lacks any reply from the kernel team since quite a while, and especially after answers were provided to question asked. Not doing anything is indeed a way to just get rid of the question, but I would have at least appreciated a definitive answer on the bug rather than via the dda mail. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#605090: [RFC] Add a grsec featureset to Debian kernels
On mer., 2011-12-28 at 05:45 +0100, Carlos Alberto Lopez Perez wrote: Hello, What is the status of this? It has been a looong time ago since last update. Sorry for the delay. As the BTS doesn't automatically CC the submitter, please keep me on CC: when replying to this bug. For sid, I keep updating the kernels from time to time, you can see the grsec-patches (against the sid svn branch) at http://anonscm.debian.org/gitweb/ and binary packages can be found at http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/sid/ (I don't upload every built kernel there since it's a bit huge. For squeeze, I'm a bit lagging but I should update both the relevant branch in grsec-patches and the repository. I don't give a status update each time I update the repositories in order not to flood people, and I still hope some positive answer from the kernel team (until it's obvious it's too late for Wheezy). I am also interested in having a Debian kernel with the grsec+pax featureset and I am sure that many sysadmins would appreciate this possibility. There is a huge user base of grsec from hosting companies. Thanks for the support. I agree that this RBAC thing may be not interesting for everybody giving the fact that it duplicates some functionality (we already have SELinux and TOMOYO). So if you really feel so strong about removing this feature from the debian-grsec-kernel it can be easily done just by setting CONFIG_GRKERNSEC_NO_RBAC=y in the .config (there is no need to ask upstream to split the patch). This was mostly about upstreaming things, in fact. But disabling an option doesn't make the patch smaller. Anyway I think RBAC is a nice feature and it don't hurts: Its far easier to use than SElinux [1] and we already have in Debian the user-space tools to work with it: CC'ing Laszlo Boszormenyi (maintainer of linux-patch-grsecurity2, paxctl and gradm2) Note that linux-patch-grsecurity2 should really be removed now. I would like to see this moving forward, so I volunteer myself to help with the maintenance of this featureset. Thanks for that :) -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#605090: [grsec] update on featureset
On mar., 2011-10-11 at 16:52 +0200, Yves-Alexis Perez wrote: Ok so the tarball on the website isn't really convenient so, for now, I've put the quilt serie on a git repository on git.d.o: http://anonscm.debian.org/gitweb/?p=users/corsac/grsec-patches.git;a=summary Now upgraded to grsecurity 2.2.2-3.0.8-201110250925 against linux-2.6_3.0.0-6. Package (i386 and amd64) should be available on: deb http://molly.corsac.net/~corsac/debian/kernel-grsec/packages/ sid/ tonight. Could we move forward on this? Since I got not reply at all after this mail, I'm asking again. I know people are busy and I know this bug is not the easiest to handle, but I'd really like to move on. Since the RT featureset was added not that long ago, I guess the concept of featureset is still welcome. I know the situation is different, but still, I really think Debian users would appreciate a grsecurity featureset, which wouldn't harm other people kernels thanks to the alternate image. Regards, -- Yves-Alexis Perez ANSSI/ACE/LAM signature.asc Description: This is a digitally signed message part
Bug#605090: [grsec] update on featureset
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/11/2011 16:24, Ben Hutchings wrote: Every extra featureset that requires additional effort from the existing team members reduces the effort that can be spent on other tasks. Yes, I definitely understand that, and I really intend to provide enough help to minimize the burdain on existing team members which don't care about that featureset. Is the grsecurity patch getting bigger or smaller over time? It's a bit hard to tell. Putting aside the various security backports (mainly relevant for the 2.6.32 patch), the size seems to have decreased a little since 2.6.39 (and risen in the 3.0 serie). Feature-wise, Brad Sprengler and the PaX team still add stuff, like the gcc plugins or hardening features like symbols hiding, fix bugs (for example in RBAC code), while few of them reach mainline. Regards, - -- Yves-Alexis Perez ANSSI/ACE/LAM -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAEBCgAGBQJOu/91AAoJENcc3UqWxbaOkVAQAK5kcuOvmrASldaP0c/CpvXm AgQBfFLhPJjO8KxB/qDhdAcc4m9Kn7rYbmbFgHi5ujdHu99ccki1+wzZv12LFZkc VzNs12RQT8OboxQybfNcsRRgledwRGOCIefkKM91z05YSLBOmxNalpC//mcEqx+Y rSvoZ/+/X/ZFp7krKHULR2oeqJFohjBejnS3/6eLSQDN8HCvGi0QN/MF45X9O+aE vVhfzkDAV3LuyYXOi82Vi9y01W/7KtLbTGf8TEi7vh2XWwrdzHagnc/Lg28adxfu QaL/ufabLUY34fdB0R5AfSjKcpnyX4J/tpDEWeObtQTMQc/p/kb0yJXWBTAk3azI /PlF63OUxUhOh9wFASbYR5nZC+e8ToATA3XAYJ/nGoXKvC2vxD73DIk7jspgstS0 bVYLcuSQ4ZkxG2w3CmbgqdF0/92JTZ5PQEvL/0lM2lwYDFt4cZ4kY2xDK+7uo0uD 8j5Js51T0PPROhg0wKK3Zk5wxnReUj8sOnfB96GtCc8x05N5CCxr49pi6Zfdk6BM yO1tfvq75x9jfspzAv+mkhZDbfo47NcbKYLM+aZvJGKHavqCU0ejSOTCSNgsH8og cY8/tEhIMd3dSY4IXmj8eHl3gSVTkzwRDpRVpGxmicf3HGlfs2tMpLAtiRY4JS8I eOmxJ7Wbkpv5dstazq8y =eBwV -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/4ebbff75.1080...@ssi.gouv.fr