UBUNTU: SAUCE: seccomp: fix SECCOMP_USER_NOTIF_FLAG_CONTINUE test
BugLink: https://bugs.launchpad.net/bugs/1849281
The ifndef for SECCOMP_USER_NOTIF_FLAG_CONTINUE was placed under the
ifndef for the SECCOMP_FILTER_FLAG_NEW_LISTENER feature. This will not
work on systems that do support SECCOMP_FILTER_FLAG_NEW_LISTENER but do not
support SECCOMP_USER_NOTIF_FLAG_CONTINUE. So move the latter ifndef out of
the former ifndef's scope.
2019-10-20 11:14:01 make run_tests -C seccomp
make: Entering directory '/usr/src/perf_selftests-x86_64-rhel-7.6-0eebfed2954f152259cae0ad57b91d3ea92968e8/tools/testing/selftests/seccomp'
gcc -Wl,-no-as-needed -Wall seccomp_bpf.c -lpthread -o seccomp_bpf
seccomp_bpf.c: In function ‘user_notification_continue’:
seccomp_bpf.c:3562:15: error: ‘SECCOMP_USER_NOTIF_FLAG_CONTINUE’ undeclared (first use in this function)
resp.flags = SECCOMP_USER_NOTIF_FLAG_CONTINUE;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
seccomp_bpf.c:3562:15: note: each undeclared identifier is reported only once for each function it appears in
Makefile:12: recipe for target 'seccomp_bpf' failed
make: *** [seccomp_bpf] Error 1
make: Leaving directory '/usr/src/perf_selftests-x86_64-rhel-7.6-0eebfed2954f152259cae0ad57b91d3ea92968e8/tools/testing/selftests/seccomp'
Reported-by: kernel test robot <rong.a.chen@intel.com> Fixes: 0eebfed2954f ("seccomp: test SECCOMP_USER_NOTIF_FLAG_CONTINUE") Cc: linux-kselftest@vger.kernel.org Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Reviewed-by: Tycho Andersen <tycho@tycho.ws> Link: https://lore.kernel.org/r/20191021091055.4644-1-christian.brauner@ubuntu.com Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 2aa8d8d04ca29c3269154e1d48855e498be8882f
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git) Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Nobuto Murata [Tue, 22 Oct 2019 02:23:28 +0000 (11:23 +0900)]
UBUNTU: [Packaging] include iavf/i40evf in generic
BugLink: https://bugs.launchpad.net/bugs/1848481
Intel's VF drivers such as igbvf and ixgbevf are already available in
generic. It makes sense to add iavf/i40evf especially for SR-IOV enabled
clouds with Intel X710/XXV710/XL710.
Sasha Neftin [Thu, 17 Oct 2019 17:48:35 +0000 (01:48 +0800)]
UBUNTU: SAUCE: e1000e: Add support for Comet Lake
BugLink: https://bugs.launchpad.net/bugs/1848555
Add devices ID's for the next LOM generations that will be
available on the next Intel Client platform (Comet Lake)
This patch provides the initial support for these devices
UBUNTU: SAUCE: seccomp: test SECCOMP_USER_NOTIF_FLAG_CONTINUE
BugLink: https://bugs.launchpad.net/bugs/1847744
Test whether a syscall can be performed after having been intercepted by
the seccomp notifier. The test uses dup() and kcmp() since it allows us to
nicely test whether the dup() syscall actually succeeded by comparing whether
the fds refer to the same underlying struct file.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Will Drewry <wad@chromium.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Martin KaFai Lau <kafai@fb.com> Cc: Song Liu <songliubraving@fb.com> Cc: Yonghong Song <yhs@fb.com> Cc: Tycho Andersen <tycho@tycho.ws> CC: Tyler Hicks <tyhicks@canonical.com> Cc: stable@vger.kernel.org Cc: linux-kselftest@vger.kernel.org Cc: netdev@vger.kernel.org Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20190920083007.11475-4-christian.brauner@ubuntu.com Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 0eebfed2954f152259cae0ad57b91d3ea92968e8
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git) Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1847744
This allows the seccomp notifier to continue a syscall. A positive
discussion about this feature was triggered by a post to the
ksummit-discuss mailing list (cf. [3]) and took place during KSummit
(cf. [1]) and again at the containers/checkpoint-restore
micro-conference at Linux Plumbers.
Recently we landed seccomp support for SECCOMP_RET_USER_NOTIF (cf. [4])
which enables a process (watchee) to retrieve an fd for its seccomp
filter. This fd can then be handed to another (usually more privileged)
process (watcher). The watcher will then be able to receive seccomp
messages about the syscalls having been performed by the watchee.
This feature is heavily used in some userspace workloads. For example,
it is currently used to intercept mknod() syscalls in user namespaces
aka in containers.
The mknod() syscall can be easily filtered based on dev_t. This allows
us to only intercept a very specific subset of mknod() syscalls.
Furthermore, mknod() is not possible in user namespaces toto coelo and
so intercepting and denying syscalls that are not in the whitelist on
accident is not a big deal. The watchee won't notice a difference.
In contrast to mknod(), a lot of other syscall we intercept (e.g.
setxattr()) cannot be easily filtered like mknod() because they have
pointer arguments. Additionally, some of them might actually succeed in
user namespaces (e.g. setxattr() for all "user.*" xattrs). Since we
currently cannot tell seccomp to continue from a user notifier we are
stuck with performing all of the syscalls in lieu of the container. This
is a huge security liability since it is extremely difficult to
correctly assume all of the necessary privileges of the calling task
such that the syscall can be successfully emulated without escaping
other additional security restrictions (think missing CAP_MKNOD for
mknod(), or MS_NODEV on a filesystem etc.). This can be solved by
telling seccomp to resume the syscall.
One thing that came up in the discussion was the problem that another
thread could change the memory after userspace has decided to let the
syscall continue which is a well known TOCTOU with seccomp which is
present in other ways already.
The discussion showed that this feature is already very useful for any
syscall without pointer arguments. For any accidentally intercepted
non-pointer syscall it is safe to continue.
For syscalls with pointer arguments there is a race but for any cautious
userspace and the main usec cases the race doesn't matter. The notifier
is intended to be used in a scenario where a more privileged watcher
supervises the syscalls of lesser privileged watchee to allow it to get
around kernel-enforced limitations by performing the syscall for it
whenever deemed save by the watcher. Hence, if a user tricks the watcher
into allowing a syscall they will either get a deny based on
kernel-enforced restrictions later or they will have changed the
arguments in such a way that they manage to perform a syscall with
arguments that they would've been allowed to do anyway.
In general, it is good to point out again, that the notifier fd was not
intended to allow userspace to implement a security policy but rather to
work around kernel security mechanisms in cases where the watcher knows
that a given action is safe to perform.
/* References */
[1]: https://linuxplumbersconf.org/event/4/contributions/560
[2]: https://linuxplumbersconf.org/event/4/contributions/477
[3]: https://lore.kernel.org/r/20190719093538.dhyopljyr5ns33qx@brauner.io
[4]: commit 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
Co-developed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Reviewed-by: Tycho Andersen <tycho@tycho.ws> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Will Drewry <wad@chromium.org> CC: Tyler Hicks <tyhicks@canonical.com> Link: https://lore.kernel.org/r/20190920083007.11475-2-christian.brauner@ubuntu.com Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit fb3c5386b382d4097476ce9647260fc89b34afdb
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git) Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Kai Vehmanen [Wed, 9 Oct 2019 08:08:38 +0000 (16:08 +0800)]
UBUNTU: SAUCE: drm/i915: extend audio CDCLK>=2*BCLK constraint to more platforms
BugLink: https://bugs.launchpad.net/bugs/1847192
The CDCLK>=2*BCLK constraint applies to all generations since gen10.
Extend the constraint logic in audio get/put_power().
Kai Vehmanen [Wed, 9 Oct 2019 08:08:37 +0000 (16:08 +0800)]
UBUNTU: SAUCE: drm/i915: Fix audio power up sequence for gen10+ display
BugLink: https://bugs.launchpad.net/bugs/1847192
On platfroms with gen10+ display, driver must set the enable bit of
AUDIO_PIN_BUF_CTL register before transactions with the HDA controller
can proceed. Add setting this bit to the audio power up sequence.
Failing to do this resulted in errors during display audio codec probe,
and failures during resume from suspend.
Note: We may also need to disable the bit afterwards, but there are
still unresolved issues with that.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111214 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191003085531.30990-1-kai.vehmanen@linux.intel.com
(backported from commit 1580d3cdddbba4a5ef78a04a5289e32844e6af24
git://anongit.freedesktop.org/drm-intel) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1847118
When looking for a bit by number we make use of the cached result from the
preceding lookup to speed up operation. Firstly we check if the requested
pfn is within the cached zone and if not lookup the new zone. We then
check if the offset for that pfn falls within the existing cached node.
This happens regardless of whether the node is within the zone we are
now scanning. With certain memory layouts it is possible for this to
false trigger creating a temporary alias for the pfn to a different bit.
This leads the hibernation code to free memory which it was never allocated
with the expected fallout.
Ensure the zone we are scanning matches the cached zone before considering
the cached node.
Deep thanks go to Andrea for many, many, many hours of hacking and testing
that went into cornering this bug.
Reported-by: Andrea Righi <andrea.righi@canonical.com> Tested-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
John Johansen [Thu, 3 Oct 2019 19:14:35 +0000 (12:14 -0700)]
UBUNTU: SAUCE: apparmor: fix nnp subset test for unconfined
The subset test is not taking into account the unconfined exception
which will cause profile transitions in the stacked confinement
case to fail when no_new_privs is applied.
This fixes a regression introduced in the 4.17 kernel caused by the
reworking of domain transitions.
Fixes: 9fcf78cca1986 ("apparmor: update domain transitions that are subsets of confinement at nnp") BugLink: https://bugs.launchpad.net/bugs/1844186 Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: overlayfs: allow with shiftfs as underlay
BugLink: https://bugs.launchpad.net/bugs/1846272
In commit [1] we enabled overlayfs on top of shiftfs. This approach was
buggy since it let to a regression for some standard overlayfs workloads
(cf. [2]).
In our original approach in [1] Seth and I concluded that running
overlayfs on top of shiftfs was not possible because of the way
overlayfs is currently opening files. The fact that it did not pass down
the dentry of shiftfs but rather it's own caused shiftfs to be confused
since it stashes away necessary information in d_fsdata.
Our solution was to modify open_with_fake_path() to also take a dentry
as an argument, then change overlayfs to pass in the shiftfs dentry
which then would override the dentry in the passed in struct path in
open_with_fake_path().
However, this led to a regression for some standard overlayfs workloads
(cf. [2]).
After various discussions involving Seth and myself in Paris we
concluded the reason for the regression was that we effectively created
a struct path that was comprised of the vfsmount of the overlayfs dentry
and the dentry of shiftfs. This is obviously broken.
The fix is to a) not modify open_with_fake_path() and b) change
overlayfs to do what shiftfs is doing, namely correctly setup the struct
path such that vfsmount and dentry match and are both from shiftfs.
Note, that overlayfs already does this for the .open method for
directories. It just did not do it for the .open method for regular
files leading to this issue. The reason why this hasn't been a problem
for overlayfs so far is that it didn't allow running on top of
filesystems that make use of d_fsdata _implicitly_ by disallowing any
filesystem that is itself an overlay, or has revalidate methods for it's
dentries as those usually have d_fsdata set up. Any other filesystem
falling in this category would have suffered from the same problem.
Seth managed to trigger the regression with the following script:
#!/bin/bash
utils=(bash cat)
mkdir -p lower/proc upper work root
for util in ${utils[@]}; do
path="$(which $util)"
dir="$(dirname $path)"
mkdir -p "lower/$dir"
cp -v "$path" "lower/$path"
libs="$(ldd $path | egrep -o '(/usr)?/lib.*\.[0-9]')"
for lib in $libs; do
dir="$(dirname $lib)"
mkdir -p "lower/$dir"
cp -v "$lib" "lower/$lib"
done
done
Seth Forshee [Tue, 22 Oct 2019 18:30:07 +0000 (13:30 -0500)]
UBUNTU: [Config] Fix SOF Kconfig options
BugLink: https://bugs.launchpad.net/bugs/1848490
As reported on the above bug and elsewhere, some incorrect config
options have resulted in non-working sound for some laptops. In
eoan we're applying a more conservative set of config changes,
but for focal we'll apply the set of changes which was
recommended to us by one of the upstream Intel ASoC maintainers.
UBUNTU: [Packaging]: download virtualbox from sources
BugLink: https://bugs.launchpad.net/bugs/1848788
dkms packages are gone from the archive when new versions are uploaded.
dkms-build grab them from the existing sources on the builder, which will
work when the expected versions are present on any of the configured
sources.
virtualbox, however, right now, only grabs it from the main archive,
preventing builds when they have been superseded. Fix it by giving the
relative pool address instead of the absolute URL for the archive.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
In the first iteration, we implemented a kmem cache for struct
shiftfs_file_info which stashed away a struct path and the struct file
for the underlay. The path however was never used anywhere so the struct
shiftfs_file_info and therefore the whole kmem cache can go away.
Instead we move to the same model as overlayfs and just stash away the
struct file for the underlay in file->private_data of the shiftfs struct
file.
Addtionally, we split the .open method for files and directories.
Similar to overlayfs .open for regular files uses open_with_fake_path()
which ensures that it doesn't contribute to the open file count (since
this would mean we'd count double). The .open method for directories
however used dentry_open() which contributes to the open file count.
The basic logic for opening files is unchanged. The main point is to
ensure that a reference to the underlay's dentry is kept through struct
path.
Various bits and pieces of this were cooked up in discussions Seth and I
had in Paris.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Andrea Righi [Mon, 14 Oct 2019 16:47:35 +0000 (18:47 +0200)]
UBUNTU: [Config] amd64: ignore fbtft and all dependent modules
With commit 63f2b1677fba11c5bd02089f25c13421948905f5
("staging/fbtft: Depend on OF") some of the TFT LCD modules are now
depending on CONFIG_OF, but we don't have it enabled on amd64.
Do not compile these modules on amd64.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Seth Forshee [Fri, 11 Oct 2019 21:37:31 +0000 (16:37 -0500)]
UBUNTU: [Debian] Generate stub reconstruct for -rc kernels
We've been removing debian.foo/reconstruct for -rc kernels, but
then we've got to remember to add it back once we rebase to the
final kernel. This is error prone, so instead just stub it out.
projects / mirror_ubuntu-focal-kernel.git / log