# [kernel] Feedback sur le hardened 3.7.0? Panic? (résolu)

## El_Goretto

Bonjour,

Je sais, c'est plutôt flou, mais en même temps, quand on a paramétré la boîte à tonnerre pour rebooter automatiquement au bout de 3 secs après un kernel panic, ça laisse peu de temps pour [prendre le metro/rentrer chez soi/brancher l'écran/lire l'affichage sur la console]  :Smile: 

Disons que je me suis mangé 2 kernel panic en moins d'une semaine sur la machine qui n'en a jamais connu sur un 3.5 hardened.

Je vais essayer de "bousculer" la machine pendant que je suis sur place (et avec un écran branché et un temps avant reboot un poil plus long ^^) mais je voulais savoir si certains utilisent cette quenelle qui est pourtant marquée "stable" et ont connu une ou 2 misères.

Comme je n'ai pas encore super l'habitude du matos qui englobe un peu trop de firmware à mon goût (radeon, bon, ok, celui du CPU, bon, soit, et enfin celui de la carte réseau tg3 (utile?)), je me demandais si j'avais pas merdouillé en ne mettant pas à jour le firmware dans /lib/firmware en même temps que booté sur le nouveau noyau, mais j'ai comme un doute car j'ai inclus les fichiers fw dans le noyau (en théorie, pour éviter un initrd).

```
Linux boner 3.7.0-hardened #7 SMP Mon Jan 7 11:24:54 CET 2013 x86_64 AMD Turion(tm) II Neo N40L Dual-Core Processor AuthenticAMD GNU/Linux
```

----------

## guilc

Aucun souchi ici.

Sans savoir d'où provient le KP, c'est un peu chercher une aiguille dans une botte de foin quand même  :Wink: 

----------

## El_Goretto

 *guilc wrote:*   

> Aucun souchi ici.
> 
> Sans savoir d'où provient le KP, c'est un peu chercher une aiguille dans une botte de foin quand même 

 

J'ai essayé Mme Irma, mais elle ne retourne jamais mes appels...   :Crying or Very sad: 

----------

## El_Goretto

Tiens, j'ai un processus qui a crashé sans emporter la quenelle, mais quand même:

```
[92913.102091] skbuff: skb_over_panic: text:ffffffff81595fd7 len:1568 put:608 head:ffff880027ca2800 data:ffff880027ca2900 tail:0x720 end:0x6c0 dev:<NULL>

[92913.104376] invalid opcode: 0000 [#1] SMP

[92913.105506] CPU 0

[92913.105530] Pid: 2380, comm: java Not tainted 3.7.0-hardened #7 HP ProLiant MicroServer

[92913.107803] RIP: 0010:[<ffffffff81529f55>]  [<ffffffff81529f55>] skb_put+0x95/0xa0

[92913.109011] RSP: 0018:ffff880070535b28  EFLAGS: 00010286

[92913.110206] RAX: 000000000000008a RBX: ffff880005fbb200 RCX: 0000000000000080

[92913.111428] RDX: 000000000000002c RSI: 0000000000000046 RDI: ffffffff81cb9f60

[92913.112660] RBP: ffff88003ad39a00 R08: 0000000000000000 R09: 0000000000000040

[92913.113915] R10: 8000000000000000 R11: 00000000000002e6 R12: 0000000000000260

[92913.115184] R13: 0000000000000420 R14: 0000000000007fe0 R15: 0000000000000260

[92913.116459] FS:  0000033e3c24f700(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000

[92913.117775] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b

[92913.119119] CR2: 0000033ea7c2b800 CR3: 0000000001668000 CR4: 00000000000007f0

[92913.120481] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

[92913.121850] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

[92913.123229] Process java (pid: 2380, threadinfo ffff880070661830, task ffff880070661440)

[92913.124654] Stack:

[92913.126098]  ffff880027ca2900 0000000000000720 00000000000006c0 ffffffff81818f77

[92913.127613]  0000000000000420 ffffffff81595fd7 ffff880074375d88 ffffffff810615db

[92913.129159]  0000000000000000 ffffffff8103e60d 0000000000000000 ffff880074375d80

[92913.130727] Call Trace:

[92913.132275]  [<ffffffff81595fd7>] ? tcp_sendmsg+0x827/0x14d0

[92913.133838]  [<ffffffff810615db>] ? __wake_up_common+0x5b/0x90

[92913.135405]  [<ffffffff8103e60d>] ? current_fs_time+0xd/0x50

[92913.136969]  [<ffffffff81115a12>] ? ep_send_events_proc+0xc2/0x160

[92913.138585]  [<ffffffff8151df82>] ? sock_aio_write+0x112/0x130

[92913.140166]  [<ffffffff81116323>] ? ep_scan_ready_list.clone.14+0x173/0x180

[92913.141771]  [<ffffffff810d449d>] ? do_sync_write+0x9d/0xe0

[92913.143384]  [<ffffffff810d468d>] ? vfs_write+0x1ad/0x200

[92913.145020]  [<ffffffff81659ebe>] ? sysret_check+0x1c/0x58

[92913.146652]  [<ffffffff810d47ed>] ? sys_write+0x5d/0xb0

[92913.148280]  [<ffffffff81659e98>] ? system_call_fastpath+0x18/0x1d

[92913.149916] Code: 00 00 48 89 44 24 10 8b 87 bc 00 00 00 48 89 44 24 08 48 8b 87 d0 00 00 00 48 c7 c7 58 0e 82 81 48 89 04 24 31 c0 e8 79 c5 12 00 <0f> 0b 66 0f 1f 84 00 00 00 00 00 41 55 89 f0 41 54 41 89 d4 55

[92913.153842] RIP  [<ffffffff81529f55>] skb_put+0x95/0xa0

[92913.155674]  RSP <ffff880070535b28>

[92913.163529] ---[ end trace c260c40e40c7f4a0 ]---

```

Une piste.

--

edit:

Dans les choses que j'avais noté en faisant le oldconfig:

*passage de powernow-k8 au driver acpi-cpufreq pour mon modèle de CPU

*des erreurs (à priori cosmétique?) en rapport avec la détection de "trucs" sur les disques durs (failed to get Identify Device Data, Emask 0x1 et failed to enable AA (error_mask=0x1))

*une histoire de helpers CT pour iptables que j'ai du mal à bien saisir.

Bref, je vais approfondir de mon côté.

----------

## guilc

Et une autre piste :

http://comments.gmane.org/gmane.linux.gentoo.hardened/5833

----------

## El_Goretto

Vivi, j'ai viré la protection grsec/pax qui kernel panic quand un process crash en root, parce que bon, à un moment, j'ai eu un doute  :Smile: 

J'ai aussi vsftpd de potentiellement impliqué, donc le kernel panic est peut être en effet un simple effet de bord.

Je laisse tourner sur le 3.7.0 pour vérifier depuis déjà quelques jours.

Merci pour le pointeur.

----------

## nox23

Je pense qu'ils sortent la version hardened trop tôt -> 3.7.0 ils suivent les versions de grsec de trop près je trouve.

Ils devraient attendre le 3.7.9 pour sortir le paquet hardened-sources. Surtout que la plupart du temps ca sert sur des serveurs.

J'utilise la série 3.2, au moins c'est bien testé et les bugs doivent être moins nombreux. -> 3.2.35-hardened

----------

## El_Goretto

Bon, je n'ai pas réussi à reproduire le problème, je vote donc pour un process tournant sous root qui s'est vautré, provoquant un kernel panic "voulu" par Papax.

vsftpd étant en tête de liste des coupables (je ne l'avais pas utilisé depuis perpette), samba & co étant pas loin derrière.

--> "Résolu"

----------

## El_Goretto

Bon, je ferai un autre thread quand j'aurai dégrossi la piste actuelle, mais la version 3.7.0 n'a rien à voir avec le problème (problème reproduit avec la 3.5.4 "stable", et avec d'autres JVM dont la sun).

C'est toujours tcp_sendmsg qui est en tête de la stack trace (sur 6 crashes java/i2p) ,et surtout, 24h avant l'apparition du premier crash, j'avais modifié net.ipv4.tcp_mtu_probing de 0 à 1. Et skb pointe sur un problème définitivement dans la pile réseau.

Je cherche à confirmer, ensuite je cherche un test pour reproduire rapidement le problème, et ensuite... on verra si ça doit être du bugreport niveau upstream ou du hardened-sources.

----------

## El_Goretto

Hop, on se dirige doucement vers un bug kernel mainstream concernant net.ipv4.tcp_mtu_probing (reproduit sur un vanilla 3.7.5). En plus maintenant sur cette version, c'est écrit en toutes lettres kernel BUG :

```
Feb 12 19:37:53 boner kernel: [204637.696945] skbuff: skb_over_panic: text:ffffffff81501c64 len:1568 put:768 head:ffff8800283cf800 da

ta:ffff8800283cf9a0 tail:0

x7c0 end:0x6c0 dev:<NULL>

Feb 12 19:37:53 boner kernel: [204637.699154] ------------[ cut here ]------------

Feb 12 19:37:53 boner kernel: [204637.700263] kernel BUG at net/core/skbuff.c:127!

Feb 12 19:37:53 boner kernel: [204637.701365] invalid opcode: 0000 [#1] SMP

Feb 12 19:37:53 boner kernel: [204637.702487] CPU 0

Feb 12 19:37:53 boner kernel: [204637.702510] Pid: 2262, comm: java Not tainted 3.7.5 #1 HP ProLiant MicroServer

Feb 12 19:37:53 boner kernel: [204637.704767] RIP: 0010:[<ffffffff814b8563>]  [<ffffffff814b8563>] skb_put+0x93/0xa0

Feb 12 19:37:53 boner kernel: [204637.705950] RSP: 0018:ffff880067777c68  EFLAGS: 00010296

Feb 12 19:37:53 boner kernel: [204637.707130] RAX: 000000000000008a RBX: ffff8800282e3dc0 RCX: 0000000000000039

Feb 12 19:37:53 boner kernel: [204637.708336] RDX: 0000000000000011 RSI: 0000000000000046 RDI: ffffffff8189ae14

Feb 12 19:37:53 boner kernel: [204637.709564] RBP: ffff880056016180 R08: 0000000000000000 R09: 0000000000000000

Feb 12 19:37:53 boner kernel: [204637.710812] R10: 00000000000002e3 R11: 0000000000000001 R12: 000000000000ff80

Feb 12 19:37:53 boner kernel: [204637.712081] R13: 0000000000000300 R14: 0000000000000420 R15: 0000000000000000

Feb 12 19:37:53 boner kernel: [204637.713399] FS:  00007f75b2b9c700(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000

Feb 12 19:37:53 boner kernel: [204637.714713] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033

Feb 12 19:37:53 boner kernel: [204637.716043] CR2: 00007f75f53dcf50 CR3: 0000000078ca6000 CR4: 00000000000007f0

Feb 12 19:37:53 boner kernel: [204637.717397] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

Feb 12 19:37:53 boner kernel: [204637.718768] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

Feb 12 19:37:53 boner kernel: [204637.720157] Process java (pid: 2262, threadinfo ffff880067776000, task ffff88007b193d40)

Feb 12 19:37:53 boner kernel: [204637.721585] Stack:

Feb 12 19:37:53 boner kernel: [204637.723014]  ffff8800283cf9a0 00000000000007c0 00000000000006c0 ffffffff81759ff1

Feb 12 19:37:53 boner kernel: [204637.724530]  0000000000000420 ffffffff81501c64 0000000000000001 ffff8800674de230

Feb 12 19:37:53 boner kernel: [204637.726064]  0000000000000000 00000040810530df 00007f75d40cd000 0000008000000320

Feb 12 19:37:53 boner kernel: [204637.727627] Call Trace:

Feb 12 19:37:53 boner kernel: [204637.729164]  [<ffffffff81501c64>] ? tcp_sendmsg+0x584/0xd00

Feb 12 19:37:53 boner kernel: [204637.730714]  [<ffffffff810d8c52>] ? touch_atime+0x62/0x160

Feb 12 19:37:53 boner kernel: [204637.732256]  [<ffffffff814af4f3>] ? sock_aio_write+0x103/0x130

Feb 12 19:37:53 boner kernel: [204637.733816]  [<ffffffff810c10c4>] ? do_sync_write+0x94/0xd0

Feb 12 19:37:53 boner kernel: [204637.735369]  [<ffffffff810c1265>] ? vfs_write+0x165/0x180

Feb 12 19:37:53 boner kernel: [204637.736934]  [<ffffffff810c1370>] ? sys_write+0x50/0xa0

Feb 12 19:37:53 boner kernel: [204637.738484]  [<ffffffff815ba792>] ? system_call_fastpath+0x16/0x1b

Feb 12 19:37:53 boner kernel: [204637.740095] Code: 89 54 24 10 8b 97 b8 00 00 00 48 89 54 24 08 48 8b 97 c8 00 00 00 48 c7 c7 a0 da 75 81 48 89 14 24 48 8b 54 24 28 e8 8d a4 0f 00 <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 41 55 b9 ff ff ff ff 41

Feb 12 19:37:53 boner kernel: [204637.743898] RIP  [<ffffffff814b8563>] skb_put+0x93/0xa0

Feb 12 19:37:53 boner kernel: [204637.745693]  RSP <ffff880067777c68>

Feb 12 19:37:53 boner kernel: [204637.753149] ---[ end trace 8702808243995769 ]---

```

Je n'ai plus qu'à laisser tourner 3j sans l'option net.ipv4.tcp_mtu_probing sur un kernel 3.7.5 hardened pour prouver que le patchset hardened n'est pas en cause et que net.ipv4.tcp_mtu_probing est bien l'élément déterminant.

----------

## El_Goretto

Bon, de mon côté, ça semble à peu près clair, je peux reproduire le problème avec un vanilla 3.7.5, et ne plus avoir aucun problème avec un hardened 3.7.5 correspondant quand je mets la variable à 0.

Pour ceux qui seraient intéressés, le rapport de bug rempli auprès de gentoo, histoire de confirmer/trouver un test pour reproduire le problème.

----------

