Project

General

Profile

Bug #8172

Unsafe verdicts of multimodule verification aren't associated with marks for single module verification

Added by Alexey Polushkin almost 3 years ago. Updated almost 3 years ago.

Status:
New
Priority:
High
Category:
Bridge
Target version:
-
Start date:
04/26/2017
Due date:
% Done:

0%

Estimated time:
Detected in build:
svn
Platform:
Published in build:

Description

After multimodule verification, existed marks don't apply to unsafe results. The reason for this is other names of verification object (say, net/unix/unix.ko713c5ebc642b instead of net/unix/unix.ko).


Related issues

Related to Klever - Feature #8274: Support advanced attributes comparisonNew07/05/2017

Actions

History

#1

Updated by Evgeny Novikov almost 3 years ago

  • Subject changed from Unsafe verdicts of multimodule verification don't support extisted marks to Unsafe verdicts of multimodule verification aren't associated with marks for single module verification
  • Description updated (diff)
  • Assignee changed from Alexey Polushkin to Vladimir Gratinskiy
  • Priority changed from Normal to High

We have the dedicated developer of Bridge that can do all the best. In particular here I suggest to always remove last 12 symbols of verification objects if they exactly match pattern [0-9a-f] whenever verification objects are compared, i.e. during marks association and verification jobs comparison (here all verdicts produced for one module will be merged and experts should analyze corresponding difference manually). This isn't applied for any attribute values, just for verification objects.

#2

Updated by Vladimir Gratinskiy almost 3 years ago

Evgeny Novikov wrote:

We have the dedicated developer of Bridge that can do all the best. In particular here I suggest to always remove last 12 symbols of verification objects if they exactly match pattern [0-9a-f] whenever verification objects are compared, i.e. during marks association and verification jobs comparison (here all verdicts produced for one module will be merged and experts should analyze corresponding difference manually). This isn't applied for any attribute values, just for verification objects.

I will not do something with attributes during marks associations as for safes associations I don't compare attributes values (since feature_8147 branch), just its ids. For unsafes I'm going to do the same. So I can fix attributes during reports uploading, but I guess its wrong. Right?

#3

Updated by Evgeny Novikov almost 3 years ago

Vladimir Gratinskiy wrote:

Evgeny Novikov wrote:

We have the dedicated developer of Bridge that can do all the best. In particular here I suggest to always remove last 12 symbols of verification objects if they exactly match pattern [0-9a-f] whenever verification objects are compared, i.e. during marks association and verification jobs comparison (here all verdicts produced for one module will be merged and experts should analyze corresponding difference manually). This isn't applied for any attribute values, just for verification objects.

I will not do something with attributes during marks associations as for safes associations I don't compare attributes values (since feature_8147 branch), just its ids. For unsafes I'm going to do the same. So I can fix attributes during reports uploading, but I guess its wrong. Right?

Actually all attribute values should be remained as is since this is exactly what users expect to see. But here we encounter a new conception - there are attribute values for visualization and attribute values for comparison. So, I suggest the following. Let's instead of a field for attributes use two fields: the first one visualization attributes (they are exactly equal to report attributes) and the second one comparison attributes. You can fill both these fields when reports are uploaded using corresponding rules (I assume that in the most cases both fields will keep the same values). Then you should use an appropriate field when you, say, show report attributes or associate marks.

Since rules for translating visualization attributes into comparison ones can change there should be an ability to recalculate comparison attributes and everything related, e.g. mark associations. I am not sure that this will be very useful but I am sure that this will be quite hard, so this can be missed right now.

BTW, don't think that all rules will be like simple regular expressions. For instance, we already met many times situations when module was renamed in a newer version of the Linux kernel so straightforward comparison and mark associations fail. That's why one would like to specify by hand such the rule that although this module will be shown as mod-new.ko it will be compared and associated with marks as mod-old.ko. And so on. After all rules can become quite complicated.

Moreover, in accordance with a generic method suggested by me and Ilja in our paper Bridge should allow to configure various things like mentioned rules via interface rather than via changing its source files. But this is another story for which I will open a new issue.

Also available in: Atom PDF