Inconsistencies between direct and indirect I/O access of the read-only rootfs

Description

It is my understanding that reading a read-only partition in direct or indirect I/O should return the same data.
However, in measured stable-9, after altering the rootfs and remounting read-only, the results are different.

Test1:

Test2:

Test1 results:
Hashes always identical on stable-8
Hashes always identical on un-measured stable-9
-> Except that one boot where they were always different!
Hashes always different on measured stable-9

Test2 results:
1000 times consistent with Test1, the behavior only changes across reboots

Theory:
Something bad happens in stable-9 during the "broken measurement" dialogs? (an obvious reason would be that it mounts the rootfs in read-write somewhere before the pivot or something)

Notes:

  • Important: when direct and indirect I/O disagree, direct seems to be right, since it survives reboots

  • The behavior is the same with or without a root password set

  • In the tests, the first `sha1sum` call can be replaced with a `dd | sha1sum` that doesn't specify "iflag=direct"

  • The direct vs indirect hashes are always the same after boot as long as the rootfs is not modified (`rw;ro`)

Environment

Dell laptops, regularly swapped:
E7470 with TPM 1.2 and NVMe drive
E7480 with TPM 2.0 and SATA drive

Legacy PXE install of OpenXT

stable-8 build $1908
stable-9 build $6536

Validation Steps

None

Activity

Show:
Jason Andryuk
May 2, 2019, 6:58 PM

I ran 500 iterations of an equivalent Test2, and all the hashes matched. Any idea how frequently you see a mismatch?

Jed
May 2, 2019, 7:00 PM

What I was trying to say is that in a given boot, it will either always match or always mismatch.

Jed
May 2, 2019, 7:01 PM

By always I mean consistently, but that word takes too long to type

Assignee

Unassigned

Reporter

Jed

Labels

None

QA Assignee

None

QA Image URL

None

Components

Fix versions

Affects versions

Priority

Major
Configure