Re: [pve-devel] [PATCH manager 9/9] report: add microcode info to better assess possible system impacts
On Mon, 2024-03-25 at 10:00 +0100, Thomas Lamprecht wrote:
> On 22/03/2024 14:59, Alexander Zeidler wrote:
> > * list availability and installation status of `*microcode` packages
> > * grep for applied "Early OS Microcode Updates"
> > * grep for (un)patched CPU vulnerability messages
> >
> > Signed-off-by: Alexander Zeidler
> > ---
> > PVE/Report.pm | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/PVE/Report.pm b/PVE/Report.pm
> > index fe497b43..18c554ec 100644
> > --- a/PVE/Report.pm
> > +++ b/PVE/Report.pm
> > @@ -108,6 +108,8 @@ my $init_report_cmds = sub {
> > 'dmidecode -t bios -q',
> > 'dmidecode -t memory | grep -E
> > "Capacity|Devices|Size|Manu|Part" | sed -Ez "s/\n\t(M|P)[^:]*:
> > (\S*)/\t\2/g" | sort',
> > 'lscpu',
> > + 'apt list *microcode 2>/dev/null | column -tL',
> > + 'dmesg | grep -i "microcode\|vuln"',
>
> I'm wondering if instead of having a handful of dmesg + grep instances
> it makes more sense to just add the whole dmesg output as separate
> file.
>
> I.e., I would like to have a cluster-wide report collection API that
> spawns a task, calls to all nodes to generate a report, saves all of
> those reports, including commands or files with very long output as
> separate files, and then assembles an archive with all that.
Great idea. The implementation of this seems not to be that trivial with
our current code base, so I plan to work on this in the near future.
And for a perhaps currently installed microcode package version, this
can be well included into the pveversion -v output. Whether it has been
applied at the current boot, will only later be visible in the dmesg file.
So this patch can be dropped.
>
> On the long run that would provide nicer UX and also avoid that some
> to strict filter hides information that might be relevant for a
> specific setup.
>
> I'd much more prefer work time spent on something like that than on
> adding the same command a few times with each having some different,
> rather a bit brittle looking, pipe chains..
>
> > 'lspci -nnk',
> > ],
> > },
>
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager 9/9] report: add microcode info to better assess possible system impacts
On 22/03/2024 14:59, Alexander Zeidler wrote:
> * list availability and installation status of `*microcode` packages
> * grep for applied "Early OS Microcode Updates"
> * grep for (un)patched CPU vulnerability messages
>
> Signed-off-by: Alexander Zeidler
> ---
> PVE/Report.pm | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/PVE/Report.pm b/PVE/Report.pm
> index fe497b43..18c554ec 100644
> --- a/PVE/Report.pm
> +++ b/PVE/Report.pm
> @@ -108,6 +108,8 @@ my $init_report_cmds = sub {
> 'dmidecode -t bios -q',
> 'dmidecode -t memory | grep -E
> "Capacity|Devices|Size|Manu|Part" | sed -Ez "s/\n\t(M|P)[^:]*: (\S*)/\t\2/g"
> | sort',
> 'lscpu',
> + 'apt list *microcode 2>/dev/null | column -tL',
> + 'dmesg | grep -i "microcode\|vuln"',
I'm wondering if instead of having a handful of dmesg + grep instances
it makes more sense to just add the whole dmesg output as separate
file.
I.e., I would like to have a cluster-wide report collection API that
spawns a task, calls to all nodes to generate a report, saves all of
those reports, including commands or files with very long output as
separate files, and then assembles an archive with all that.
On the long run that would provide nicer UX and also avoid that some
to strict filter hides information that might be relevant for a
specific setup.
I'd much more prefer work time spent on something like that than on
adding the same command a few times with each having some different,
rather a bit brittle looking, pipe chains..
> 'lspci -nnk',
> ],
> },
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager 9/9] report: add microcode info to better assess possible system impacts
On Fri, 2024-03-22 at 17:44 +0100, Stoiko Ivanov wrote:
> On Fri, 22 Mar 2024 14:59:33 +0100
> Alexander Zeidler wrote:
>
> > * list availability and installation status of `*microcode` packages
> > * grep for applied "Early OS Microcode Updates"
> > * grep for (un)patched CPU vulnerability messages
> >
> > Signed-off-by: Alexander Zeidler
> > ---
> > PVE/Report.pm | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/PVE/Report.pm b/PVE/Report.pm
> > index fe497b43..18c554ec 100644
> > --- a/PVE/Report.pm
> > +++ b/PVE/Report.pm
> > @@ -108,6 +108,8 @@ my $init_report_cmds = sub {
> > 'dmidecode -t bios -q',
> > 'dmidecode -t memory | grep -E
> > "Capacity|Devices|Size|Manu|Part" | sed -Ez "s/\n\t(M|P)[^:]*:
> > (\S*)/\t\2/g" | sort',
> > 'lscpu',
> > + 'apt list *microcode 2>/dev/null | column -tL',
> While `apt` works really well and its output hasn't changed since I
> started using it (wheezy or jessie) - I still want to mention it's output
> when piping:
> ```
> WARNING: apt does not have a stable CLI interface. Use with caution in
> scripts. ```
> potentially consider either using our code directly or switching to
> `dpkg -l`?
> (but as said `apt` has been pretty stable, and we simply dump the output -
> so probably the warning is not too relevant here)
Thank you! I have noticed the missing -a to list possible further package
versions for downgrading if needed. So `dpkg` and its verbose output would
not be an equal solution. However, since previous package versions can be
looked up in the Debian repo, the whole command may not be needed in the
first place.
Instead it may be better to include the current installed microcode version
in `pveversion` and use the
> > + 'dmesg | grep -i "microcode\|vuln"',
to see if microcode was loaded during this boot.
> > 'lspci -nnk',
> > ],
> > },
>
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH manager 9/9] report: add microcode info to better assess possible system impacts
On Fri, 22 Mar 2024 14:59:33 +0100
Alexander Zeidler wrote:
> * list availability and installation status of `*microcode` packages
> * grep for applied "Early OS Microcode Updates"
> * grep for (un)patched CPU vulnerability messages
>
> Signed-off-by: Alexander Zeidler
> ---
> PVE/Report.pm | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/PVE/Report.pm b/PVE/Report.pm
> index fe497b43..18c554ec 100644
> --- a/PVE/Report.pm
> +++ b/PVE/Report.pm
> @@ -108,6 +108,8 @@ my $init_report_cmds = sub {
> 'dmidecode -t bios -q',
> 'dmidecode -t memory | grep -E
> "Capacity|Devices|Size|Manu|Part" | sed -Ez "s/\n\t(M|P)[^:]*: (\S*)/\t\2/g"
> | sort',
> 'lscpu',
> + 'apt list *microcode 2>/dev/null | column -tL',
While `apt` works really well and its output hasn't changed since I
started using it (wheezy or jessie) - I still want to mention it's output
when piping:
```
WARNING: apt does not have a stable CLI interface. Use with caution in
scripts. ```
potentially consider either using our code directly or switching to
`dpkg -l`?
(but as said `apt` has been pretty stable, and we simply dump the output -
so probably the warning is not too relevant here)
> + 'dmesg | grep -i "microcode\|vuln"',
> 'lspci -nnk',
> ],
> },
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager 9/9] report: add microcode info to better assess possible system impacts
* list availability and installation status of `*microcode` packages
* grep for applied "Early OS Microcode Updates"
* grep for (un)patched CPU vulnerability messages
Signed-off-by: Alexander Zeidler
---
PVE/Report.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/PVE/Report.pm b/PVE/Report.pm
index fe497b43..18c554ec 100644
--- a/PVE/Report.pm
+++ b/PVE/Report.pm
@@ -108,6 +108,8 @@ my $init_report_cmds = sub {
'dmidecode -t bios -q',
'dmidecode -t memory | grep -E
"Capacity|Devices|Size|Manu|Part" | sed -Ez "s/\n\t(M|P)[^:]*: (\S*)/\t\2/g" |
sort',
'lscpu',
+ 'apt list *microcode 2>/dev/null | column -tL',
+ 'dmesg | grep -i "microcode\|vuln"',
'lspci -nnk',
],
},
--
2.39.2
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
