Check impure, opaque, origin & meta xattr with no sepolicy audit
(using __vfs_getxattr) since these operations are internal to
overlayfs operations and do not disclose any data. This became
an issue for credential override off since sys_admin would have
been required by the caller; whereas would have been inherently
present for the creator since it performed the mount.
This is a change in operations since we do not check in the new
ovl_do_vfs_getxattr function if the credential override is off or
not. Reasoning is that the sepolicy check is unnecessary overhead,
especially since the check can be expensive.
Because for override credentials off, this affects _everyone_ that
underneath performs private xattr calls without the appropriate
sepolicy permissions and sys_admin capability. Providing blanket
support for sys_admin would be bad for all possible callers.
For the override credentials on, this will affect only the mounter,
should it lack sepolicy permissions. Not considered a security
problem since mounting by definition has sys_admin capabilities,
but sepolicy contexts would still need to be crafted.
It should be noted that there is precedence, __vfs_getxattr is used
in other filesystems for their own internal trusted xattr management.
Signed-off-by: Mark Salyzyn <email address hidden>
Cc: Miklos Szeredi <email address hidden>
Cc: Jonathan Corbet <email address hidden>
Cc: Vivek Goyal <email address hidden>
Cc: Eric W. Biederman <email address hidden>
Cc: Amir Goldstein <email address hidden>
Cc: Randy Dunlap <email address hidden>
Cc: Stephen Smalley <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
v15 - revert to v13 as xattr_gs_args was rejected.
- move ovl_do_wrapper from util.c to inline in overlayfs.h
v14 - rebase to use xattr_gs_args.
v13 - rebase to use __vfs_getxattr flags option
v12 - rebase
v11 - switch name to ovl_do_vfs_getxattr, fortify comment
v10 - added to patch series
[Based on v15: https://lore.kernel.org/patchwork/patch/1148514/]
[<email address hidden>: Adjusted __vfs_getxattr() args and
removed XATTR_NOSECURITY]
Signed-off-by: Marcelo Henrique Cerri <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Seth Forshee <email address hidden>
Acked-by: Kamal Mostafa <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Kelsey Skunberg <email address hidden>
This option seems to introduce failures when resuming from hibernation
on Xen t2 instance types, especially those with a small amount of memory
(e.g., t2.nano and t2.small).
With this option enabled device drivers are allowed to use the
Contiguous Memory Allocator (CMA) for DMA operations. So, drivers can
allocate large physically-contiguous blocks of memory, instead of
relying on the I/O map or scatter-gather support.
However, on resume, the memory used by DMA needs to be re-initialized /
re-allocated, but it may fail to allocate large chunks of contiguous
memory due to the fact that we also need to restore the hibernation
image, using more memory and causing a system hang during the resume
process.
Such failures are more likely to happen in systems with a small amount
of memory (e.g., t2.nano and t2.small) that were showing a significant
higher rate of failures.
Make sure to disable this option for now on amd64 and re-align the
config and annotations file with the master kernel.
NOTE #1: this option has been disabled in the generic kernel because,
according to the associated bug link (LP: #1362261), it seemed to
introduce performance regressions on amd64, so there is no reason to do
differently in the aws kernel.
NOTE #2: this also disables the module 'etnaviv' (that is really not
needed in the aws kernel); update the modules list accordingly.
