This feature flag indicates that the filesystem contains encrypted
files.
Signed-off-by: NRichard Weinberger <richard@nod.at>

This feature flag indicates that all directory entry nodes have a 32bit
cookie set and therefore UBIFS is allowed to perform lookups by hash.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Signed-off-by: NRichard Weinberger <richard@nod.at>

UBIFS stores a 32bit hash of every file, for traditional lookups by name
this scheme is fine since UBIFS can first try to find the file by the
hash of the filename and upon collisions it can walk through all entries
with the same hash and do a string compare.
When filesnames are encrypted fscrypto will ask the filesystem for a
unique cookie, based on this cookie the filesystem has to be able to
locate the target file again. With 32bit hashes this is impossible
because the chance for collisions is very high. Do deal with that we
store a 32bit cookie directly in the UBIFS directory entry node such
that we get a 64bit cookie (32bit from filename hash and the dent
cookie). For a lookup by hash UBIFS finds the entry by the first 32bit
and then compares the dent cookie. If it does not match, it has to do a
linear search of the whole directory and compares all dent cookies until
the correct entry is found.
Signed-off-by: NRichard Weinberger <richard@nod.at>

tnc_read_hashed_node() is a better name since we read a node
by a given hash, not a name.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Signed-off-by: NRichard Weinberger <richard@nod.at>

Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NDavid Gstir <david@sigma-star.at>
Signed-off-by: NRichard Weinberger <richard@nod.at>

As of now all filenames known by UBIFS are strings with a NUL
terminator. With encrypted filenames a filename can be any binary
string and the r5 function cannot search for the NUL terminator.
UBIFS always knows how long a filename is, therefore we can change
the hash function to iterate over the filename length to work
correctly with binary strings.
Signed-off-by: NRichard Weinberger <richard@nod.at>

With encrypted filenames we store raw binary data, doing
string tests is no longer possible.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NDavid Gstir <david@sigma-star.at>
Signed-off-by: NRichard Weinberger <richard@nod.at>

...and provide a non const variant for fscrypto
Signed-off-by: NRichard Weinberger <richard@nod.at>

When data of a data node is compressed and encrypted
we need to store the size of the compressed data because
before encryption we may have to add padding bytes.

For the new field we consume the last two padding bytes
in struct ubifs_data_node. Two bytes are fine because
the data length is at most 4096.
Signed-off-by: NRichard Weinberger <richard@nod.at>

We need this extra check in mmap because a process could
gain an already opened fd.
Signed-off-by: NRichard Weinberger <richard@nod.at>

When we're creating a new inode in UBIFS the inode is not
yet exposed and fscrypto calls ubifs_xattr_set() without
holding the inode mutex. This is okay but ubifs_xattr_set()
has to know about this.
Signed-off-by: NRichard Weinberger <richard@nod.at>

...and mark the dentry as encrypted.
Signed-off-by: NRichard Weinberger <richard@nod.at>

When a file is moved or linked into another directory
its current crypto policy has to be compatible with the
target policy.
Signed-off-by: NRichard Weinberger <richard@nod.at>

We need ->open() for files to load the crypto key.
If the no key is present and the file is encrypted,
refuse to open.
Signed-off-by: NRichard Weinberger <richard@nod.at>

We need the ->open() hook to load the crypto context
which is needed for all crypto operations within that
directory.
Signed-off-by: NRichard Weinberger <richard@nod.at>

We have to make sure that we don't expose our internal
crypto context to userspace.
Signed-off-by: NRichard Weinberger <richard@nod.at>

This is the first building block to provide file level
encryption on UBIFS.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Like ext4 UBIFS will store the crypto context in a xattr
attribute.
Signed-off-by: NRichard Weinberger <richard@nod.at>

For fscrypto we need this function outside of xattr.c.
Signed-off-by: NRichard Weinberger <richard@nod.at>

fscrypto will need this function too. Also get struct ubifs_info
from the provided inode. Not all callers will have a reference to
struct ubifs_info.
Signed-off-by: NRichard Weinberger <richard@nod.at>

'ubifs_fast_find_freeable()' can not return an error pointer, so this test
can be removed.
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NRichard Weinberger <richard@nod.at>

Right now wbuf timer has hardcoded timeouts and there is no place for
manual adjustments. Some projects / cases many need that though. Few
file systems allow doing that by respecting dirty_writeback_interval
that can be set using sysctl (dirty_writeback_centisecs).

Lowering dirty_writeback_interval could be some way of dealing with user
space apps lacking proper fsyncs. This is definitely *not* a perfect
solution but we don't have ideal (user space) world. There were already
advanced discussions on this matter, mostly when ext4 was introduced and
it wasn't behaving as ext3. Anyway, the final decision was to add some
hacks to the ext4, as trying to fix whole user space or adding new API
was pointless.

We can't (and shouldn't?) just follow ext4. We can't e.g. sync on close
as this would cause too many commits and flash wearing. On the other
hand we still should allow some trade-off between -o sync and default
wbuf timeout. Respecting dirty_writeback_interval should allow some sane
cutomizations if used warily.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

Values of these fields are set during init and never modified. They are
used (read) in a single function only. There isn't really any reason to
keep them in a struct. It only makes struct just a bit bigger without
any visible gain.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

... to better explain its purpose after introducing in-place encryption
without bounce buffer.
Signed-off-by: NDavid Gstir <david@sigma-star.at>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

Since fscrypt users can now indicated if fscrypt_encrypt_page() should
use a bounce page, we can delay the bounce page pool initialization util
it is really needed. That is until fscrypt_operations has no
FS_CFLG_OWN_PAGES flag set.
Signed-off-by: NDavid Gstir <david@sigma-star.at>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

Rename the FS_CFLG_INPLACE_ENCRYPTION flag to FS_CFLG_OWN_PAGES which,
when set, indicates that the fs uses pages under its own control as
opposed to writeback pages which require locking and a bounce buffer for
encryption.
Signed-off-by: NDavid Gstir <david@sigma-star.at>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

- Improve documentation
- Add BUG_ON(len == 0) to avoid accidental switch of offs and len
parameters
- Improve variable names for readability
Signed-off-by: NDavid Gstir <david@sigma-star.at>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

In case of in-place encryption fscrypt_ctx was allocated but never
released. Since we don't need it for in-place encryption, we skip
allocating it.

Fixes: 1c7dcf69 ("fscrypt: Add in-place encryption mode")
Signed-off-by: NDavid Gstir <david@sigma-star.at>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

Actually use the fs-provided index instead of always using page->index
which is only set for page-cache pages.

Fixes: 9c4bb8a3 ("fscrypt: Let fs select encryption index/tweak")
Signed-off-by: NDavid Gstir <david@sigma-star.at>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

These constants are part of the UAPI, so they belong in
include/uapi/linux/fs.h instead of include/linux/fscrypto.h
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Reviewed-by: NEric Biggers <ebiggers@google.com>

Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Reviewed-by: NEric Biggers <ebiggers@google.com>

The fscrypt_initalize() function isn't used outside fs/crypto, so
there's no point making it be an exported symbol.
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Reviewed-by: NEric Biggers <ebiggers@google.com>

To avoid namespace collisions, rename get_crypt_info() to
fscrypt_get_crypt_info().  The function is only used inside the
fs/crypto directory, so declare it in the new header file,
fscrypt_private.h.
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Reviewed-by: NEric Biggers <ebiggers@google.com>

Multiple bugs were recently fixed in the "set encryption policy" ioctl.
To make it clear that fscrypt_process_policy() and fscrypt_get_policy()
implement ioctls and therefore their implementations must take standard
security and correctness precautions, rename them to
fscrypt_ioctl_set_policy() and fscrypt_ioctl_get_policy().  Make the
latter take in a struct file * to make it consistent with the former.
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

SHA256 and ENCRYPTED_KEYS are not needed.  CTR shouldn't be needed
either, but I left it for now because it was intentionally added by
commit 71dea01e ("ext4 crypto: require CONFIG_CRYPTO_CTR if ext4
encryption is enabled").  So it sounds like there may be a dependency
problem elsewhere, which I have not been able to identify specifically,
that must be solved before CTR can be removed.
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

The filesystem level encryption support, currently used by ext4 and f2fs
and proposed for ubifs, does not yet have a dedicated mailing list.
Since no mailing lists were specified in MAINTAINERS, get_maintainer.pl
only recommended to send patches directly to the maintainers and to
linux-kernel.  This patch adds linux-fsdevel as the preferred mailing
list for fscrypto patches for the time being.
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

With the new (in 4.9) option to use a virtually-mapped stack
(CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for
the scatterlist crypto API because they may not be directly mappable to
struct page.  get_crypt_info() was using a stack buffer to hold the
output from the encryption operation used to derive the per-file key.
Fix it by using a heap buffer.

This bug could most easily be observed in a CONFIG_DEBUG_SG kernel
because this allowed the BUG in sg_set_buf() to be triggered.

Cc: stable@vger.kernel.org
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>