PCI: Disable VF decoding before pcibios_sriov_disable() updates resources
BugLink: http://bugs.launchpad.net/bugs/1715073
A struct resource represents the address space consumed by a device. We
should not modify that resource while the device is actively using the
address space. For VFs, pci_iov_update_resource() enforces this by
printing a warning and doing nothing if the VFE (VF Enable) and MSE (VF
Memory Space Enable) bits are set.
Previously, both sriov_enable() and sriov_disable() called the
pcibios_sriov_disable() arch hook, which may update the struct resource,
while VFE and MSE were enabled. This effectively dropped the resource
update pcibios_sriov_disable() intended to do.
Disable VF memory decoding before calling pcibios_sriov_disable().
Reported-by: Carol L Soto <clsoto@us.ibm.com> Tested-by: Carol L Soto <clsoto@us.ibm.com> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
[bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: shan.gavin@gmail.com Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org>
(cherry picked from linux-next commit 0fc690a7c3f7053613dcbab6a7613bb6586d8ee2) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: selftests/seccomp: Support glibc 2.26 siginfo_t.h
The 2.26 release of glibc changed how siginfo_t is defined, and the earlier
work-around to using the kernel definition are no longer needed. The old
way needs to stay around for a while, though.
Jacob Keller [Fri, 1 Sep 2017 20:43:08 +0000 (13:43 -0700)]
i40e: point wb_desc at the nvm_wb_desc during i40e_read_nvm_aq
BugLink: http://bugs.launchpad.net/bugs/1715578
When introducing the functions to read the NVM through the AdminQ, we
did not correctly mark the wb_desc.
Fixes: 7073f46e443e ("i40e: Add AQ commands for NVM Update for X722", 2015-06-05) Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 3c8f3e96af3a6799841761923d000566645f0942) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
i40e: avoid NVM acquire deadlock during NVM update
BugLink: http://bugs.launchpad.net/bugs/1715578
X722 devices use the AdminQ to access the NVM, and this requires taking
the AdminQ lock. Because of this, we lock the AdminQ during
i40e_read_nvm(), which is also called in places where the lock is
already held, such as the firmware update path which wants to lock once
and then unlock when finished after performing several tasks.
Although this should have only affected X722 devices, commit 96a39aed25e6 ("i40e: Acquire NVM lock before reads on all devices",
2016-12-02) added locking for all NVM reads, regardless of device
family.
This resulted in us accidentally causing NVM acquire timeouts on all
devices, causing failed firmware updates which left the eeprom in
a corrupt state.
Create unsafe non-locked variants of i40e_read_nvm_word and
i40e_read_nvm_buffer, __i40e_read_nvm_word and __i40e_read_nvm_buffer
respectively. These variants will not take the NVM lock and are expected
to only be called in places where the NVM lock is already held if
needed.
Since the only caller of i40e_read_nvm_buffer() was in such a path,
remove it entirely in favor of the unsafe version. If necessary we can
always add it back in the future.
Additionally, we now need to hold the NVM lock in i40e_validate_checksum
because the call to i40e_calc_nvm_checksum now assumes that the NVM lock
is held. We can further move the call to read I40E_SR_SW_CHECKSUM_WORD
up a bit so that we do not need to acquire the NVM lock twice.
This should resolve firmware updates and also fix potential raise that
could have caused the driver to report an invalid NVM checksum upon
driver load.
Reported-by: Stefan Assmann <sassmann@kpanic.de> Fixes: 96a39aed25e6 ("i40e: Acquire NVM lock before reads on all devices", 2016-12-02) Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 09f79fd49d94cda5837e9bfd0cb222232b3b6d9f) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1714571
Some POWER PMU event names have multiple/alternate event codes. These
alternate event codes were listed in the POWER9 JSON files for
reference.
But the perf tool does not seem to handle duplicates cleanly. 'perf
list' shows such duplicate events only once, but 'perf stat' ends up
counting the first event code twice, multiplexing if necessary and we
end up with double the event counts.
Remove the duplicate event codes from the JSON files for now.
Reported-by: Michael Petlan <mpetlan@redhat.com> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Anton Blanchard <anton@au1.ibm.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Link: http://lkml.kernel.org/r/20170830231506.GB20351@us.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
(cherry picked from commit 2a118e1bd22cad57318520d37e3a184b8846c6a2
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Config] Include vmd in storage-core-modules udeb
BugLink: http://bugs.launchpad.net/bugs/1703339
This is a secondary PCIe host bridge which may have NVMe devices
behind it. The module is needed in the installer to install to
these disks.
Note that while theoretically non-disk devices such as NICs could
be connected in a VMD domain, Intel says they do not support such
usage at this time. If supported in the future vmd should be
moved to the kernel-image udeb.
UBUNTU: SAUCE: powerpc/powernv: Clear LPCR[PECE1] via stop-api only for deep state offline
BugLink: http://bugs.launchpad.net/bugs/1715064
commit 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via
stop-api only on Hotplug") clears the PECE1 bit of the LPCR via
stop-api during CPU-Hotplug to prevent wakeup due to a decrementer on
an offlined CPU which is in a deep stop state.
In the case where the stop-api support is found to be lacking, the
commit 785a12afdb4a ("powerpc/powernv/idle: Disable LOSE_FULL_CONTEXT
states when stop-api fails") disables deep states that lose hypervisor
context. Thus in this case, the offlined CPU will be put to some
shallow idle state.
However, we currently unconditionally clear the PECE1 in LPCR via
stop-api during CPU-Hotplug even when deep states are disabled due to
stop-api failure.
Fix this by clearing PECE1 of LPCR via stop-api during CPU-Hotplug
*only* when the offlined CPU will be put to a deep state that loses
hypervisor context.
Fixes: commit 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via
stop-api only on Hotplug")
Reported-by: Pavithra Prakash <pavirampu@linux.vnet.ibm.com> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
(Applied from mailing list patch https://patchwork.ozlabs.org/patch/808233/) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
powerpc/powernv: Clear PECE1 in LPCR via stop-api only on Hotplug
BugLink: http://bugs.launchpad.net/bugs/1715064
Currently we use the stop-api provided by the firmware to program the
SLW engine to restore the values of hypervisor resources that get lost
on deeper idle states (such as winkle). Since the deep states were
only used for CPU-Hotplug on POWER8 systems, we would program the LPCR
to have the PECE1 bit since Hotplugged CPUs shouldn't be spuriously
woken up by decrementer.
On POWER9, some of the deep platform idle states such as stop4 can be
used in cpuidle as well. In this case, we want the CPU in stop4 to be
woken up by the decrementer when some timer on the CPU expires.
In this patch, we program the stop-api for LPCR with PECE1
bit cleared only when we are offlining the CPU and set it
back once the CPU is online.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 24be85a23d1fcdc72264a062a2e4ebaaea48feab linux-next) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
powerpc/powernv: Save/Restore additional SPRs for stop4 cpuidle
BugLink: http://bugs.launchpad.net/bugs/1715064
The stop4 idle state on POWER9 is a deep idle state which loses
hypervisor resources, but whose latency is low enough that it can be
exposed via cpuidle.
Until now, the deep idle states which lose hypervisor resources (eg:
winkle) were only exposed via CPU-Hotplug. Hence currently on wakeup
from such states, barring a few SPRs which need to be restored to
their older value, rest of the SPRS are reinitialized to their values
corresponding to that at boot time.
When stop4 is used in the context of cpuidle, we want these additional
SPRs to be restored to their older value, to ensure that the context
on the CPU coming back from idle is same as it was before going idle.
In this patch, we define a SPR save area in PACA (since we have used
up the volatile register space in the stack) and on POWER9, we restore
SPRN_PID, SPRN_LDBAR, SPRN_FSCR, SPRN_HFSCR, SPRN_MMCRA, SPRN_MMCR1,
SPRN_MMCR2 to the values they had before entering stop.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit e1c1cfed54326fd2b17c78f0c85092167fc0783b linux-next) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1714112
This causes a conflict with the sbridge module, the advice from
upstream is to disable the option until a fix is available.
The DAC access permissions for several apparmorfs files are wrong.
.access - needs to be writable by all tasks to perform queries
the others in the set only provide a read fn so should be read only.
With policy namespace virtualization all apparmor needs to control
the permission and visibility checks directly which means DAC
access has to be allowed for all user, group, and other.
BugLink: http://bugs.launchpad.net/bugs/1713103 Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Seth Forshee [Wed, 30 Aug 2017 13:14:06 +0000 (08:14 -0500)]
UBUNTU: SAUCE: selftests/powerpc: Disable some ptrace selftests
The ptrace-tm-vsx, ptrace-tm-spd-vsx, and ptrace-tm-spr tests
FTBFS with the gcc in artful due to inline asm which includes r2
in the clobber list. Disable these tests until a solution is
found.
On Denverton micro-server, the presence of the P2SB bridge PCI device is
enabled or disabled by the item 'RelaxSecConf' in BIOS setup menu. When
'RelaxSecConf' is enabled, the P2SB PCI device is present and the pnd2_edac
EDAC driver also uses it to get BAR. Hiding the P2SB PCI device caused the
pnd2_edac EDAC driver failed to get BAR then reported the above failure.
Therefor, store the presence state of P2SB PCI device before unhiding it
for reading BAR and restore the presence state after reading BAR.
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Reported-by: Yunying Sun <yunying.sun@intel.com> Tested-by: Yunying Sun <yunying.sun@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
(cherry picked from commit bfd4473b850c8cfaa1cdf56b8ef52fae4e8a6ee5
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
If it's hidden by some device driver (e.g. with the i801 I2C driver,
the commit
9424693035a5 ("i2c: i801: Create iTCO device on newer Intel PCHs")
unconditionally hid the P2SB PCI device wrongly) it will make the
pnd2_edac driver read out an invalid BAR value of 0xffffffff and then
fail on ioremap().
Therefore, store the presence state of P2SB PCI device before unhiding
it for reading BAR and restore the presence state after reading BAR.
Qiuxu Zhuo [Mon, 14 Aug 2017 15:48:13 +0000 (23:48 +0800)]
EDAC, pnd2: Mask off the lower four bits of a BAR
BugLink: http://bugs.launchpad.net/bugs/1709257
Bit[0] of BAR is always zero. Bit[2:1] and bit[3] of BAR contain the
information of 'type' and the 'prefetchable' accordingly. Therefore,
mask the lower four bits to retrieve the actual base address of a BAR.
Tony Luck [Thu, 3 Aug 2017 21:05:36 +0000 (14:05 -0700)]
EDAC, pnd2: Build in a minimal sideband driver for Apollo Lake
BugLink: http://bugs.launchpad.net/bugs/1709257
I've been waing a long time for the generic sideband driver to
appear. Patience has run out, so include the minimum here to
just read registers.
Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing
the syscall. At the implementation level, this action is identical to
the existing SECCOMP_RET_ALLOW action. However, it can be very useful when
initially developing a seccomp filter for an application. The developer
can set the default action to be SECCOMP_RET_LOG, maybe mark any
obviously needed syscalls with SECCOMP_RET_ALLOW, and then put the
application through its paces. A list of syscalls that triggered the
default action (SECCOMP_RET_LOG) can be easily gleaned from the logs and
that list can be used to build the syscall whitelist. Finally, the
developer can change the default action to the desired value.
This provides a more friendly experience than seeing the application get
killed, then updating the filter and rebuilding the app, seeing the
application get killed due to a different syscall, then updating the
filter and rebuilding the app, etc.
The functionality is similar to what's supported by the various LSMs.
SELinux has permissive mode, AppArmor has complain mode, SMACK has
bring-up mode, etc.
SECCOMP_RET_LOG is given a lower value than SECCOMP_RET_ALLOW as allow
while logging is slightly more restrictive than quietly allowing.
Unfortunately, the tests added for SECCOMP_RET_LOG are not capable of
inspecting the audit log to verify that the syscall was logged.
With this patch, the logic for deciding if an action will be logged is:
if action == RET_ALLOW:
do not log
else if action == RET_KILL && RET_KILL in actions_logged:
log
else if action == RET_LOG && RET_LOG in actions_logged:
log
else if filter-requests-logging && action in actions_logged:
log
else if audit_enabled && process-is-being-audited:
log
else:
do not log
Tyler Hicks [Fri, 11 Aug 2017 04:33:56 +0000 (04:33 +0000)]
seccomp: Filter flag to log all actions except SECCOMP_RET_ALLOW
Add a new filter flag, SECCOMP_FILTER_FLAG_LOG, that enables logging for
all actions except for SECCOMP_RET_ALLOW for the given filter.
SECCOMP_RET_KILL actions are always logged, when "kill" is in the
actions_logged sysctl, and SECCOMP_RET_ALLOW actions are never logged,
regardless of this flag.
This flag can be used to create noisy filters that result in all
non-allowed actions to be logged. A process may have one noisy filter,
which is loaded with this flag, as well as a quiet filter that's not
loaded with this flag. This allows for the actions in a set of filters
to be selectively conveyed to the admin.
Since a system could have a large number of allocated seccomp_filter
structs, struct packing was taken in consideration. On 64 bit x86, the
new log member takes up one byte of an existing four byte hole in the
struct. On 32 bit x86, the new log member creates a new four byte hole
(unavoidable) and consumes one of those bytes.
Unfortunately, the tests added for SECCOMP_FILTER_FLAG_LOG are not
capable of inspecting the audit log to verify that the actions taken in
the filter were logged.
With this patch, the logic for deciding if an action will be logged is:
if action == RET_ALLOW:
do not log
else if action == RET_KILL && RET_KILL in actions_logged:
log
else if filter-requests-logging && action in actions_logged:
log
else if audit_enabled && process-is-being-audited:
log
else:
do not log
Tyler Hicks [Fri, 11 Aug 2017 04:33:55 +0000 (04:33 +0000)]
seccomp: Selftest for detection of filter flag support
Userspace needs to be able to reliably detect the support of a filter
flag. A good way of doing that is by attempting to enter filter mode,
with the flag bit(s) in question set, and a NULL pointer for the args
parameter of seccomp(2). EFAULT indicates that the flag is valid and
EINVAL indicates that the flag is invalid.
This patch adds a selftest that can be used to test this method of
detection in userspace.
Tyler Hicks [Fri, 11 Aug 2017 04:33:54 +0000 (04:33 +0000)]
seccomp: Sysctl to configure actions that are allowed to be logged
Adminstrators can write to this sysctl to set the seccomp actions that
are allowed to be logged. Any actions not found in this sysctl will not
be logged.
For example, all SECCOMP_RET_KILL, SECCOMP_RET_TRAP, and
SECCOMP_RET_ERRNO actions would be loggable if "kill trap errno" were
written to the sysctl. SECCOMP_RET_TRACE actions would not be logged
since its string representation ("trace") wasn't present in the sysctl
value.
The path to the sysctl is:
/proc/sys/kernel/seccomp/actions_logged
The actions_avail sysctl can be read to discover the valid action names
that can be written to the actions_logged sysctl with the exception of
"allow". SECCOMP_RET_ALLOW actions cannot be configured for logging.
The default setting for the sysctl is to allow all actions to be logged
except SECCOMP_RET_ALLOW. While only SECCOMP_RET_KILL actions are
currently logged, an upcoming patch will allow applications to request
additional actions to be logged.
There's one important exception to this sysctl. If a task is
specifically being audited, meaning that an audit context has been
allocated for the task, seccomp will log all actions other than
SECCOMP_RET_ALLOW despite the value of actions_logged. This exception
preserves the existing auditing behavior of tasks with an allocated
audit context.
With this patch, the logic for deciding if an action will be logged is:
if action == RET_ALLOW:
do not log
else if action == RET_KILL && RET_KILL in actions_logged:
log
else if audit_enabled && task-is-being-audited:
log
else:
do not log
Tyler Hicks [Fri, 11 Aug 2017 04:33:53 +0000 (04:33 +0000)]
seccomp: Operation for checking if an action is available
Userspace code that needs to check if the kernel supports a given action
may not be able to use the /proc/sys/kernel/seccomp/actions_avail
sysctl. The process may be running in a sandbox and, therefore,
sufficient filesystem access may not be available. This patch adds an
operation to the seccomp(2) syscall that allows userspace code to ask
the kernel if a given action is available.
If the action is supported by the kernel, 0 is returned. If the action
is not supported by the kernel, -1 is returned with errno set to
-EOPNOTSUPP. If this check is attempted on a kernel that doesn't support
this new operation, -1 is returned with errno set to -EINVAL meaning
that userspace code will have the ability to differentiate between the
two error cases.
Tyler Hicks [Fri, 11 Aug 2017 04:33:52 +0000 (04:33 +0000)]
seccomp: Sysctl to display available actions
This patch creates a read-only sysctl containing an ordered list of
seccomp actions that the kernel supports. The ordering, from left to
right, is the lowest action value (kill) to the highest action value
(allow). Currently, a read of the sysctl file would return "kill trap
errno trace allow". The contents of this sysctl file can be useful for
userspace code as well as the system administrator.
The path to the sysctl is:
/proc/sys/kernel/seccomp/actions_avail
libseccomp and other userspace code can easily determine which actions
the current kernel supports. The set of actions supported by the current
kernel may be different than the set of action macros found in kernel
headers that were installed where the userspace code was built.
In addition, this sysctl will allow system administrators to know which
actions are supported by the kernel and make it easier to configure
exactly what seccomp logs through the audit subsystem. Support for this
level of logging configuration will come in a future patch.
Kees Cook [Wed, 2 Aug 2017 22:00:40 +0000 (15:00 -0700)]
seccomp: Provide matching filter for introspection
Both the upcoming logging improvements and changes to RET_KILL will need
to know which filter a given seccomp return value originated from. In
order to delay logic processing of result until after the seccomp loop,
this adds a single pointer assignment on matches. This will allow both
log and RET_KILL logic to work off the filter rather than doing more
expensive tests inside the time-critical run_filters loop.
Running tight cycles of getpid() with filters attached shows no measurable
difference in speed.
Seth Forshee [Fri, 25 Aug 2017 19:47:29 +0000 (14:47 -0500)]
UBUNTU: SAUCE: selftests/powerpc: Use snprintf to construct DSCR sysfs interface paths
BugLink: http://bugs.launchpad.net/bugs/1710904
Currently sprintf is used, and while paths should never exceed
the size of the buffer it is theoretically possible since
dirent.d_name is 256 bytes. As a result this trips
-Wformat-overflow, and since the test is built with -Wall -Werror
the causes the build to fail. Switch to using snprintf and skip
any paths which are too long for the filename buffer.
John Johansen [Wed, 16 Aug 2017 16:33:48 +0000 (09:33 -0700)]
apparmor: fix incorrect type assignment when freeing proxies
sparse reports
poisoning the proxy->label before freeing the struct is resulting in
a sparse build warning.
../security/apparmor/label.c:52:30: warning: incorrect type in assignment (different address spaces)
../security/apparmor/label.c:52:30: expected struct aa_label [noderef] <asn:4>*label
../security/apparmor/label.c:52:30: got struct aa_label *<noident>
fix with RCU_INIT_POINTER as this is one of those cases where
rcu_assign_pointer() is not needed.
Signed-off-by: John Johansen <john.johansen@canonical.com>
(cherry picked from commit 76e22e212a850bbd16cf49f9c586d4635507e0b5 linux-next) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
John Johansen [Wed, 16 Aug 2017 12:48:06 +0000 (05:48 -0700)]
apparmor: ensure unconfined profiles have dfas initialized
Generally unconfined has early bailout tests and does not need the
dfas initialized, however if an early bailout test is ever missed
it will result in an oops.
Be defensive and initialize the unconfined profile to have null dfas
(no permission) so if an early bailout test is missed we fail
closed (no perms granted) instead of oopsing.
Signed-off-by: John Johansen <john.johansen@canonical.com>
(cherry picked from commit 034ad2d248927722bdcd1aedb62634cdc2049113 linux-next) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
John Johansen [Wed, 16 Aug 2017 12:40:49 +0000 (05:40 -0700)]
apparmor: fix race condition in null profile creation
There is a race when null- profile is being created between the
initial lookup/creation of the profile and lock/addition of the
profile. This could result in multiple version of a profile being
added to the list which need to be removed/replaced.
Since these are learning profile their is no affect on mediation.
Signed-off-by: John Johansen <john.johansen@canonical.com>
(cherry picked from commit 3aa3de2a4fb8f33ec62b00998bc6b6c6850d41b1 linux-next) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
John Johansen [Wed, 19 Jul 2017 06:18:33 +0000 (23:18 -0700)]
apparmor: add base infastructure for socket mediation
Provide a basic mediation of sockets. This is not a full net mediation
but just whether a spcific family of socket can be used by an
application, along with setting up some basic infrastructure for
network mediation to follow.
the user space rule hav the basic form of
NETWORK RULE = [ QUALIFIERS ] 'network' [ DOMAIN ]
[ TYPE | PROTOCOL ]
John Johansen [Wed, 19 Jul 2017 06:37:18 +0000 (23:37 -0700)]
apparmor: make policy_unpack able to audit different info messages
Switch unpack auditing to using the generic name field in the audit
struct and make it so we can start adding new info messages about
why an unpack failed.
Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
(cherry picked from commit 1489d896c5649e9ce1b6000b4857f8baa7a6ab63 linux-next) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
John Johansen [Sun, 6 Aug 2017 12:39:08 +0000 (05:39 -0700)]
apparmor: add support for absolute root view based labels
With apparmor policy virtualization based on policy namespace View's
we don't generally want/need absolute root based views, however there
are cases like debugging and some secid based conversions where
using a root based view is important.
Signed-off-by: John Johansen <john.johansen@canonical.com> Acked-by: Seth Arnold <seth.arnold@canonical.com>
(cherry picked from commit eadfbf0898eda94cee0d982626aa24a3146db48b linux-next) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
John Johansen [Wed, 19 Jul 2017 06:04:47 +0000 (23:04 -0700)]
apparmor: add mount mediation
Add basic mount mediation. That allows controlling based on basic
mount parameters. It does not include special mount parameters for
apparmor, super block labeling, or any triggers for apparmor namespace
parameter modifications on pivot root.
default userspace policy rules have the form of
MOUNT RULE = ( MOUNT | REMOUNT | UMOUNT )
MOUNT = [ QUALIFIERS ] 'mount' [ MOUNT CONDITIONS ] [ SOURCE FILEGLOB ]
[ '->' MOUNTPOINT FILEGLOB ]
John Johansen [Wed, 19 Jul 2017 05:56:22 +0000 (22:56 -0700)]
apparmor: add the ability to mediate signals
Add signal mediation where the signal can be mediated based on the
signal, direction, or the label or the peer/target. The signal perms
are verified on a cross check to ensure policy consistency in the case
of incremental policy load/replacement.
The optimization of skipping the cross check when policy is guaranteed
to be consistent (single compile unit) remains to be done.
policy rules have the form of
SIGNAL_RULE = [ QUALIFIERS ] 'signal' [ SIGNAL ACCESS PERMISSIONS ]
[ SIGNAL SET ] [ SIGNAL PEER ]
SIGNAL ACCESS PERMISSIONS = SIGNAL ACCESS | SIGNAL ACCESS LIST
SIGNAL ACCESS LIST = '(' Comma or space separated list of SIGNAL
ACCESS ')'
Dan Carpenter [Thu, 13 Jul 2017 07:39:20 +0000 (10:39 +0300)]
apparmor: Fix an error code in aafs_create()
We accidentally forgot to set the error code on this path. It means we
return NULL instead of an error pointer. I looked through a bunch of
callers and I don't think it really causes a big issue, but the
documentation says we're supposed to return error pointers here.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
(cherry picked from commit aee58bf341db52a3a3563c6b972bfd4fc2d41e46 linux-next) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
verify_header() is currently checking whether interface version is less
than 5 *and* greater than 7, which always evaluates to false. Instead it
should check whether it is less than 5 *or* greater than 7.
Signed-off-by: Christos Gkekas <chris.gekas@gmail.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
(cherry picked from commit c54a2175e3a6bf6c697d249bba1aa729e06c7ba8 linux-next) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
apparmor: Fix shadowed local variable in unpack_trans_table()
with W=2:
security/apparmor/policy_unpack.c: In function ‘unpack_trans_table’:
security/apparmor/policy_unpack.c:469: warning: declaration of ‘pos’ shadows a previous local
security/apparmor/policy_unpack.c:451: warning: shadowed declaration is here
Rename the old "pos" to "saved_pos" to fix this.
Fixes: 5379a3312024a8be ("apparmor: support v7 transition format compatible with label_parse") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
(cherry picked from commit 966d631935a578fadb5770f17a957ee1a969d868 linux-next) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Packaging] sort ABI files with C.UTF-8 locale
BugLink: https://bugs.launchpad.net/bugs/1712345
Whenever we update the ABI files, the files may be sorted in a different
order, even though their contents are the same. That happens because the
system updating the ABI files may use a different locale than the one
that was used previously.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: igb: add support for using Broadcom 54616 as PHY
BugLink: https://launchpad.net/bugs/1712024
Ported from packages/base/any/kernels/3.18.25/patches/driver-support-intel-igb-bcm54616-phy.patch
in OpenNetworkLinux https://github.com/opencomputeproject/OpenNetworkLinux/
Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-By: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
- flush_tlb_mm() will flush the PWC which is unnecessary (for example
when doing a fork)
- A large unmap will call flush_tlb_pwc() multiple times causing us
to perform that fairly expensive operation repeatedly. This happens
often in batches of 3 on every new process.
So we change flush_tlb_mm() to only flush the TLB, and we use the
existing "need_flush_all" flag in struct mmu_gather to indicate
that the PWC needs flushing.
Unfortunately, flush_tlb_range() still needs to do a full flush
for now as it's used by the THP collapsing. We will fix that later.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit a46cc7a90fd8d95bfbb2b27080efe872a1a51db4) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1712168
Currently mod_verify_sig() calls verify_pkcs_7_signature() with
trusted_keys=NULL, which causes only the builtin keys to be used
to verify the signature. This breaks self-signing of modules with
a MOK, as the MOK is loaded into the secondary trusted keyring.
Fix this by passing the spacial value trusted_keys=(void *)1UL,
which tells verify_pkcs_7_signature() to use the secondary
keyring instead.
(cherry picked from commit cff4523d65b848f9c41c9e998a735ae2a820da2d
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git)
[ saf: Taken from fedora commit without authorship information or much
of a commit message; modified so that commit will describe the
problem being fixed. ] Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Seth Forshee [Thu, 17 Aug 2017 12:40:27 +0000 (07:40 -0500)]
UBUNTU: [Config] CONFIG_INTEL_ATOMISP=n
BugLink: http://bugs.launchpad.net/bugs/1711298
This is a staging driver which is causing a panic in xen pv
guests. The driver makes no sense for xen, but it can only be
configured as built-in and unconditionally registers a platform
device. Disable this driver until it is in better shape.
Now that we have separate JSON files for each topic in a CPU (eg: see
tools/perf/pmu-events/arch/powerpc/power8/*.json) the .json suffix in
the mapfile is misleading and redundant.
Reported-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Cc: Anton Blanchard <anton@au1.ibm.com> Cc: Jiri Olsa <jolsa@redhat.com> Link: http://lkml.kernel.org/r/20170802174617.GA32545@us.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
(cherry picked from commit 2862a16875452b697c65d8e06cc010c922d19171
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1700972
Allow images to be created without the need of an initrd and also allow
users to run without an initrd if they want to.
Seth Forshee [Thu, 10 Aug 2017 17:07:04 +0000 (12:07 -0500)]
UBUNTU: SAUCE: powerpc: Always initialize input array when calling epapr_hypercall()
Several callers to epapr_hypercall() pass an uninitialized stack
allocated array for the input arguments, presumably because they
have no input arguments. However this can produce errors like
this one
arch/powerpc/include/asm/epapr_hcalls.h:470:42: error: 'in' may be used uninitialized in this function [-Werror=maybe-uninitialized]
unsigned long register r3 asm("r3") = in[0];
~~^~~
Fix callers to this function to always zero-initialize the input
arguments array to prevent this.
Seth Forshee [Tue, 8 Aug 2017 19:26:51 +0000 (14:26 -0500)]
UBUNTU: SAUCE: aufs -- Add missing argument to loop_switch() call
The aufs patches add an argument to loop_switch(), but an
additional call to this function was added since the patches were
last updated. This causes a FTBFS:
drivers/block/loop.c: In function 'loop_flush':
drivers/block/loop.c:624:9: error: too few arguments to function 'loop_switch'
return loop_switch(lo, NULL);
^~~~~~~~~~~
drivers/block/loop.c:596:12: note: declared here
static int loop_switch(struct loop_device *lo, struct file *file,
^~~~~~~~~~~
This new call is meant only to induce a flush of queued bios and
does not use the file arguments at all, so just pass NULL.
Patrick Pedersen [Sat, 15 Jul 2017 12:27:21 +0000 (14:27 +0200)]
UBUNTU: SAUCE: (no-up) HID: Add quirk for Lenovo Yoga 910 with ITE Chips
BugLink: http://bugs.launchpad.net/bugs/1708120
As with previous generations of this device (see https://patchwork.kernel.org/patch/7887361/), the ITE
HID Sensor Hub, responsible for the accelerometer and als sensor, requires a quirk entry.
Without the entry, the Sensor Hub can't be accessed and the kernel fails to report any movements. As a result
iio-sensor-proxy receives no new data.
It shall additionally be noted that the i2c-hid 'sleep' bug (present since kernel ver. 4.3)
still affects the driver. This means that the sensor hub will not report any movement, until
the device is suspended and resumed.
Signed-off-by: Patrick Pedersen <ctx.xda@gmail.com> Signed-off-by: Chris MacNaughton <chris.macnaughton@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Seth Forshee [Wed, 2 Aug 2017 14:43:28 +0000 (09:43 -0500)]
UBUNTU: [Config] CONFIG_SATA_HIGHBANK=y
BugLink: http://bugs.launchpad.net/bugs/1703430
This changed from y to m after trusty without justification.
Having it built as a module causes issues with booting on some
ARM systems.
projects / mirror_ubuntu-artful-kernel.git / log