Read vhd verity footer #1008
Read vhd verity footer #1008
Conversation
anmaxvl
force-pushed
the
read-vhd-verity-footer
branch
from
b8852cf to
8c2754d
Compare
anmaxvl
force-pushed
the
read-vhd-verity-footer
branch
from
8c2754d to
f16bb86
Compare
|
Anything new here? |
anmaxvl
force-pushed
the
read-vhd-verity-footer
branch
from
f16bb86 to
020f812
Compare
anmaxvl
force-pushed
the
read-vhd-verity-footer
branch
from
020f812 to
bc7251a
Compare
| MountPath: uvmPath, | ||
| } | ||
| if v, iErr := readVeritySuperBlock(ctx, hostPath); iErr != nil { | ||
| log.G(ctx).WithError(err).WithField("hostPath", hostPath).Debug("unable to read dm-verity information from VHD") |
There was a problem hiding this comment.
this doesn't error out the call though right, so we'd still make a guest request? I thought the only time we wanted to silently continue was when we get a ErrSuperBlockReadFailure error
There was a problem hiding this comment.
skipping the error here ensures we always have a fallback to the original behavior. whether it's the way to go about is debatable of course. what do you think?
There was a problem hiding this comment.
so the idea is that if we fail to read the verity block then we just mount it as a normal vpmem device? But verity wouldn't be setup properly?
There was a problem hiding this comment.
yes, that's correct. we could also introduce something that will tell us to always enforce it, for example or vice-versa (i.e. ignore failure)
There was a problem hiding this comment.
I see, so we always try to use dm-verity if possible. I think that might be fine.
|
do we only want this for the default VPMem support? |
for now yes, I'll need to validate the other path, since we just merged it today 😄 |
|
Can you add the commit msg in the pr description? |
this builds on top of the dm-verity footer feature that has been previously added. changes to opengcs have already been made where the verity info (root hash, merkle tree etc) is expected to be appended to the ext4 data and this change enables passing in the actual verity information. If dm-verity footer read fails, fallback to the original behavior as if the footer wasn't present at all. Signed-off-by: Maksim An <[email protected]>
anmaxvl
force-pushed
the
read-vhd-verity-footer
branch
from
bc7251a to
9dc13eb
Compare
Related work items: microsoft#930, microsoft#962, microsoft#1004, microsoft#1008, microsoft#1039, microsoft#1045, microsoft#1046, microsoft#1047, microsoft#1052, microsoft#1053, microsoft#1054, microsoft#1057, microsoft#1058, microsoft#1060, microsoft#1061, microsoft#1063, microsoft#1064, microsoft#1068, microsoft#1069, microsoft#1070, microsoft#1071, microsoft#1074, microsoft#1078, microsoft#1079, microsoft#1081, microsoft#1082, microsoft#1083, microsoft#1084, microsoft#1088, microsoft#1090, microsoft#1091, microsoft#1093, microsoft#1094, microsoft#1096, microsoft#1098, microsoft#1099, microsoft#1102, microsoft#1103, microsoft#1105, microsoft#1106, microsoft#1108, microsoft#1109, microsoft#1115, microsoft#1116, microsoft#1122, microsoft#1123, microsoft#1126
3 participants
this builds on top of the dm-verity footer feature that
has been previously added. changes to opengcs have already been
made where the verity info (root hash, merkle tree etc) is expected
to be appended to the ext4 data and this change enables passing
in the actual verity information.
If dm-verity footer read fails, fallback to the original behavior as
if the footer wasn't present at all.
NOTE: Integration tests will be added in a separate PR, since there's a dependency on CRI/containerd