Re: [pve-devel] [PATCH manager 9/9] report: add microcode info to better assess possible system impacts

[Alexander Zeidler <a.zeidler@proxmox.com>]

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 <a.zeidler@proxmox.com>
> > ---
> >  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',
> >  	    ],
> >  	},
>