Bug#999551: Support Landlock by default in Debian kernels

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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"

[Yves-Alexis Perez]

-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"

[Yves-Alexis Perez]

-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)

[Yves-Alexis Perez]

-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?

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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 ?

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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)

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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 (?)

[Yves-Alexis Perez]

-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 (?)

[Yves-Alexis Perez]

-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 (?)

[Yves-Alexis Perez]

-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 (?)

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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)

[Yves-Alexis Perez]

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)

[Yves-Alexis Perez]

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)

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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?

[Yves-Alexis Perez]

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?

[Yves-Alexis Perez]

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?

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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]

[Yves-Alexis Perez]

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 ?

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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"

[Yves-Alexis Perez]

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"

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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]

[Yves-Alexis Perez]

On Sun, 26 Nov 2017 11:02:04 +0100 Salvatore Bonaccorso 
wrote:
> 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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

On Fri, 19 Feb 2016 16:24:06 +0900 Norbert Preining  wrote:
> 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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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?

[Yves-Alexis Perez]

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?

[Yves-Alexis Perez]

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?

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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!

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

-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]

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

-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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

 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

[Yves-Alexis Perez]

(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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

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

[Yves-Alexis Perez]

-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