Hello,
That said, a dwarf based checker tool should be able to do as good a job
(maybe a bit better because report is very informative and it may pick up
compiler alignments or padding options).
So, Nicholas was kind enough to send me the two Linux Kernel binaries
that he built with the tiny li
On 12/01/2016 12:09 PM, Nicholas Piggin wrote:
On Thu, 1 Dec 2016 11:48:09 +0100
Stanislav Kozina wrote:
On 12/01/2016 05:13 AM, Don Zickus wrote:
...
I think GregKH pointed to one such tool, libabigail? We are working on
others too.
I should mention one of the others here:
https
Yeah it's great work, so is Stanislav's checker. I wouldn't mind having
a kernel-centric checker tool merged in the kernel if it is small,
maintained, and does a sufficient job for distros.
I'd be very happy to see the resulting tool in the kernel tree, as it
needs to be kept in sync with any
On 12/01/2016 05:13 AM, Don Zickus wrote:
...
I think GregKH pointed to one such tool, libabigail? We are working on
others too.
I should mention one of the others here:
https://github.com/skozina/kabi-dw
It's quite comparable to libabigail in the way it works, the main
differences are:
The question is how to provide a similar guarantee if a different way?
As a tool to aid distro reviewers, modversions has some value, but the
debug info parsing tools that have been mentioned in this thread seem
superior (not that I've tested them).
On the other hand the big advantage of modver
The question is how to provide a similar guarantee if a different way?
As a tool to aid distro reviewers, modversions has some value, but the
debug info parsing tools that have been mentioned in this thread seem
superior (not that I've tested them).
On the other hand the big advantage of modvers
A runtime check is still done, with per-module vermagic which distros
can change when they bump the ABI version. Is it really necessary to
have more than that (i.e., per-symbol versioning)?
From my point of view, it is. We need to allow changing ABI for some
modules while maintaining it for oth
Hello Borislav,
On Fri, 2018-01-26 at 15:49 +0100, Borislav Petkov wrote:
> On Fri, Jan 26, 2018 at 02:50:00PM +0100, Petr Oros wrote:
> > But what in production? Edit boot params, restart server, grep
> > /proc/cpuinfo and
> > restart again? Why i can not read it just from dmesg?
>
> Because you
> Now let's take a step back: you don't really need the previous revision
> in the spectre case! Not really.
I understand all your points.
We submitted the patch to ease debugging of microcode issues where the
systems impacted are not yet identified and thus can't be blacklisted.
Best Regards,
9 matches
Mail list logo
