Início / user-284577

sys463's questions

Martin Hope
sys463
Asked: 2018-06-08 04:38:17 +0800 CST
  • 1

Eu tenho "falha de alocação de página" relatada no meu sistema:

[some_app]: page allocation failure: order:4, mode:0x2040d0

Alguém poderia explicar o que exatamente esse modo significa? Estou certo que isso é para os seguintes sinalizadores GFP: GFP_NOTRACK | GFP_COMP | GFP_WAIT | GFP_IO | GFP_FS?

A versão do kernel é 3.10.0-693.21.1.el7.AV1.x86_64.

kernel memory
Martin Hope
sys463
Asked: 2018-06-01 04:11:13 +0800 CST
  • 1

A saída do lsofmeu RHEL7 mostra que um arquivo com descritor de arquivo memé usado por 40 processos. Isso significa que este arquivo é mapeado na memória 40 vezes ou o quê? Alguém poderia explicar o que significa arquivos mapeados em memória? Isso significa que 40 vezes na minha memória?

# lsof /usr/lib/locale/locale-archive
COMANDO PID USUÁRIO FD TIPO TAMANHO DO DISPOSITIVO/DESLIGADO NOME DO NÓ
vmtoolsd 605 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
agetty 656 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
sintonizado 963 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
iostat 1199 adm mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
chkMtaMem 1205 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
snmpd 4704 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
sleep 5461 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
cmsubagt 6487 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
sleep 6649 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc1 6803 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc2 6835 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc3 6836 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc4 6856 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc5 6884 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc6 6889 usr mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc7 6893 usr1 mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
cmfpagt 7704 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc8 7943 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
crond 8001 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
sh 8005 adm mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
iostat 8014 adm mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
crond 20427 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc9 20648 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc10 20649 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc10 20760 usr2 mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc9 20777 usr2 mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc11 21353 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc12 21354 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc13 21355 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc14 21356 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc15 21357 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc16 21358 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc17 21554 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc18 21569 usr2 mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc19 21590 usr2 mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc20 21647 usr2 mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc21 22016 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc22 22017 root mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc23 22104 usr2 mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
proc24 22122 usr2 mem REG 8,5 106070960 50808629 /usr/lib/locale/locale-archive
linux rhel
Martin Hope
sys463
Asked: 2018-05-26 07:02:02 +0800 CST
  • 2

Ocorreu um erro de "falha de alocação de página" em meu sistema RHEL7. Aqui está:

kernel: [85531.010995] sh: falha de alocação de página: ordem:4, modo:0x2040d0
kernel: [85531.011000] CPU: 1 PID: 20846 Comm: sh Não contaminado 3.10.0-693.el7.AV1.x86_64 #1
kernel: [85531.011002] Nome do hardware: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 21/09/2015
kernel: [85531.011003] 00000000002040d0 00000000d00413f4 ffff8800070ffa18 ffffffff816a3e1d
kernel: [85531.011006] ffff8800070ffaa8 ffffffff81188d00 0000000000000000 ffff88023ffd8000
kernel: [85531.011008] 0000000000000004 00000000002040d0 ffff8800070ffaa8 00000000d00413f4
kernel: [85531.011010] Rastreamento de chamada:
kernel: [85531.011018] [] dump_stack+0x19/0x1b
kernel: [85531.011023] [] warning_alloc_failed+0x110/0x180
kernel: [85531.011026] [] __alloc_pages_slowpath+0x6b6/0x724
kernel: [85531.011028] [] __alloc_pages_nodemask+0x405/0x420
kernel: [85531.011031] [] alloc_pages_current+0x98/0x110
kernel: [85531.011035] [] new_slab+0x2fc/0x310
kernel: [85531.011037] [] ___slab_alloc+0x3ac/0x4f0
kernel: [85531.011042] [] ? copy_process+0x18e/0x19a0
kernel: [85531.011044] [] ? copy_process+0x18e/0x19a0
kernel: [85531.011046] [] __slab_alloc+0x40/0x5c
kernel: [85531.011049] [] kmem_cache_alloc_node+0x8b/0x200
kernel: [85531.011051] [] copy_process+0x18e/0x19a0
kernel: [85531.011053] [] do_fork+0x91/0x320
kernel: [85531.011056] [] SyS_clone+0x16/0x20
kernel: [85531.011059] [] stub_clone+0x69/0x90
kernel: [85531.011061] [] ? system_call_fastpath+0x16/0x1b
kernel: [85531.011062] Mem-Info:
kernel: [85531.011066] anon_ativo:1145227 anon_inativo:278512 anon_isolado:0
kernel: [85531.011066] arquivo_ativo:181319 arquivo_inativo:185784 arquivo_isolado:0
kernel: [85531.011066] inevitável:2695 sujo:4333 writeback:0 instável:0
kernel: [85531.011066] slab_reclaimable:45889 slab_unreclaimable:54798
kernel: [85531.011066] mapeado:79471 shmem:52418 pagetables:11994 bounce:0
kernel: [85531.011066] grátis:33850 free_pcp:0 free_cma:0
kernel: [85531.011069] Nó 0 DMA livre:15868kB min:132kB baixo:164kB alto:196kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolado(anon):0kB isolado(arquivo):0kB presente:15992kB gerenciado:15908kB mlocked:0kB sujo:0kB writeback:0kB mapeado:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:8kB kernel_stack:0kB tabelas de paginação:0kB instável:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB páginas 0 all_unreclaimable? sim
kernel: [85531.011073] lowmem_reserve[]: 0 2809 7800 7800
kernel: [85531.011076] Nó 0 DMA32 Free: 53892kb min: 24292kb Low: 30364kb de altura: 36436kb ativo_anon: 1622080kb inactive_anon: 516652kb ativo_file: 2022084kb inactive_anon: 516652kb: managed:2878656kB mlocked:2312kB dirty:6236kB writeback:0kB mapped:115972kB shmem:79808kB slab_reclaimable:77740kB slab_unreclaimable:90500kB kernel_stack:13680kB pagetables:17624kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned: 0 all_unreclaimable? não
kernel: [85531.011080] lowmem_reserve[]: 0 0 4990 4990
kernel: [85531.011082] Nó 0 Normal livre:65640kB min:43152kB baixo:53940kB alto:64728kB active_anon:2958828kB inactive_anon:597396kB active_file:522032kB inactive_file:531032kB unevictable:8468kB isolado (anon) managed:5110372kB mlocked:8464kB dirty:11096kB writeback:0kB mapped:201912kB shmem:129864kB slab_reclaimable:105816kB slab_unreclaimable:128684kB kernel_stack:19936kB pagetables:30352kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned: 0 all_unreclaimable? não
kernel: [85531.011085] lowmem_reserve[]: 0 0 0 0
kernel: [85531.011087] Nó 0 DMA: 1*4kB (U) 1*8kB (U) 1*16kB (U) 1*32kB (U) 1*64kB (U) 1*128kB (U) 1*256kB (U) ) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15868kB
kernel: [85531.011095] Nó 0 DMA32: 2946*4kB (UEM) 1995*8kB (UEM) 1241*16kB (UEM) 186*32kB (UEM) 9*64kB (U) 0*128kB 0*256kB 0*512kB 0* 1024kB 0*2048kB 0*4096kB = 54128kB
kernel: [85531.011102] Nó 0 Normal: 16005*4kB (UEM) 248*8kB (UEM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 66004k
kernel: [85531.011108] Nó 0 enormepages_total=0 enormepages_free=0 enormepages_surp=0 enormepages_size=2048kB
kernel: [85531.011109] 428930 páginas totais de pagecache
kernel: [85531.011110] 8261 páginas no cache de troca
kernel: [85531.011111] Troque as estatísticas do cache: adicione 51264, exclua 43003, localize 2892763/2894481
kernel: [85531.011112] Troca livre = 5078128kB
kernel: [85531.011113] Troca total = 5242876kB
kernel: [85531.011114] 2097038 páginas RAM
kernel: [85531.011114] 0 páginas HighMem/MovableOnly
kernel: [85531.011115] 95804 páginas reservadas
kernel: [85531.011116] SLUB: Não é possível alocar memória no nó -1 (gfp=0xd0)
kernel: [85531.011118] cache: task_struct, tamanho do objeto: 45024, tamanho do buffer: 45024, ordem padrão: 4, ordem mínima: 4
kernel: [85531.011119] node 0: slabs: 2114, objs: 2114, free: 0

A pergunta é sobre a última seção de sua mensagem:

kernel: [85531.011116] SLUB: Não é possível alocar memória no nó -1 (gfp=0xd0)
kernel: [85531.011118] cache: task_struct, tamanho do objeto: 45024, tamanho do buffer: 45024, ordem padrão: 4, ordem mínima: 4
kernel: [85531.011119] node 0: slabs: 2114, objs: 2114, free: 0

Por que o índice do nó tem -1, quando a alocação falha na zona de Node 0? Isso é meio confuso..

kernel: [85531.011087] Nó 0 DMA: 1*4kB (U) 1*8kB (U) 1*16kB (U) 1*32kB (U) 1*64kB (U) 1*128kB (U) 1*256kB (U) ) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15868kB
kernel: [85531.011095] Nó 0 DMA32: 2946*4kB (UEM) 1995*8kB (UEM) 1241*16kB (UEM) 186*32kB (UEM) 9*64kB (U) 0*128kB 0*256kB 0*512kB 0* 1024kB 0*2048kB 0*4096kB = 54128kB
kernel: [85531.011102] Nó 0 Normal: 16005*4kB (UEM) 248*8kB (UEM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 66004k
linux rhel
Martin Hope
sys463
Asked: 2018-05-25 09:44:40 +0800 CST
  • 2

Existe uma maneira de rastrear as alocações de memória realizadas pelo kernel? Eu encontrei um artigo, onde as alocações de memória são rastreadas no log do kernel (eu acho). Aqui está como ele se parece:

[ 3830.215613] [HIGHERORDER_DEBUG] : __alloc_pages_nodemask is called by process <PID = 1168, NAME = Xorg> !!!

Talvez seja alguma compilação personalizada do kernel ...

Existe uma maneira de rastrear as alocações de memória dessa maneira? Talvez existam algumas ferramentas para isso? Estou usando o RHEL7.

rhel linux-kernel
Martin Hope
sys463
Asked: 2018-04-27 00:43:38 +0800 CST
  • 4

Eu tenho um aplicativo de servidor em funcionamento há muito tempo, que deve funcionar sem problemas por meses. Depois de mover um dispositivo para RHEL7, o sistema começou a sofrer fragmentação de memória após cerca de 2 a 3 dias de carga normal. Existem muitas mensagens de "falha de alocação de página" do kernel, indicando a incapacidade de alocar as 4 páginas de ordem na Zona Normal (enquanto há muitas páginas de ordem baixa) para quase cada processo. Aqui está um exemplo:

kernel: [85531.010995] sh: page allocation failure: order:4, mode:0x2040d0
kernel: [85531.011000] CPU: 1 PID: 20846 Comm: sh Not tainted 3.10.0-693.el7.AV1.x86_64 #1
kernel: [85531.011002] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/21/2015
kernel: [85531.011003]  00000000002040d0 00000000d00413f4 ffff8800070ffa18 ffffffff816a3e1d
kernel: [85531.011006]  ffff8800070ffaa8 ffffffff81188d00 0000000000000000 ffff88023ffd8000
kernel: [85531.011008]  0000000000000004 00000000002040d0 ffff8800070ffaa8 00000000d00413f4
kernel: [85531.011010] Call Trace:
kernel: [85531.011018]  [<ffffffff816a3e1d>] dump_stack+0x19/0x1b
kernel: [85531.011023]  [<ffffffff81188d00>] warn_alloc_failed+0x110/0x180
kernel: [85531.011026]  [<ffffffff8169fe1a>] __alloc_pages_slowpath+0x6b6/0x724
kernel: [85531.011028]  [<ffffffff8118d275>] __alloc_pages_nodemask+0x405/0x420
kernel: [85531.011031]  [<ffffffff811d15f8>] alloc_pages_current+0x98/0x110
kernel: [85531.011035]  [<ffffffff811dc36c>] new_slab+0x2fc/0x310
kernel: [85531.011037]  [<ffffffff811ddbfc>] ___slab_alloc+0x3ac/0x4f0
kernel: [85531.011042]  [<ffffffff810850be>] ? copy_process+0x18e/0x19a0
kernel: [85531.011044]  [<ffffffff810850be>] ? copy_process+0x18e/0x19a0
kernel: [85531.011046]  [<ffffffff816a117e>] __slab_alloc+0x40/0x5c
kernel: [85531.011049]  [<ffffffff811e00cb>] kmem_cache_alloc_node+0x8b/0x200
kernel: [85531.011051]  [<ffffffff810850be>] copy_process+0x18e/0x19a0
kernel: [85531.011053]  [<ffffffff81086a81>] do_fork+0x91/0x320
kernel: [85531.011056]  [<ffffffff81086d96>] SyS_clone+0x16/0x20
kernel: [85531.011059]  [<ffffffff816b5259>] stub_clone+0x69/0x90
kernel: [85531.011061]  [<ffffffff816b4f09>] ? system_call_fastpath+0x16/0x1b
kernel: [85531.011062] Mem-Info:
kernel: [85531.011066] active_anon:1145227 inactive_anon:278512 isolated_anon:0
kernel: [85531.011066]  active_file:181319 inactive_file:185784 isolated_file:0
kernel: [85531.011066]  unevictable:2695 dirty:4333 writeback:0 unstable:0
kernel: [85531.011066]  slab_reclaimable:45889 slab_unreclaimable:54798
kernel: [85531.011066]  mapped:79471 shmem:52418 pagetables:11994 bounce:0
kernel: [85531.011066]  free:33850 free_pcp:0 free_cma:0
kernel: [85531.011069] Node 0 DMA free:15868kB min:132kB low:164kB high:196kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:8kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
kernel: [85531.011073] lowmem_reserve[]: 0 2809 7800 7800
kernel: [85531.011076] Node 0 DMA32 free:53892kB min:24292kB low:30364kB high:36436kB active_anon:1622080kB inactive_anon:516652kB active_file:203244kB inactive_file:212104kB unevictable:2312kB isolated(anon):0kB isolated(file):0kB present:3129280kB managed:2878656kB mlocked:2312kB dirty:6236kB writeback:0kB mapped:115972kB shmem:79808kB slab_reclaimable:77740kB slab_unreclaimable:90500kB kernel_stack:13680kB pagetables:17624kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
kernel: [85531.011080] lowmem_reserve[]: 0 0 4990 4990
kernel: [85531.011082] Node 0 Normal free:65640kB min:43152kB low:53940kB high:64728kB active_anon:2958828kB inactive_anon:597396kB active_file:522032kB inactive_file:531032kB unevictable:8468kB isolated(anon):0kB isolated(file):0kB present:5242880kB managed:5110372kB mlocked:8464kB dirty:11096kB writeback:0kB mapped:201912kB shmem:129864kB slab_reclaimable:105816kB slab_unreclaimable:128684kB kernel_stack:19936kB pagetables:30352kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
kernel: [85531.011085] lowmem_reserve[]: 0 0 0 0
kernel: [85531.011087] Node 0 DMA: 1*4kB (U) 1*8kB (U) 1*16kB (U) 1*32kB (U) 1*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15868kB
kernel: [85531.011095] Node 0 DMA32: 2946*4kB (UEM) 1995*8kB (UEM) 1241*16kB (UEM) 186*32kB (UEM) 9*64kB (U) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 54128kB
kernel: [85531.011102] Node 0 Normal: 16005*4kB (UEM) 248*8kB (UEM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 66004kB
kernel: [85531.011108] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
kernel: [85531.011109] 428930 total pagecache pages
kernel: [85531.011110] 8261 pages in swap cache
kernel: [85531.011111] Swap cache stats: add 51264, delete 43003, find 2892763/2894481
kernel: [85531.011112] Free swap  = 5078128kB
kernel: [85531.011113] Total swap = 5242876kB
kernel: [85531.011114] 2097038 pages RAM
kernel: [85531.011114] 0 pages HighMem/MovableOnly
kernel: [85531.011115] 95804 pages reserved
kernel: [85531.011116] SLUB: Unable to allocate memory on node -1 (gfp=0xd0)
kernel: [85531.011118]   cache: task_struct, object size: 45024, buffer size: 45024, default order: 4, min order: 4
kernel: [85531.011119]   node 0: slabs: 2114, objs: 2114, free: 0

Assim, tenho algumas perguntas:

  1. O que pode afetar a fragmentação da memória no sistema?
  2. É possível determinar qual processo está causando a fragmentação (por exemplo, qual processo está usando mais de 4 páginas de pedidos)?
  3. E, claro, como posso ajustar o sistema para evitar a fragmentação da memória?

UPD:

  1. Descobri que essa CONFIG_COMPACTIONopção pode ajudar no meu caso, mas não consigo descobrir como ativá-la ou verificar seu estado atual. Então, como posso verificar/habilitar isso?

Tudo funcionou bem antes no RHEL6 e RHEL5.

# uname -a
Linux <hostname> 3.10.0-693.21.1.el7.AV1.x86_64 #1 SMP Thursday April 5, 2018 09:26:08 MDT x86_64 x86_64 x86_64 GNU/Linux

Essa é uma VM rodando no ESXi 6.5

UPD1: O sistema está sofrendo de falta de ordem 4 páginas novamente agora. A mensagem do kernel mostra que no momento da alocação havia páginas suficientes na zona DMA32, mas 0 na zona Normal.

[82794.805373] Node 0 DMA: 1*4kB (U) 0*8kB 1*16kB (U) 1*32kB (U) 1*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15860kB
[82794.805384] Node 0 DMA32: 4528*4kB (UEM) 2604*8kB (UEM) 1544*16kB (UEM) 142*32kB (UE) 19*64kB (EM) 3*128kB (U) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 69792kB
[82794.805393] Node 0 Normal: 17041*4kB (UEM) 183*8kB (UEM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 69628kB

É possível de alguma forma fazer o sistema alocar no DMA32? Não sou especialista nessa área, então qualquer informação é bem-vinda.

UPD2 Eu tentei jogar com parâmetros do kernel como vm.swappinesse vm.dirty_ratio, mas apenas adiou a ocorrência de falhas. Além disso, aumentar a quantidade de memória não ajudou.
UPD3 A eliminação dos caches do kernel echo 3 > /proc/sys/vm/drop_cachesajuda a evitar "falhas de alocação de página" por um tempo. Mas entendo que não é uma solução permanente, pois afeta o desempenho.

linux rhel
Martin Hope
sys463
Asked: 2018-04-07 08:05:23 +0800 CST
  • 1

Instalei a atualização de microcódigo Intel mais recente para usar a correção da variante #2 do Spectre, mas o verificador Spectre&Meltdown ainda mostra que o IBRS/IBPB não pode ser usado.

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
  * Kernel is compiled with IBRS/IBPB support:  YES
  * Currently enabled features
    * IBRS enabled for Kernel space:  NO
    * IBRS enabled for User space:  NO
    * IBPB enabled:  NO
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO
  * Kernel compiled with retpoline option:  NO
  * Kernel compiled with a retpoline-aware compiler:  NO
> STATUS:  VULNERABLE  (Your kernel is compiled with IBRS but your CPU microcode is lacking support to successfully mitigate the vulnerability)

dmesg mostra que a revisão mais recente está instalada.

# dmesg | grep microcode
[    1.199842] microcode: CPU0 sig=0x206d7, pf=0x1, revision=0x713
[    1.199860] microcode: CPU1 sig=0x206d7, pf=0x1, revision=0x713
[    1.199877] microcode: CPU2 sig=0x206d7, pf=0x1, revision=0x713
[    1.199898] microcode: CPU3 sig=0x206d7, pf=0x1, revision=0x713
[    1.199966] microcode: Microcode Update Driver: v2.01 <[email protected]>, Peter Oruba

A CPU é Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHze o tipo de host éESXi-5.1.0-20130402001-standard

cpu vmware
Martin Hope
sys463
Asked: 2018-04-06 07:40:44 +0800 CST
  • 2

Tentando atualizar o microcódigo Intel para a versão 03/12/2018 (versão: 20180312) com o seguinte procedimento:

1. extract files from downloaded tarball
2. cp -v intel-ucode/* /lib/firmware/intel-ucode/ 
3. echo 1 > /sys/devices/system/cpu/microcode/reload
4. dracut -vvf
5. reboot

mas nada muda. Antes da atualização:

# cat /proc/cpuinfo | grep microcode
microcode       : 0x13

Após a atualização:

# dmesg | grep microcode
[    1.096790] microcode: CPU0 sig=0x206c2, pf=0x1, revision=0x13
[    1.096829] microcode: CPU1 sig=0x206c2, pf=0x1, revision=0x13
[    1.096851] microcode: CPU2 sig=0x206c2, pf=0x1, revision=0x13
[    1.096875] microcode: CPU3 sig=0x206c2, pf=0x1, revision=0x13
[    1.096965] microcode: Microcode Update Driver: v2.01 <[email protected]>, Peter Oruba

Estou fazendo isso para corrigir 'Spectre variant 2'. O spectre-meltdown-checker.sh mostra o seguinte:

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
  * Kernel is compiled with IBRS/IBPB support:  YES
  * Currently enabled features
    * IBRS enabled for Kernel space:  NO
    * IBRS enabled for User space:  NO
    * IBPB enabled:  NO
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO
  * Kernel compiled with retpoline option:  NO
  * Kernel compiled with a retpoline-aware compiler:  NO
> STATUS:  VULNERABLE  (Your kernel is compiled with IBRS but your CPU microcode is lacking support to successfully mitigate the vulnerability)

A CPU é a seguinte: CPU Intel(R) Xeon(R) E5620 @ 2,40 GHz

linux linux-kernel