Empty block contents #571
Open
Empty block contents #571
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The spec was silent on whether a just-created volume can read back garbage data left over in the storage from a previous use. There are likely applications that depend on a block volume reading as all zeroes. Empty filesystems are more likely to do what is desired (as mkfs is the most likely step to have happened during the creation), at which point the filesystem will not allow access to any uninitialized part of the underlying storage. But putting in an explicit statement that an empty block volume MUST read as zero is good for security reasons (one tenant cannot read the leftover garbage leftover by a previous tenant), even if it the Plugin has to take longer to actually ensure that scenario. More likely, Plugins can exploit hardware with efficient zeroing operations (for example, this is an extension in the SCSI spec but commonly available) or other techniques (any storage based by a filesystem has POSIX guarantees that the file started out reading as all zero; LVM technology has modes where it can guarantee that all allocations to a dynamcally sized LV starts life reading all zero). Even if we later add an optional mode to favor faster creation of block volumes without explicit zeroing, it should be a non-default opt-in setup (and only used by a CO that knows the block volume being allocated will only be used by software that doesn't read the uninitialized portions of the disk, such as when passing that block to mkfs). Signed-off-by: Eric Blake <eblake@redhat.com>
ebblake
force-pushed
the
empty-block-contents
branch
2 times, most recently
from
cc84eba
to
d07061a
Compare
Requiring a newly-created block to read as all zeroes is good security practice, but for some hardware, the time required to explicitly zero out the hardware can be lengthy. Enhance the spec with an option for a CO to request volume creation without regards to contents of the empty volume (safe if the volume will be handed to something that will in turn initialize it, such as mkfs, but risky if handed to something that will try to learn how the data was left by a previous tenant). Existing Plugins that ignore this field (and thereby always zero contents) are still compliant, but adding the field allows for some faster allocations, in a carefully controlled environment where the uninitialized storage is not setting up a data leak. Signed-off-by: Eric Blake <eblake@redhat.com>
ebblake
force-pushed
the
empty-block-contents
branch
from
d07061a
to
c72b656
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
Doc clarification, plus feature proposal
What this PR does / why we need it:
Clarify that by default, a Plugin MUST ensure that a newly-created volume reads as all zeroes, and additionally offer a way to allow Plugins to create volumes more quickly by skipping this guarantee.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
The first commit should be usable whether or not the community agrees with the proposal of the second.
Does this PR introduce an API-breaking change?:
NONE (the new option proposed in the second patch is backwards-compatible)