• Re: Debian 12 - Messaggi dmesg

    From Alessandro Rubini@21:1/5 to All on Mon Jul 24 11:50:01 2023
    [ 0.208536] ** This system shows unhashed kernel memory addresses **

    Vuol dire che i messaggi del kernel mostrano gli indirizzi interni
    invece di una "hash" degli stessi (ma solo se il driver usa "%p" per
    stampare il puntatore, invece che le normali stringhe testuali.
    Per esempio in caso di oops o panic.

    [ 0.208536] ** via the console, logs, and other interfaces. This **

    Appunto, i messaggi.

    Questo quadratozzo di NOTICE sta in lib/vsprintf.c nei sorgenti del kernel,
    da cui vedo che dipende dal parametro "no_hash_pointers".

    Guardando /proc/cmdline si dovrebbe vedere la presenza di questa
    opzione, che si puo` togliere nella configurazione del boot loader.

    Io, che sono vecchio e rinco, non vedo 'sto gran problema di
    sicurezza, e da sviluppatore preferisco di gran lunga i numeri
    veri. Ma oggi non si possono minimizzare potenziali minacce senza
    sembrare rinco (appunto!) quindi forse andrebbe tolta l'opzione.

    Il dubbio che rimane e` perche` qualcuno ha messo quel parametro,
    che serve solo a chi fa debug sul kernel. Da me non c'e` :)

    Comunque tra ricerche in rete e/o "git blame" sui sorgenti, e` spiegato
    tutto.

    saluti
    /alessandro

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pinguino@21:1/5 to All on Mon Jul 24 11:30:01 2023
    Buongiorno Lista,
    Ho notato degli strani messaggi all'avvio.
    Cercando in rete ho trovato delle spiegazioni sul comando dmesg, per
    vedere quali sono i messaggi di warning e di errore più critici, da
    tenere d'occhio.

    Quindi per ora ho dato questo:
    dmesg --level=err,warn

    Il risultato è il seguente:
    0.208535] **********************************************************
    [ 0.208535] ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
    [ 0.208535] ** **
    [ 0.208536] ** This system shows unhashed kernel memory addresses **
    [ 0.208536] ** via the console, logs, and other interfaces. This **
    [ 0.208536] ** might reduce the security of your system. **
    [ 0.208537] ** **
    [ 0.208537] ** If you see this message and you are not debugging **
    [ 0.208537] ** the kernel, report this immediately to your system **
    [ 0.208537] ** administrator! **
    [ 0.208537] ** **
    [ 0.208538] ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
    [ 0.208538] **********************************************************
    [ 2.559237] pci 0000:00:00.2: can't derive routing for PCI INT A
    [ 2.559241] pci 0000:00:00.2: PCI INT A: not connected
    [ 4.908943] i8042: PNP: PS/2 controller doesn't have KBD irq; using
    default 1
    [ 5.340447] ACPI Warning: SystemIO range 0x0000000000000B00-0x0000000000000B08 conflicts with OpRegion 0x0000000000000B00-0x0000000000000B0F (\GSA1.SMBI) (20220331/utaddress-204)
    [ 5.379534] usb: port power management may be unreliable
    [ 6.779856] amdgpu 0000:08:00.0: amdgpu: PSP runtime database doesn't
    exist
    [ 6.779857] amdgpu 0000:08:00.0: amdgpu: PSP runtime database doesn't
    exist
    [ 7.649729] amdgpu: SRAT table not found
    [ 10.775983] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is
    disabled. Duplicate IMA measurements will not be recorded in the IMA log.
    [ 241.172646] show_signal: 10 callbacks suppressed

    Io per ora ho notato soltanto due anomalie :
    1) Quando cerco di uscire e spegnere il PC, a volte da errore di power-management, quindi non esce subito, ma dice di attendere qualche
    secondo in più.

    2) Quando faccio le copie di Backup sul disco esterno, con rsync,
    collegato alla porta USB, mi sembra che non tutti i files vengono copiati. Mentre se faccio le copie tra i dischi interni tutto funziona bene.

    Siccome non conosco bene il comando dmesg, ci sono altri parametri o
    altri comandi per verificare se il sistema funziona bene ?
    oppure ha delle anomalie nascoste.

    Grazie
    Saluti
    Claudio


    --
    https://www.linkedin.com/in/claudio-sandrone

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pinguino@21:1/5 to All on Tue Jul 25 11:10:01 2023
    Il 24/07/23 11:47, Alessandro Rubini ha scritto:
    [ 0.208536] ** This system shows unhashed kernel memory addresses **

    Vuol dire che i messaggi del kernel mostrano gli indirizzi interni
    invece di una "hash" degli stessi (ma solo se il driver usa "%p" per
    stampare il puntatore, invece che le normali stringhe testuali.
    Per esempio in caso di oops o panic.

    [ 0.208536] ** via the console, logs, and other interfaces. This **

    Appunto, i messaggi.

    Questo quadratozzo di NOTICE sta in lib/vsprintf.c nei sorgenti del kernel, da cui vedo che dipende dal parametro "no_hash_pointers".
    Buongiorno Lista,
    Qua ho trovato questo: https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html?highlight=boot%20parameter
    no_hash_pointers
    Force pointers printed to the console or
    buffers to be
    unhashed. By default, when a pointer is
    printed via %p
    format string, that pointer is "hashed", i.e.
    obscured
    by hashing the pointer value. This is a
    security feature
    that hides actual kernel addresses from
    unprivileged
    users, but it also makes debugging the kernel more
    difficult since unequal pointers can no longer be
    compared. However, if this command-line option is
    specified, then all normal pointers will have
    their true
    value printed. This option should only be
    specified when
    debugging the kernel. Please do not use on
    production
    kernels.

    Spiega cosa fa. Poi alla fine dice di non usarlo nei kernels di produzione.


    Guardando /proc/cmdline si dovrebbe vedere la presenza di questa
    opzione, che si puo` togliere nella configurazione del boot loader.
    In /boot/grub/grub.cfg non ho trovato quel parametro.
    Non so se lo devo aggiungere ?

    Io ho trovato questo nel mio /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 root=UUID=880d6880-906e-49a6-8e72-bef089ab837e ro kaslr pti=on
    slab_nomerge page_poison=1 slub_debug=FPZ nosmt

    Non c'è il parametro no_hash_pointers

    Grazie
    Saluti
    Claudio


    Io, che sono vecchio e rinco, non vedo 'sto gran problema di
    sicurezza, e da sviluppatore preferisco di gran lunga i numeri
    veri. Ma oggi non si possono minimizzare potenziali minacce senza
    sembrare rinco (appunto!) quindi forse andrebbe tolta l'opzione.

    Il dubbio che rimane e` perche` qualcuno ha messo quel parametro,
    che serve solo a chi fa debug sul kernel. Da me non c'e` :)

    Comunque tra ricerche in rete e/o "git blame" sui sorgenti, e` spiegato tutto.

    saluti
    /alessandro


    --
    https://www.linkedin.com/in/claudio-sandrone

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Davide Prina@21:1/5 to All on Sun Jul 30 11:10:01 2023
    pinguino ha scritto:

    Io ho trovato questo nel mio /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 root=UUID=880d6880-906e-49a6-8e72-bef089ab837e ro kaslr pti=on
    slab_nomerge page_poison=1 slub_debug=FPZ nosmt

    ma hai seguito qualche quida di hardening?
    Se hai fatto un'installazione standard non dovresti avere tutti quei parametri

    cercando in rete:

    1) kaslr
    kASLR is enabled by default in the Debian kernel since 4.7~rc7-1~exp1 (CONFIG_RANDOMIZE_BASE and CONFIG_RANDOMIZE_MEMORY) so there is no need to enable it with a specific kernel parameter.

    infatti se fai:
    $ grep "CONFIG_RANDOMIZE_BASE\|CONFIG_RANDOMIZE_MEMORY" /boot/config-$(uname -r)
    CONFIG_RANDOMIZE_BASE=y
    CONFIG_RANDOMIZE_MEMORY=y
    CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=$(Valore)

    quindi questo parametro è inutile poiché già abilitato di default

    2) pti=on

    enables kernel page-table isolation

    $ grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-$(uname -r) CONFIG_PAGE_TABLE_ISOLATION=y

    anche in questo caso il parametro è inutile perché già attivato

    3) slab_nomerge

    Disables the merging of slabs of similar sizes. Many times some obscure slab will
    be used in a vulnerable way, allowing an attacker to mess with it more or less arbitrarily. Most slabs are not usable even when exploited, so this isn't too big
    of a deal. Unfortunately the kernel will merge similar slabs to save a tiny bit of
    space, and if a vulnerable and useless slab is merged with a safe but useful slab,
    an attacker can leverage that aliasing to do far more harm than they could have otherwise. In effect, this reduces kernel attack surface area by isolating slabs
    from each other. The trade-off is a very slight increase in kernel memory utilization. slabinfo -a can be used to tell what the memory footprint increase would be on a given system.

    $ grep SLAB /boot/config-$(uname -r)
    # SLAB allocator options
    # CONFIG_SLAB is not set
    CONFIG_SLAB_MERGE_DEFAULT=y
    CONFIG_SLAB_FREELIST_RANDOM=y
    CONFIG_SLAB_FREELIST_HARDENED=y
    # end of SLAB allocator options

    questo, da quanto deduco, dovrebbe avere un effetto diverso da quanto previsto nel Linux di default Debian

    4) page_poison=1

    clear the page allocator to prevent use-after-free attacks

    $ grep CONFIG_PAGE_POISONING /boot/config-$(uname -r)
    CONFIG_PAGE_POISONING=y

    anche questo è inutile poiché già attivato

    5) slub_debug=FPZ

    Enables sanity checks (F) and redzoning (Z). Sanity checks are self-evident and come with a modest performance impact, but this is unlikely to be significant on
    an average Tails system. The checks are basic but are still useful both for security and as a debugging measure. Redzoning adds extra areas around slabs that
    detect when a slab is overwritten past its real size, which can help detect overflows. Its performance impact is negligible.

    An additional note: any time slub_debug= is put in the kernel command line, slab_nomerge is implied. But having slab_nomerge explicitely declared can help prevent regressions where disabling of debugging features is desired but re-enabling of merging is not.

    come indicato sopra questo dovrebbe far qualcosa di diverso, però non so se funziona dato che
    # CONFIG_SLAB is not set

    6) nosmt

    disables SMT

    questo, se ho interpretato correttamente, disabilita l'SMT (Simultaneous MultiThreading), ma fare questo ha forti impatti prestazionali.
    La sua disabilitazione permette di evitare che i bug hardware collegati ad esso possano essere sfruttati.



    Penso che questi parametri li hai abilitati in /etc/default/grub

    per saperne di più:
    $ man kernel-command-line

    https://www.kernel.org/doc/html/

    Io sconsiglio di applicare a caso qualcosa trovato su un articolo o su qualche guida generica, senza essersi informati per avere almeno un'idea generica di quello che si sta facendo e verificare se sulla propria Debian è già abilitato
    o meno e che effetti ha con il resto della configurazione in essere.

    Ciao
    Davide

    --
    La mia privacy non è affar tuo
    https://noyb.eu/it
    - You do not have my permission to use this email to train an AI -

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pinguino@21:1/5 to All on Mon Jul 31 12:20:01 2023
    Il 30/07/23 11:01, Davide Prina ha scritto:
    pinguino ha scritto:

    Io ho trovato questo nel mio /proc/cmdline
    BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64
    root=UUID=880d6880-906e-49a6-8e72-bef089ab837e ro kaslr pti=on
    slab_nomerge page_poison=1 slub_debug=FPZ nosmt

    ma hai seguito qualche quida di hardening?
    Se hai fatto un'installazione standard non dovresti avere tutti quei parametri
    Buongiorno Lista,
    Non ho seguito guide di hardening.
    Soltanto questa sulla sicurezza Debian. https://www.debian.org/doc/manuals/securing-debian-manual/,
    per Debian 12.

    Si, ho fatto una installazione standard. Ho scaricato il DVD dal sito ufficiale, ed ho fatto una installazione da zero. Non ho potuto fare un avanzamento di versione.
    I parametri che sono descritti qui sopra, non li ho inserito io. Erano
    già cosi come li ho trovati.

    cercando in rete:

    1) kaslr
    kASLR is enabled by default in the Debian kernel since 4.7~rc7-1~exp1 (CONFIG_RANDOMIZE_BASE and CONFIG_RANDOMIZE_MEMORY) so there is no need to enable it with a specific kernel parameter.

    infatti se fai:
    $ grep "CONFIG_RANDOMIZE_BASE\|CONFIG_RANDOMIZE_MEMORY" /boot/config-$(uname -r)
    CONFIG_RANDOMIZE_BASE=y
    CONFIG_RANDOMIZE_MEMORY=y
    CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=$(Valore)

    quindi questo parametro è inutile poiché già abilitato di default

    2) pti=on

    enables kernel page-table isolation

    $ grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-$(uname -r) CONFIG_PAGE_TABLE_ISOLATION=y

    anche in questo caso il parametro è inutile perché già attivato

    3) slab_nomerge

    Disables the merging of slabs of similar sizes. Many times some obscure slab will
    be used in a vulnerable way, allowing an attacker to mess with it more or less
    arbitrarily. Most slabs are not usable even when exploited, so this isn't too big
    of a deal. Unfortunately the kernel will merge similar slabs to save a tiny bit of
    space, and if a vulnerable and useless slab is merged with a safe but useful slab,
    an attacker can leverage that aliasing to do far more harm than they could have
    otherwise. In effect, this reduces kernel attack surface area by isolating slabs
    from each other. The trade-off is a very slight increase in kernel memory utilization. slabinfo -a can be used to tell what the memory footprint increase
    would be on a given system.

    $ grep SLAB /boot/config-$(uname -r)
    # SLAB allocator options
    # CONFIG_SLAB is not set
    CONFIG_SLAB_MERGE_DEFAULT=y
    CONFIG_SLAB_FREELIST_RANDOM=y
    CONFIG_SLAB_FREELIST_HARDENED=y
    # end of SLAB allocator options

    questo, da quanto deduco, dovrebbe avere un effetto diverso da quanto previsto
    nel Linux di default Debian

    4) page_poison=1

    clear the page allocator to prevent use-after-free attacks

    $ grep CONFIG_PAGE_POISONING /boot/config-$(uname -r)
    CONFIG_PAGE_POISONING=y

    anche questo è inutile poiché già attivato

    5) slub_debug=FPZ

    Enables sanity checks (F) and redzoning (Z). Sanity checks are self-evident and
    come with a modest performance impact, but this is unlikely to be significant on
    an average Tails system. The checks are basic but are still useful both for security and as a debugging measure. Redzoning adds extra areas around slabs that
    detect when a slab is overwritten past its real size, which can help detect overflows. Its performance impact is negligible.

    An additional note: any time slub_debug= is put in the kernel command line, slab_nomerge is implied. But having slab_nomerge explicitely declared can help
    prevent regressions where disabling of debugging features is desired but re-enabling of merging is not.

    come indicato sopra questo dovrebbe far qualcosa di diverso, però non so se funziona dato che
    # CONFIG_SLAB is not set

    6) nosmt

    disables SMT

    questo, se ho interpretato correttamente, disabilita l'SMT (Simultaneous MultiThreading), ma fare questo ha forti impatti prestazionali.
    La sua disabilitazione permette di evitare che i bug hardware collegati ad esso
    possano essere sfruttati.



    Penso che questi parametri li hai abilitati in /etc/default/grub
    In /etc/default/grub.d/01_hardening.cfg ho trovato questo : GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT kaslr pti=on slab_nomerge page_poison=1 slub_debug=FPZ nosmt"

    sembra che siano abilitati anche qui.

    In /etc/default/ non c'è il file grub , ma c'è grub.ucf-dist che non ha
    quei parametri.

    per saperne di più:
    $ man kernel-command-line

    https://www.kernel.org/doc/html/
    Ok. Lo leggo.

    Io sconsiglio di applicare a caso qualcosa trovato su un articolo o su qualche
    guida generica, senza essersi informati per avere almeno un'idea generica di quello che si sta facendo e verificare se sulla propria Debian è già abilitato
    o meno e che effetti ha con il resto della configurazione in essere.

    Ciao
    Davide

    Grazie
    Saluti
    Claudio

    --
    La mia privacy non è affar tuo
    https://noyb.eu/it
    - You do not have my permission to use this email to train an AI -


    --
    https://www.linkedin.com/in/claudio-sandrone

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Davide Prina@21:1/5 to All on Tue Aug 8 17:50:01 2023
    pinguino ha scritto:

    Non ho seguito guide di hardening.
    Soltanto questa sulla sicurezza Debian. https://www.debian.org/doc/manuals/securing-debian-manual/,
    per Debian 12.

    veramente quella guida è stata aggiornata l'ultima volta ad inizio 2017 https://www.debian.org/doc/manuals/securing-debian-manual/changelog_history.en.html

    e a quella data c'era Jessie (Debian 8) come stable https://wiki.debian.org/DebianReleases

    ho visto che anche altri facevano notare che le guide di sicurezza Debian
    sono ormai datate e non ci sono guide aggiornate

    Ciao
    Davide

    --
    La mia privacy non è affar tuo
    https://noyb.eu/it
    - You do not have my permission to use this email to train an AI -

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)