Enabling btusb autosuspend by default
by Hans de Goede
Hi all,
As mentioned before I'm working on trying to improve the OOTB
power-consumption of Fedora Workstation on laptops
(I need to create an F28 feature page for this).
On many laptops the btusb device is the only USB device not
having USB autosuspend enabled, this causes not only the btusb
device but also the USB controller to stay awake, together using
aprox. 0.4W of power. Modern ultrabooks idle around 6W
(at 50% screen brightness), 3.5W for Apollo Lake devices.
0.4W is a significant chunk of this (7 / 11%).
So I would like to enable btusb autosuspend by default, to
make this possible I've submitted the following kernel
patch upstream which has just been merged (queued for 4.16):
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next....
If it is ok with the Fedora kernel team I would like to add
this as a patch to the Fedora kernels for now and set
the new BT_HCIBTUSB_AUTOSUSPEND option to y. This is not
without a risk of regressions, so this is something for
rawhide/F28 only.
Regards,
Hans
6 years, 5 months
4.14 kernels, write error broken pipe
by Chris Murphy
When I 'dnf install' kernel, kernel-core, kernel-modules rpms, I'm getting this:
Transaction test succeeded.
Running transaction
Preparing :
Installing : kernelcore-4.14.0-1.fc28.x86_64
Running scriptlet: kernel-core-4.14.0-1.fc28.x86_64
Installing : kernel-modules-4.14.0-1.fc28.x86_64
Running scriptlet: kernel-modules-4.14.0-1.fc28.x86_64
Installing : kernel-4.14.0-1.fc28.x86_64
Running scriptlet: kernel-core-4.14.0-1.fc28.x86_64
^Tcat: write error: Broken pipe
Verifying : kernel-4.14.0-1.fc28.x86_64
Verifying : kernel-core-4.14.0-1.fc28.x86_64
Verifying : kernel-modules-4.14.0-1.fc28.x86_64
Installed:
kernel.x86_64 4.14.0-1.fc28
kernel-core.x86_64 4.14.0-1.fc28
kernel-modules.x86_64 4.14.0-1.fc28
Complete!
dnf -v isn't revealing so I'm wondering how to get more information
for filing a bug. It seems to be non-fatal but the message isn't much
to go on.
--
Chris Murphy
6 years, 5 months
Re: Backport new SELinux NNP/nosuid patch to resolve interactions
with systemd?
by Paul Moore
On Tue, Nov 7, 2017 at 3:06 AM, Lukas Vrabec <lvrabec(a)redhat.com> wrote:
> On 11/02/2017 03:25 PM, Paul Moore wrote:
>>
>> Hello all,
>>
>> The Fedora SELinux policy folks are having a bit of problem on F27
>> with kernel v4.13 and the latest systemd trend of enabling NNP for a
>> large number of services. We added some new SELinux functionality in
>> the upstream kernel (see the commit description for an excellent
>> explanation of the problem and solution) that should arrive with v4.14
>> but the policy folks are asking if we can backport the functionality
>> to F27's v4.13 builds. The single commit is pretty low risk and
>> should be an easy backport, any chance we can get it in the v4.13
>> builds?
>>
>
> Hi all,
>
> Do we have any update here? Fedora 27 users still facing this issue, e.g:
> https://bugzilla.redhat.com/show_bug.cgi?id=1503980
Hi Lukas,
Jeremy Cline replied a few days ago that the patch should be in the
v4.13.11 update, unfortunately he didn't CC you directly and I didn't
realize you were included in the reply, sorry about that. Archive
link below:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject....
--
paul moore
security @ redhat
6 years, 5 months
Backport new SELinux NNP/nosuid patch to resolve interactions with systemd?
by Paul Moore
Hello all,
The Fedora SELinux policy folks are having a bit of problem on F27
with kernel v4.13 and the latest systemd trend of enabling NNP for a
large number of services. We added some new SELinux functionality in
the upstream kernel (see the commit description for an excellent
explanation of the problem and solution) that should arrive with v4.14
but the policy folks are asking if we can backport the functionality
to F27's v4.13 builds. The single commit is pretty low risk and
should be an easy backport, any chance we can get it in the v4.13
builds?
commit af63f4193f9fbbbac50fc766417d74735afd87ef
Author: Stephen Smalley <sds(a)tycho.nsa.gov>
Date: Mon Jul 31 10:12:46 2017 -0400
selinux: Generalize support for NNP/nosuid SELinux domain transitions
As systemd ramps up enabling NNP (NoNewPrivileges) for system services,
it is increasingly breaking SELinux domain transitions for those services
and their descendants. systemd enables NNP not only for services whose
unit files explicitly specify NoNewPrivileges=yes but also for services
whose unit files specify any of the following options in combination with
running without CAP_SYS_ADMIN (e.g. specifying User= or a
CapabilityBoundingSet= without CAP_SYS_ADMIN): SystemCallFilter=,
SystemCallArchitectures=, RestrictAddressFamilies=, RestrictNamespaces=,
PrivateDevices=, ProtectKernelTunables=, ProtectKernelModules=,
MemoryDenyWriteExecute=, or RestrictRealtime= as per the systemd.exec(5)
man page.
The end result is bad for the security of both SELinux-disabled and
SELinux-enabled systems. Packagers have to turn off these
options in the unit files to preserve SELinux domain transitions. For
users who choose to disable SELinux, this means that they miss out on
at least having the systemd-supported protections. For users who keep
SELinux enabled, they may still be missing out on some protections
because it isn't necessarily guaranteed that the SELinux policy for
that service provides the same protections in all cases.
commit 7b0d0b40cd78 ("selinux: Permit bounded transitions under
NO_NEW_PRIVS or NOSUID.") allowed bounded transitions under NNP in
order to support limited usage for sandboxing programs. However,
defining typebounds for all of the affected service domains
is impractical to implement in policy, since typebounds requires us
to ensure that each domain is allowed everything all of its descendant
domains are allowed, and this has to be repeated for the entire chain
of domain transitions. There is no way to clone all allow rules from
descendants to their ancestors in policy currently, and doing so would
be undesirable even if it were practical, as it requires leaking
permissions to objects and operations into ancestor domains that could
weaken their own security in order to allow them to the descendants
(e.g. if a descendant requires execmem permission, then so do all of
its ancestors; if a descendant requires execute permission to a file,
then so do all of its ancestors; if a descendant requires read to a
symbolic link or temporary file, then so do all of its ancestors...).
SELinux domains are intentionally not hierarchical / bounded in this
manner normally, and making them so would undermine their protections
and least privilege.
We have long had a similar tension with SELinux transitions and nosuid
mounts, albeit not as severe. Users often have had to choose between
retaining nosuid on a mount and allowing SELinux domain transitions on
files within those mounts. This likewise leads to unfortunate tradeoffs
in security.
Decouple NNP/nosuid from SELinux transitions, so that we don't have to
make a choice between them. Introduce a nnp_nosuid_transition policy
capability that enables transitions under NNP/nosuid to be based on
a permission (nnp_transition for NNP; nosuid_transition for nosuid)
between the old and new contexts in addition to the current support
for bounded transitions. Domain transitions can then be allowed in
policy without requiring the parent to be a strict superset of all of
its children.
With this change, systemd unit files can be left unmodified from upstream.
SELinux-disabled and SELinux-enabled users will benefit from retaining any
of the systemd-provided protections. SELinux policy will only need to
be adapted to enable the new policy capability and to allow the
new permissions between domain pairs as appropriate.
NB: Allowing nnp_transition between two contexts opens up the potential
for the old context to subvert the new context by installing seccomp
filters before the execve. Allowing nosuid_transition between two
contexts opens up the potential for a context transition to occur on a
file from an untrusted filesystem (e.g. removable media or remote
filesystem). Use with care.
Signed-off-by: Stephen Smalley <sds(a)tycho.nsa.gov>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
--
paul moore
security @ redhat
6 years, 5 months
[PATCH f26] Add fix for potential mlxsw firmware incompatibility
by Ido Schimmel
In case the firmware shipped with the device is new, it is possible for
the mlxsw driver to fail during initialization.
The patch allows the driver to load with both new and old firmware
versions.
Signed-off-by: Ido Schimmel <idosch(a)mellanox.com>
---
Patch is against f26 branch since that's what I'm using. However, it's
relevant for f25 and f27 as well.
---
...g-Add-high-and-low-temperature-thresholds.patch | 71 ++++++++++++++++++++++
kernel.spec | 3 +
2 files changed, 74 insertions(+)
create mode 100644 0001-mlxsw-reg-Add-high-and-low-temperature-thresholds.patch
diff --git a/0001-mlxsw-reg-Add-high-and-low-temperature-thresholds.patch b/0001-mlxsw-reg-Add-high-and-low-temperature-thresholds.patch
new file mode 100644
index 00000000..8f1752d7
--- /dev/null
+++ b/0001-mlxsw-reg-Add-high-and-low-temperature-thresholds.patch
@@ -0,0 +1,71 @@
+From 62b0e9243fca257217ef72f383bd38ed5a542b5e Mon Sep 17 00:00:00 2001
+From: Ido Schimmel <idosch(a)mellanox.com>
+Date: Mon, 30 Oct 2017 10:51:18 +0100
+Subject: [PATCH] mlxsw: reg: Add high and low temperature thresholds
+
+The ASIC has the ability to generate events whenever a sensor indicates
+the temperature goes above or below its high or low thresholds,
+respectively.
+
+In new firmware versions the firmware enforces a minimum of 5
+degrees Celsius difference between both thresholds. Make the driver
+conform to this requirement.
+
+Note that this is required even when the events are disabled, as in
+certain systems interrupts are generated via GPIO based on these
+thresholds.
+
+Fixes: 85926f877040 ("mlxsw: reg: Add definition of temperature management registers")
+Signed-off-by: Ido Schimmel <idosch(a)mellanox.com>
+Signed-off-by: Jiri Pirko <jiri(a)mellanox.com>
+Signed-off-by: David S. Miller <davem(a)davemloft.net>
+---
+ drivers/net/ethernet/mellanox/mlxsw/reg.h | 25 +++++++++++++++++++++++++
+ 1 file changed, 25 insertions(+)
+
+diff --git a/drivers/net/ethernet/mellanox/mlxsw/reg.h b/drivers/net/ethernet/mellanox/mlxsw/reg.h
+index 4afc8486eb9a..5acfbe5b8b9d 100644
+--- a/drivers/net/ethernet/mellanox/mlxsw/reg.h
++++ b/drivers/net/ethernet/mellanox/mlxsw/reg.h
+@@ -5827,6 +5827,29 @@ MLXSW_ITEM32(reg, mtmp, mtr, 0x08, 30, 1);
+ */
+ MLXSW_ITEM32(reg, mtmp, max_temperature, 0x08, 0, 16);
+
++/* reg_mtmp_tee
++ * Temperature Event Enable.
++ * 0 - Do not generate event
++ * 1 - Generate event
++ * 2 - Generate single event
++ * Access: RW
++ */
++MLXSW_ITEM32(reg, mtmp, tee, 0x0C, 30, 2);
++
++#define MLXSW_REG_MTMP_THRESH_HI 0x348 /* 105 Celsius */
++
++/* reg_mtmp_temperature_threshold_hi
++ * High threshold for Temperature Warning Event. In 0.125 Celsius.
++ * Access: RW
++ */
++MLXSW_ITEM32(reg, mtmp, temperature_threshold_hi, 0x0C, 0, 16);
++
++/* reg_mtmp_temperature_threshold_lo
++ * Low threshold for Temperature Warning Event. In 0.125 Celsius.
++ * Access: RW
++ */
++MLXSW_ITEM32(reg, mtmp, temperature_threshold_lo, 0x10, 0, 16);
++
+ #define MLXSW_REG_MTMP_SENSOR_NAME_SIZE 8
+
+ /* reg_mtmp_sensor_name
+@@ -5843,6 +5866,8 @@ static inline void mlxsw_reg_mtmp_pack(char *payload, u8 sensor_index,
+ mlxsw_reg_mtmp_sensor_index_set(payload, sensor_index);
+ mlxsw_reg_mtmp_mte_set(payload, max_temp_enable);
+ mlxsw_reg_mtmp_mtr_set(payload, max_temp_reset);
++ mlxsw_reg_mtmp_temperature_threshold_hi_set(payload,
++ MLXSW_REG_MTMP_THRESH_HI);
+ }
+
+ static inline void mlxsw_reg_mtmp_unpack(char *payload, unsigned int *p_temp,
+--
+2.13.6
+
diff --git a/kernel.spec b/kernel.spec
index e1a88cbb..e3416d1b 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -688,6 +688,9 @@ Patch630: Input-synaptics---Disable-kernel-tracking-on-SMBus-devices.patch
# Headed upstream
Patch631: drm-i915-boost-GPU-clocks-if-we-miss-the-pageflip.patch
+# http://patchwork.ozlabs.org/patch/831938/
+Patch632: 0001-mlxsw-reg-Add-high-and-low-temperature-thresholds.patch
+
# END OF PATCH DEFINITIONS
%endif
--
2.13.6
6 years, 5 months
