- 19 5月, 2015 2 次提交
-
-
由 Theodore Ts'o 提交于
Use struct ext4_encryption_key only for the master key passed via the kernel keyring. For internal kernel space users, we now use struct ext4_crypt_info. This will allow us to put information from the policy structure so we can cache it and avoid needing to constantly looking up the extended attribute. We will do this in a spearate patch. This patch is mostly mechnical to make it easier for patch review. Signed-off-by: NTheodore Ts'o <tytso@mit.edu> -
由 Theodore Ts'o 提交于
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
-
- 02 5月, 2015 1 次提交
-
-
由 Theodore Ts'o 提交于
This obscures the length of the filenames, to decrease the amount of information leakage. By default, we pad the filenames to the next 4 byte boundaries. This costs nothing, since the directory entries are aligned to 4 byte boundaries anyway. Filenames can also be padded to 8, 16, or 32 bytes, which will consume more directory space. Change-Id: Ibb7a0fb76d2c48e2061240a709358ff40b14f322 Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
-
- 16 4月, 2015 1 次提交
-
-
由 Theodore Ts'o 提交于
Signed-off-by: NUday Savagaonkar <savagaon@google.com> Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
-
- 12 4月, 2015 3 次提交
-
-
由 Michael Halcrow 提交于
Signed-off-by: NUday Savagaonkar <savagaon@google.com> Signed-off-by: NIldar Muslukhov <ildarm@google.com> Signed-off-by: NMichael Halcrow <mhalcrow@google.com> Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
-
由 Michael Halcrow 提交于
Signed-off-by: NMichael Halcrow <mhalcrow@google.com> Signed-off-by: NIldar Muslukhov <muslukhovi@gmail.com> Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
-
由 Michael Halcrow 提交于
On encrypt, we will re-assign the buffer_heads to point to a bounce page rather than the control_page (which is the original page to write that contains the plaintext). The block I/O occurs against the bounce page. On write completion, we re-assign the buffer_heads to the original plaintext page. On decrypt, we will attach a read completion callback to the bio struct. This read completion will decrypt the read contents in-place prior to setting the page up-to-date. The current encryption mode, AES-256-XTS, lacks cryptographic integrity. AES-256-GCM is in-plan, but we will need to devise a mechanism for handling the integrity data. Signed-off-by: NMichael Halcrow <mhalcrow@google.com> Signed-off-by: NIldar Muslukhov <ildarm@google.com> Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
-
- 11 4月, 2015 1 次提交
-
-
由 Michael Halcrow 提交于
Signed-off-by: NMichael Halcrow <mhalcrow@google.com> Signed-off-by: NTheodore Ts'o <tytso@mit.edu> Signed-off-by: NIldar Muslukhov <muslukhovi@gmail.com>
-