RFC Enable GCM support
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest3 patches 1 replyIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | eCryptfs: Add mount option for cipher modefs/ fs/ fs/ | +59 | 0 replies | |
| 2/3 | eCryptfs: Extend file headers to store cipher mode.fs/ fs/ fs/ +1 more | +208 | 0 replies | |
| 3/3 | Enable GCM support in eCryptfsfs/ fs/ fs/ +5 more | +319 | 1 reply |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC 0/3] Enable GCM support
This set of patches is the work we've done so far on adding integrity protection. We've been using a modified version of the test suite, available at
https://code.launchpad.net/~zmanji/ecryptfs/1270455/+merge/202197 to test GCM using the existing tests. This is done by passing -o "ecryptfs_cipher_mode=gcm" to the test script along with other flags.
When GCM mode is used, most of the test suite passes, but several tests involving truncating a file to a larger size fail. We believe this to be a result of calling read_mapping_page at mmap.c:49, which sometimes calls ecryptfs_readpage with a fresh page. This new page does not have a valid auth tag, so E_BADMSG is returned. We think this was fine before, as whatever was in the page would get overwritten and ignored, but now we're doing integrity checks, so we run into issues.
We'd like to know if there is an alternative to read_mapping_page that preserves the necessary semantics, or if there is some field in the page that gets passed to ecryptfs_readpage that would allow us to distinguish between pages we have never written to before and pages that were just fetched from the cache or disk.
-Will