CHROMIUM: verity: remove verify_mode

CHROMIUM: verity: remove verify_mode

We don't really use verify_mode any more. We used to use it when
dm_bht_compute called verify_path but that is no longer the case.

I'm sending this patch now because it makes the LOCALLY_VERIFIED state
patch I'm working on a little cleaner. So this is really work
leading up to that.

BUG=9752
TEST=Ran platform_DMVerityCorruption on H/W.

Change-Id: I4ef602f1b0a6c1c4a26927925dbe6d7abe75048c
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>;

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=8e3d642

[Will Drewry, 2011-03-10 18:56:59]

LGTM

A strong motivator for this code was being able to compare always re-verify
behavior to the normal case of verify to avoid regressions, but since we haven't
wired up the testing for that, I'd rather we get the new extra state transition
functional before we keep something in for testing we're not using.

~~

Do you really think the extra state is a good thing?  In a lot of ways, I'm
inclined to just reconsider making verify_path walk down from the root.  It
avoids the need for an extra state which avoids a need for extra atomic int
checks, etc. I guess I just worry the extra state adds complexity, but I haven't
had the chance to think it through well enough.  (Which leaves me inclined to go
with the original implementation model which I had done so for. :)

cheers!
will

[Paul T, 2011-03-10 19:09:40]

LGTM

[Mandeep Singh Baines, 2011-03-10 20:38:55]

wad@chromium.org (wad@chromium.org) wrote:
> LGTM
> 
> A strong motivator for this code was being able to compare always re-verify
> behavior to the normal case of verify to avoid regressions, but
> since we haven't
> wired up the testing for that, I'd rather we get the new extra state
> transition
> functional before we keep something in for testing we're not using.
> 
> ~~
> 
> Do you really think the extra state is a good thing?  In a lot of ways, I'm
> inclined to just reconsider making verify_path walk down from the root.  It
> avoids the need for an extra state which avoids a need for extra atomic int
> checks, etc. I guess I just worry the extra state adds complexity,
> but I haven't
> had the chance to think it through well enough.  (Which leaves me
> inclined to go
> with the original implementation model which I had done so for. :)
> 

I like going bottom up because you can short-circuit at any level. As soon
as you hit a VERIFIED node you're done. Harder to short-circuit top-down.

> cheers!
> will
> 
> http://codereview.chromium.org/6659037/

[Will Drewry, 2011-03-10 21:05:20]

On Thu, Mar 10, 2011 at 2:38 PM, Mandeep Singh Baines <msb@chromium.org> wrote:
> wad@chromium.org (wad@chromium.org) wrote:
>> LGTM
>>
>> A strong motivator for this code was being able to compare always re-verify
>> behavior to the normal case of verify to avoid regressions, but
>> since we haven't
>> wired up the testing for that, I'd rather we get the new extra state
>> transition
>> functional before we keep something in for testing we're not using.
>>
>> ~~
>>
>> Do you really think the extra state is a good thing?  In a lot of ways, I'm
>> inclined to just reconsider making verify_path walk down from the root.  It
>> avoids the need for an extra state which avoids a need for extra atomic int
>> checks, etc. I guess I just worry the extra state adds complexity,
>> but I haven't
>> had the chance to think it through well enough.  (Which leaves me
>> inclined to go
>> with the original implementation model which I had done so for. :)
>>
>
> I like going bottom up because you can short-circuit at any level. As soon
> as you hit a VERIFIED node you're done. Harder to short-circuit top-down.

The the difference is you can assert verify path is accurate using one
top-down traversal, then do short-circuits in check_block which avoids
ever calling verify_path at all then :)  As is, it sounds like an
extra traversal will be required to move from LOCAL_VERIFIED to
VERIFIED down a path (that or depth*traversals to slowly propagate
parent validity down the tree).  Either way - just want to make the
sure additional state is actually merited and not just a side effect
of the change to verify_path that we did without reconsidering the
ability to optimize.

thanks!
will