[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-05-21 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 4.13.0-43.48

---
linux (4.13.0-43.48) artful; urgency=medium

  * CVE-2018-3639 (powerpc)
- SAUCE: rfi-flush: update H_CPU_* macro names to upstream
- SAUCE: rfi-flush: update plpar_get_cpu_characteristics() signature to
  upstream
- SAUCE: update pseries_setup_rfi_flush() capitalization to upstream
- powerpc/pseries: Support firmware disable of RFI flush
- powerpc/powernv: Support firmware disable of RFI flush
- powerpc/64s: Allow control of RFI flush via debugfs
- powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code
- powerpc/rfi-flush: Always enable fallback flush on pseries
- powerpc/rfi-flush: Differentiate enabled and patched flush types
- powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags
- powerpc: Add security feature flags for Spectre/Meltdown
- powerpc/powernv: Set or clear security feature flags
- powerpc/pseries: Set or clear security feature flags
- powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()
- powerpc/pseries: Use the security flags in pseries_setup_rfi_flush()
- powerpc/pseries: Fix clearing of security feature flags
- powerpc: Move default security feature flags
- powerpc/pseries: Restore default security feature flags on setup
- powerpc/64s: Add support for a store forwarding barrier at kernel 
entry/exit

  * CVE-2018-3639 (x86)
- SAUCE: Add X86_FEATURE_ARCH_CAPABILITIES
- SAUCE: x86: Add alternative_msr_write
- x86/nospec: Simplify alternative_msr_write()
- x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
- x86/bugs: Concentrate bug detection into a separate function
- x86/bugs: Concentrate bug reporting into a separate function
- x86/msr: Add definitions for new speculation control MSRs
- x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits
- x86/bugs, KVM: Support the combination of guest and host IBRS
- x86/bugs: Expose /sys/../spec_store_bypass
- x86/cpufeatures: Add X86_FEATURE_RDS
- x86/bugs: Provide boot parameters for the spec_store_bypass_disable
  mitigation
- x86/bugs/intel: Set proper CPU features and setup RDS
- x86/bugs: Whitelist allowed SPEC_CTRL MSR values
- x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested
- x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest
- x86/speculation: Create spec-ctrl.h to avoid include hell
- prctl: Add speculation control prctls
- x86/process: Allow runtime control of Speculative Store Bypass
- x86/speculation: Add prctl for Speculative Store Bypass mitigation
- nospec: Allow getting/setting on non-current task
- proc: Provide details on speculation flaw mitigations
- seccomp: Enable speculation flaw mitigations
- SAUCE: x86/bugs: Honour SPEC_CTRL default
- x86/bugs: Make boot modes __ro_after_init
- prctl: Add force disable speculation
- seccomp: Use PR_SPEC_FORCE_DISABLE
- seccomp: Add filter flag to opt-out of SSB mitigation
- seccomp: Move speculation migitation control to arch code
- x86/speculation: Make "seccomp" the default mode for Speculative Store
  Bypass
- x86/bugs: Rename _RDS to _SSBD
- proc: Use underscores for SSBD in 'status'
- Documentation/spec_ctrl: Do some minor cleanups
- x86/bugs: Fix __ssb_select_mitigation() return type
- x86/bugs: Make cpu_show_common() static

  * LSM Stacking prctl values should be redefined as to not collide with
upstream prctls (LP: #1769263) // CVE-2018-3639
- SAUCE: LSM stacking: adjust prctl values

linux (4.13.0-42.47) artful; urgency=medium

  * linux: 4.13.0-42.47 -proposed tracker (LP: #1769993)

  * arm64: fix CONFIG_DEBUG_WX address reporting (LP: #1765850)
- arm64: fix CONFIG_DEBUG_WX address reporting

  * HiSilicon HNS NIC names are truncated in /proc/interrupts (LP: #1765977)
- net: hns: Avoid action name truncation

  * CVE-2017-18208
- mm/madvise.c: fix madvise() infinite loop under special circumstances

  * CVE-2018-8822
- staging: ncpfs: memory corruption in ncp_read_kernel()

  * CVE-2017-18203
- dm: fix race between dm_get_from_kobject() and __dm_destroy()

  * CVE-2017-17449
- netlink: Add netns check on taps

  * CVE-2017-17975
- media: usbtv: prevent double free in error case

  * [8086:3e92] display becomes blank after S3 (LP: #1763271)
- drm/i915/edp: Allow alternate fixed mode for eDP if available.
- drm/i915/dp: rename intel_dp_is_edp to intel_dp_is_port_edp
- drm/i915/dp: make is_edp non-static and rename to intel_dp_is_edp
- drm/i915/edp: Do not do link training fallback or prune modes on EDP

  * sky2 gigabit ethernet driver sometimes stops working after lid-open resume
from sleep (88E8055) (LP: #1758507)
- sky2: Increase D3 delay to sky2 stops working after suspend

  * perf vendor events arm64: Enable JSON events for 

[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-05-21 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 4.13.0-43.48

---
linux (4.13.0-43.48) artful; urgency=medium

  * CVE-2018-3639 (powerpc)
- SAUCE: rfi-flush: update H_CPU_* macro names to upstream
- SAUCE: rfi-flush: update plpar_get_cpu_characteristics() signature to
  upstream
- SAUCE: update pseries_setup_rfi_flush() capitalization to upstream
- powerpc/pseries: Support firmware disable of RFI flush
- powerpc/powernv: Support firmware disable of RFI flush
- powerpc/64s: Allow control of RFI flush via debugfs
- powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code
- powerpc/rfi-flush: Always enable fallback flush on pseries
- powerpc/rfi-flush: Differentiate enabled and patched flush types
- powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags
- powerpc: Add security feature flags for Spectre/Meltdown
- powerpc/powernv: Set or clear security feature flags
- powerpc/pseries: Set or clear security feature flags
- powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()
- powerpc/pseries: Use the security flags in pseries_setup_rfi_flush()
- powerpc/pseries: Fix clearing of security feature flags
- powerpc: Move default security feature flags
- powerpc/pseries: Restore default security feature flags on setup
- powerpc/64s: Add support for a store forwarding barrier at kernel 
entry/exit

  * CVE-2018-3639 (x86)
- SAUCE: Add X86_FEATURE_ARCH_CAPABILITIES
- SAUCE: x86: Add alternative_msr_write
- x86/nospec: Simplify alternative_msr_write()
- x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
- x86/bugs: Concentrate bug detection into a separate function
- x86/bugs: Concentrate bug reporting into a separate function
- x86/msr: Add definitions for new speculation control MSRs
- x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits
- x86/bugs, KVM: Support the combination of guest and host IBRS
- x86/bugs: Expose /sys/../spec_store_bypass
- x86/cpufeatures: Add X86_FEATURE_RDS
- x86/bugs: Provide boot parameters for the spec_store_bypass_disable
  mitigation
- x86/bugs/intel: Set proper CPU features and setup RDS
- x86/bugs: Whitelist allowed SPEC_CTRL MSR values
- x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested
- x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest
- x86/speculation: Create spec-ctrl.h to avoid include hell
- prctl: Add speculation control prctls
- x86/process: Allow runtime control of Speculative Store Bypass
- x86/speculation: Add prctl for Speculative Store Bypass mitigation
- nospec: Allow getting/setting on non-current task
- proc: Provide details on speculation flaw mitigations
- seccomp: Enable speculation flaw mitigations
- SAUCE: x86/bugs: Honour SPEC_CTRL default
- x86/bugs: Make boot modes __ro_after_init
- prctl: Add force disable speculation
- seccomp: Use PR_SPEC_FORCE_DISABLE
- seccomp: Add filter flag to opt-out of SSB mitigation
- seccomp: Move speculation migitation control to arch code
- x86/speculation: Make "seccomp" the default mode for Speculative Store
  Bypass
- x86/bugs: Rename _RDS to _SSBD
- proc: Use underscores for SSBD in 'status'
- Documentation/spec_ctrl: Do some minor cleanups
- x86/bugs: Fix __ssb_select_mitigation() return type
- x86/bugs: Make cpu_show_common() static

  * LSM Stacking prctl values should be redefined as to not collide with
upstream prctls (LP: #1769263) // CVE-2018-3639
- SAUCE: LSM stacking: adjust prctl values

linux (4.13.0-42.47) artful; urgency=medium

  * linux: 4.13.0-42.47 -proposed tracker (LP: #1769993)

  * arm64: fix CONFIG_DEBUG_WX address reporting (LP: #1765850)
- arm64: fix CONFIG_DEBUG_WX address reporting

  * HiSilicon HNS NIC names are truncated in /proc/interrupts (LP: #1765977)
- net: hns: Avoid action name truncation

  * CVE-2017-18208
- mm/madvise.c: fix madvise() infinite loop under special circumstances

  * CVE-2018-8822
- staging: ncpfs: memory corruption in ncp_read_kernel()

  * CVE-2017-18203
- dm: fix race between dm_get_from_kobject() and __dm_destroy()

  * CVE-2017-17449
- netlink: Add netns check on taps

  * CVE-2017-17975
- media: usbtv: prevent double free in error case

  * [8086:3e92] display becomes blank after S3 (LP: #1763271)
- drm/i915/edp: Allow alternate fixed mode for eDP if available.
- drm/i915/dp: rename intel_dp_is_edp to intel_dp_is_port_edp
- drm/i915/dp: make is_edp non-static and rename to intel_dp_is_edp
- drm/i915/edp: Do not do link training fallback or prune modes on EDP

  * sky2 gigabit ethernet driver sometimes stops working after lid-open resume
from sleep (88E8055) (LP: #1758507)
- sky2: Increase D3 delay to sky2 stops working after suspend

  * perf vendor events arm64: Enable JSON events for 

[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-05-21 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 3.13.0-149.199

---
linux (3.13.0-149.199) trusty; urgency=medium

  * CVE-2018-3639 (powerpc)
- SAUCE: rfi-flush: update H_CPU_* macro names to upstream
- SAUCE: rfi-flush: update plpar_get_cpu_characteristics() signature to
  upstream
- powerpc/pseries: Support firmware disable of RFI flush
- powerpc/powernv: Support firmware disable of RFI flush
- powerpc/64s: Allow control of RFI flush via debugfs
- powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code
- powerpc/rfi-flush: Always enable fallback flush on pseries
- powerpc/rfi-flush: Differentiate enabled and patched flush types
- powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags
- powerpc: Add security feature flags for Spectre/Meltdown
- powerpc/pseries: Set or clear security feature flags
- powerpc/powernv: Set or clear security feature flags
- powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()
- powerpc/pseries: Use the security flags in pseries_setup_rfi_flush()
- powerpc/pseries: Fix clearing of security feature flags
- powerpc: Move default security feature flags
- powerpc/pseries: Restore default security feature flags on setup
- powerpc/64s: Add support for a store forwarding barrier at kernel 
entry/exit
- SAUCE: powerpc/64s: Move the data access exception out-of-line

  * CVE-2018-3639 (x86)
- arch: Introduce post-init read-only memory
- SAUCE: Add X86_FEATURE_ARCH_CAPABILITIES
- SAUCE: x86: Add alternative_msr_write
- x86/nospec: Simplify alternative_msr_write()
- x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
- x86/bugs: Concentrate bug detection into a separate function
- x86/bugs: Concentrate bug reporting into a separate function
- x86/msr: Add definitions for new speculation control MSRs
- x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits
- x86/bugs, KVM: Support the combination of guest and host IBRS
- x86/bugs: Expose /sys/../spec_store_bypass
- x86/cpufeatures: Add X86_FEATURE_RDS
- x86/bugs: Provide boot parameters for the spec_store_bypass_disable
  mitigation
- x86/bugs/intel: Set proper CPU features and setup RDS
- x86/bugs: Whitelist allowed SPEC_CTRL MSR values
- x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested
- x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest
- x86/speculation: Create spec-ctrl.h to avoid include hell
- prctl: Add speculation control prctls
- x86/process: Allow runtime control of Speculative Store Bypass
- x86/speculation: Add prctl for Speculative Store Bypass mitigation
- nospec: Allow getting/setting on non-current task
- proc: Provide details on speculation flaw mitigations
- seccomp: Enable speculation flaw mitigations
- SAUCE: x86/bugs: Honour SPEC_CTRL default
- x86/bugs: Make boot modes __ro_after_init
- prctl: Add force disable speculation
- seccomp: Use PR_SPEC_FORCE_DISABLE
- seccomp: Add filter flag to opt-out of SSB mitigation
- seccomp: Move speculation migitation control to arch code
- x86/speculation: Make "seccomp" the default mode for Speculative Store
  Bypass
- x86/bugs: Rename _RDS to _SSBD
- proc: Use underscores for SSBD in 'status'
- Documentation/spec_ctrl: Do some minor cleanups
- x86/bugs: Fix __ssb_select_mitigation() return type
- x86/bugs: Make cpu_show_common() static

linux (3.13.0-148.197) trusty; urgency=medium

  * linux: 3.13.0-148.197 -proposed tracker (LP: #1769077)

  * CVE-2017-18208
- mm/madvise.c: fix madvise() infinite loop under special circumstances

  * CVE-2018-8822
- staging: ncpfs: memory corruption in ncp_read_kernel()

  * CVE-2017-18221
- mlock: fix mlock count can not decrease in race condition

  * CVE-2017-12134
- xen: fix bio vec merging

  * CVE-2017-18203
- dm: fix race between dm_get_from_kobject() and __dm_destroy()

  * CVE-2017-17449
- netlink: Add netns check on taps

  * CVE-2017-13220
- Bluetooth: hidp_connection_add() unsafe use of l2cap_pi()

  * CVE-2017-18204
- ocfs2: should wait dio before inode lock in ocfs2_setattr()

  * CVE-2017-13305
- KEYS: encrypted: fix buffer overread in valid_master_desc()

  * CVE-2017-18079
- Input: i8042 - fix crash at boot time

  * "ip a" command on a guest VM shows UNKNOWN status (LP: #1761534)
- virtio-net: Fix operstate for virtio when no VIRTIO_NET_F_STATUS

  * ibrs/ibpb fixes result in excessive kernel logging  (LP: #1755627)
- SAUCE: remove ibrs_dump sysctl interface

 -- Stefan Bader   Mon, 14 May 2018 16:58:50
+0200

** Changed in: linux (Ubuntu Trusty)
   Status: Fix Committed => Fix Released

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-12134

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-13220


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-05-21 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 3.13.0-149.199

---
linux (3.13.0-149.199) trusty; urgency=medium

  * CVE-2018-3639 (powerpc)
- SAUCE: rfi-flush: update H_CPU_* macro names to upstream
- SAUCE: rfi-flush: update plpar_get_cpu_characteristics() signature to
  upstream
- powerpc/pseries: Support firmware disable of RFI flush
- powerpc/powernv: Support firmware disable of RFI flush
- powerpc/64s: Allow control of RFI flush via debugfs
- powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code
- powerpc/rfi-flush: Always enable fallback flush on pseries
- powerpc/rfi-flush: Differentiate enabled and patched flush types
- powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags
- powerpc: Add security feature flags for Spectre/Meltdown
- powerpc/pseries: Set or clear security feature flags
- powerpc/powernv: Set or clear security feature flags
- powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()
- powerpc/pseries: Use the security flags in pseries_setup_rfi_flush()
- powerpc/pseries: Fix clearing of security feature flags
- powerpc: Move default security feature flags
- powerpc/pseries: Restore default security feature flags on setup
- powerpc/64s: Add support for a store forwarding barrier at kernel 
entry/exit
- SAUCE: powerpc/64s: Move the data access exception out-of-line

  * CVE-2018-3639 (x86)
- arch: Introduce post-init read-only memory
- SAUCE: Add X86_FEATURE_ARCH_CAPABILITIES
- SAUCE: x86: Add alternative_msr_write
- x86/nospec: Simplify alternative_msr_write()
- x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
- x86/bugs: Concentrate bug detection into a separate function
- x86/bugs: Concentrate bug reporting into a separate function
- x86/msr: Add definitions for new speculation control MSRs
- x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits
- x86/bugs, KVM: Support the combination of guest and host IBRS
- x86/bugs: Expose /sys/../spec_store_bypass
- x86/cpufeatures: Add X86_FEATURE_RDS
- x86/bugs: Provide boot parameters for the spec_store_bypass_disable
  mitigation
- x86/bugs/intel: Set proper CPU features and setup RDS
- x86/bugs: Whitelist allowed SPEC_CTRL MSR values
- x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested
- x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest
- x86/speculation: Create spec-ctrl.h to avoid include hell
- prctl: Add speculation control prctls
- x86/process: Allow runtime control of Speculative Store Bypass
- x86/speculation: Add prctl for Speculative Store Bypass mitigation
- nospec: Allow getting/setting on non-current task
- proc: Provide details on speculation flaw mitigations
- seccomp: Enable speculation flaw mitigations
- SAUCE: x86/bugs: Honour SPEC_CTRL default
- x86/bugs: Make boot modes __ro_after_init
- prctl: Add force disable speculation
- seccomp: Use PR_SPEC_FORCE_DISABLE
- seccomp: Add filter flag to opt-out of SSB mitigation
- seccomp: Move speculation migitation control to arch code
- x86/speculation: Make "seccomp" the default mode for Speculative Store
  Bypass
- x86/bugs: Rename _RDS to _SSBD
- proc: Use underscores for SSBD in 'status'
- Documentation/spec_ctrl: Do some minor cleanups
- x86/bugs: Fix __ssb_select_mitigation() return type
- x86/bugs: Make cpu_show_common() static

linux (3.13.0-148.197) trusty; urgency=medium

  * linux: 3.13.0-148.197 -proposed tracker (LP: #1769077)

  * CVE-2017-18208
- mm/madvise.c: fix madvise() infinite loop under special circumstances

  * CVE-2018-8822
- staging: ncpfs: memory corruption in ncp_read_kernel()

  * CVE-2017-18221
- mlock: fix mlock count can not decrease in race condition

  * CVE-2017-12134
- xen: fix bio vec merging

  * CVE-2017-18203
- dm: fix race between dm_get_from_kobject() and __dm_destroy()

  * CVE-2017-17449
- netlink: Add netns check on taps

  * CVE-2017-13220
- Bluetooth: hidp_connection_add() unsafe use of l2cap_pi()

  * CVE-2017-18204
- ocfs2: should wait dio before inode lock in ocfs2_setattr()

  * CVE-2017-13305
- KEYS: encrypted: fix buffer overread in valid_master_desc()

  * CVE-2017-18079
- Input: i8042 - fix crash at boot time

  * "ip a" command on a guest VM shows UNKNOWN status (LP: #1761534)
- virtio-net: Fix operstate for virtio when no VIRTIO_NET_F_STATUS

  * ibrs/ibpb fixes result in excessive kernel logging  (LP: #1755627)
- SAUCE: remove ibrs_dump sysctl interface

 -- Stefan Bader   Mon, 14 May 2018 16:58:50
+0200

** Changed in: linux (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-16995

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-17862


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-05-21 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 4.4.0-127.153

---
linux (4.4.0-127.153) xenial; urgency=medium

  * CVE-2018-3639 (powerpc)
- powerpc/pseries: Support firmware disable of RFI flush
- powerpc/powernv: Support firmware disable of RFI flush
- powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code
- powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again
- powerpc/rfi-flush: Always enable fallback flush on pseries
- powerpc/rfi-flush: Differentiate enabled and patched flush types
- powerpc/rfi-flush: Call setup_rfi_flush() after LPM migration
- powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags
- powerpc: Add security feature flags for Spectre/Meltdown
- powerpc/pseries: Set or clear security feature flags
- powerpc/powernv: Set or clear security feature flags
- powerpc/64s: Move cpu_show_meltdown()
- powerpc/64s: Enhance the information in cpu_show_meltdown()
- powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()
- powerpc/pseries: Use the security flags in pseries_setup_rfi_flush()
- powerpc/64s: Wire up cpu_show_spectre_v1()
- powerpc/64s: Wire up cpu_show_spectre_v2()
- powerpc/pseries: Fix clearing of security feature flags
- powerpc: Move default security feature flags
- powerpc/pseries: Restore default security feature flags on setup
- SAUCE: powerpc/64s: Add support for a store forwarding barrier at kernel
  entry/exit

  * CVE-2018-3639 (x86)
- SAUCE: Clean up IBPB and IBRS control functions and macros
- SAUCE: Fix up IBPB and IBRS kernel parameters documentation
- SAUCE: Remove #define X86_FEATURE_PTI
- x86/cpufeature: Move some of the scattered feature bits to x86_capability
- x86/cpufeature: Cleanup get_cpu_cap()
- x86/cpu: Probe CPUID leaf 6 even when cpuid_level == 6
- x86/cpufeatures: Add CPUID_7_EDX CPUID leaf
- x86/cpufeatures: Add Intel feature bits for Speculation Control
- SAUCE: x86/kvm: Expose SPEC_CTRL from the leaf
- x86/cpufeatures: Add AMD feature bits for Speculation Control
- x86/msr: Add definitions for new speculation control MSRs
- SAUCE: x86/msr: Rename MSR spec control feature bits
- x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
- x86/cpufeature: Blacklist SPEC_CTRL/PRED_CMD on early Spectre v2 
microcodes
- x86/speculation: Add basic IBPB (Indirect Branch Prediction Barrier) 
support
- x86/speculation: Add  dependency
- x86/cpufeatures: Clean up Spectre v2 related CPUID flags
- x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel
- SAUCE: x86/speculation: Move vendor specific IBRS/IBPB control code
- SAUCE: x86: Add alternative_msr_write
- SAUCE: x86/nospec: Simplify alternative_msr_write()
- SAUCE: x86/bugs: Concentrate bug detection into a separate function
- SAUCE: x86/bugs: Concentrate bug reporting into a separate function
- arch: Introduce post-init read-only memory
- SAUCE: x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits
- SAUCE: x86/bugs, KVM: Support the combination of guest and host IBRS
- SAUCE: x86/bugs: Expose /sys/../spec_store_bypass
- SAUCE: x86/cpufeatures: Add X86_FEATURE_RDS
- SAUCE: x86/bugs: Provide boot parameters for the spec_store_bypass_disable
  mitigation
- SAUCE: x86/bugs/intel: Set proper CPU features and setup RDS
- SAUCE: x86/bugs: Whitelist allowed SPEC_CTRL MSR values
- SAUCE: x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if
  requested
- SAUCE: x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest
- SAUCE: x86/speculation: Create spec-ctrl.h to avoid include hell
- SAUCE: prctl: Add speculation control prctls
- x86/process: Optimize TIF checks in __switch_to_xtra()
- SAUCE: x86/process: Allow runtime control of Speculative Store Bypass
- SAUCE: x86/speculation: Add prctl for Speculative Store Bypass mitigation
- SAUCE: nospec: Allow getting/setting on non-current task
- SAUCE: proc: Provide details on speculation flaw mitigations
- SAUCE: seccomp: Enable speculation flaw mitigations
- SAUCE: x86/bugs: Honour SPEC_CTRL default
- SAUCE: x86/bugs: Make boot modes __ro_after_init
- SAUCE: prctl: Add force disable speculation
- SAUCE: seccomp: Use PR_SPEC_FORCE_DISABLE
- selftest/seccomp: Fix the flag name SECCOMP_FILTER_FLAG_TSYNC
- SAUCE: seccomp: Add filter flag to opt-out of SSB mitigation
- SAUCE: seccomp: Move speculation migitation control to arch code
- SAUCE: x86/speculation: Make "seccomp" the default mode for Speculative
  Store Bypass
- SAUCE: x86/bugs: Rename _RDS to _SSBD
- SAUCE: proc: Use underscores for SSBD in 'status'
- SAUCE: Documentation/spec_ctrl: Do some minor cleanups
- SAUCE: x86/bugs: Fix __ssb_select_mitigation() return type
- SAUCE: x86/bugs: Make cpu_show_common() static

[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-05-11 Thread Kamal Mostafa
Indeed, the -proposed kernel versions which included this fix were all
bumped out due to an unrelated security fix release.  The next kernel
versions (now available in -proposed) include the fix again:

 trusty 3.13.0-148.197
 xenial 4.4.0-125.150
 artful 4.13.0-42.47

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-05-10 Thread Scott Emmons
It looks like it got deferred to 4.4.0-125 according to the changelog
[1].

[1] https://launchpad.net/ubuntu/+source/linux/4.4.0-125.150

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-05-10 Thread Will Oller
I am still experiencing this issue after upgrading to xenial 16.04.4 LTS
4.4.0-124-generic.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-30 Thread daniel CURTIS
Hello.

I just wanto to confirm: everything seems to be okay after updating
Linux kernel to v4.4.0-123-generic. However, I would like to ask a
question about 'intel-microcode' and 'amd64-microcode' packages. During
system updating process via apt(8), there was an information that "The
following NEW packages will be installed" etc. and it was about two
mentioned 'microcode' packages.

I did not have these packages installed, until then. It's an Intel
processor, but it seems, that Intel Corporation will not publish any
microcode updates for some processor. Intel reveals (on Apr. 3., 2018)
list of processors that won't receive Meltdown and Spectre patches. It
seems, that some of older processors won't receive microcode updates
designed to mitigate the vulnerabilities: Bloomfield, Bloomfield Xeon,
Clarksfield, Gulftown etc.

So, I would like to ask if it was normal, that apt(8) installed such a
packages? And why both since it's an Intel processor? Can I remove both
packages (since there is no changes related to the microcode and
"Spectre & Meltdown" mitigation; just 'revision' change in
'/proc/cpuinfo' virtual file or/and dmesg(1) etc.)?

In sum two questions:

✗ why apt(8) installed two 'microcode' packages during Linux kernel 
v4.4.0-123-generic updates? 
✗ can 'intel/amd64-microcode' packages be removed (since there is no difference 
with "Spectre & Meltdown" mitigations)? 

I apologize for asking such a questions here, but this bug is about
'ibrs/ibpb' (a method to "Spectre & Meltdown" mitigation etc.) and Linux
kernel update (v4.4.0-123-generic) during which, two 'microcode'
packages were installed.

Thanks, best regards.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:

[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-27 Thread Kamal Mostafa
Verified fixed in all affected -proposed kernels:
 trusty 3.13.0-146.195
 xenial 4.4.0-123.147
 artful 4.13.0-40.45

** Tags removed: verification-needed-artful verification-needed-trusty 
verification-needed-xenial
** Tags added: verification-done-artful verification-done-trusty 
verification-done-xenial

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-27 Thread Brad Figg
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'. If the problem still exists,
change the tag 'verification-needed-xenial' to 'verification-failed-
xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-27 Thread Brad Figg
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
artful' to 'verification-done-artful'. If the problem still exists,
change the tag 'verification-needed-artful' to 'verification-failed-
artful'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-artful

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-25 Thread daniel CURTIS
Hello.

Yes, Mr. Kamal Mostafa is right. Linux kernel v4.4.0-123.147 will
contain a fix for all of these issues with, for example,
'/var/log/syslog' flooding with 'ibrs_dump', 'use_ibrs/ibpb' and
'sysctl_ibrs{,ibpb}_enabled' entries. Now, a "proposed" kernel is
v4.4.0-122.146  with a fix for "Redpine: WiFi scan stopping issue
observed with BLE (LP: #1757435)".

Anyway, next kernel version, mentioned above will be updated, at last,
to the v4.4.128 stable release (current version, available e.g. in 16.04
LTS is v4.4.117) and will contain this patch, of course:

* ibrs/ibpb fixes result in excessive kernel logging  (LP: #1755627)
  - SAUCE: remove ibrs_dump sysctl interface 

So, we have to wait a little more, because so-called "master-next"
branch (with all needed patches for already mentioned v4.4.128 Stable
release) was updated only 24 hours ago. Additionally, there will be also
a couple of 'x86/spectre' and 'x86/retpoline' patches (mainly in
v4.4.118).

Thanks, best regards.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-25 Thread Brad Figg
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
trusty' to 'verification-done-trusty'. If the problem still exists,
change the tag 'verification-needed-trusty' to 'verification-failed-
trusty'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-trusty

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-25 Thread Stephan Kurth
Is the fixed kernel available right now? Or when could it be available?
This "ubrs" messages are flooding our syslog log files on many machines.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-24 Thread Kamal Mostafa
Just FYI folks: This fix does not yet appear in the kernels which just
landed in -proposed (which are respins for an unrelated issue).  The fix
is still queued up for the next cycle (currently 4.4.0-123.147).

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-21 Thread daniel CURTIS
Hello.

Today, I noticed the same entries in a log files such as
'/var/log/syslog' and via dmesg(1) on 16.04 LTS Release (i386/x86_32
arch) with v4.4.0-120-generic (4.4.117) Linux kernel. The one thing,
that is different is 'use_ibrs' value. In my case it's:

[~]$ sudo dmesg
[  464.877859] use_ibrs = 0, use_ibpb = 4
[  467.893757] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[  467.893762] use_ibrs = 4, use_ibpb = 4
(...)

I'm writing about this, because I don't see '0' in any of the above
posts etc. Anyway, as Mr Kamal Mostafa wrote, I will wait for a
"-proposed" kernel.

Thanks, best regards.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-18 Thread Zophren
Hello,

The same here:

Apr 18 06:29:16 ovh-staging-rancher-docker-10 kernel: [37874.285196] 
sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
Apr 18 06:29:16 host kernel: [37874.285197] use_ibrs = 4, use_ibpb = 4
Apr 18 06:29:16 host kernel: [37874.285202] read cpu 0 ibrs val 0
Apr 18 06:29:16 host kernel: [37874.285203] read cpu 1 ibrs val 0
Apr 18 06:29:16 host kernel: [37874.285203] read cpu 2 ibrs val 0
Apr 18 06:29:16 host kernel: [37874.285204] read cpu 3 ibrs val 0

Linux DESKTOP-KCAOO2V 4.4.0-17133-Microsoft #1-Microsoft Fri Mar 23
13:12:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-13 Thread Kamal Mostafa
@lscotte - Thanks for reporting the issue.  Launchpad will post a note
to this bug as soon as the kernel versions containing the fix reach the
-proposed archive.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-12 Thread Scott Emmons
Thank you @kamalmostafa - we'll keep an eye out for the updated packages
in the repositories and follow up if anything is not as expected. Thanks
again for fixing this!

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-12 Thread Kamal Mostafa
@bmoyles-  FYI, we're just removing the kernel.ibrs_dump interface
altogether -- its only purpose is to provide that debug info, and
nothing like it made it to mainline.

** Changed in: linux (Ubuntu Trusty)
   Status: In Progress => Fix Committed

** Changed in: linux (Ubuntu Xenial)
   Status: In Progress => Fix Committed

** Changed in: linux (Ubuntu Artful)
   Status: In Progress => Fix Committed

** Changed in: linux (Ubuntu)
   Status: Confirmed => Fix Committed

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Kamal Mostafa (kamalmostafa)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Artful:
  Fix Committed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-12 Thread Kamal Mostafa
** Also affects: linux (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu Artful)
   Status: New => In Progress

** Changed in: linux (Ubuntu Artful)
 Assignee: (unassigned) => Kamal Mostafa (kamalmostafa)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Trusty:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Artful:
  In Progress

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-04-03 Thread Kamal Mostafa
** Changed in: linux (Ubuntu Trusty)
 Assignee: Canonical Kernel Team (canonical-kernel-team) => Kamal Mostafa 
(kamalmostafa)

** Changed in: linux (Ubuntu Xenial)
 Assignee: Canonical Kernel Team (canonical-kernel-team) => Kamal Mostafa 
(kamalmostafa)

** Changed in: linux (Ubuntu Trusty)
   Status: Triaged => In Progress

** Changed in: linux (Ubuntu Xenial)
   Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Trusty:
  In Progress
Status in linux source package in Xenial:
  In Progress

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-03-14 Thread Brian Moyles
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/tree/kernel/sysctl.c#n2433
and 
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/tree/kernel/sysctl.c#n2446

are the source(s) of the noise

Looking at nearby functions like proc_dointvec_ibrs_ctrl and
proc_dointvec_ipbp_ctrl, I suspect the intention was to use pr_debug
instead of printk...

Introduced in this commit:
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/commit/kernel/sysctl.c?id=5e7fa0233bdfe2906216606d0d4d156be8f86950

I haven't done any digging on 3.13 but expect it will be similar.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Trusty:
  Triaged
Status in linux source package in Xenial:
  Triaged

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-03-14 Thread Scott Emmons
Thank you Leann!

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Trusty:
  Triaged
Status in linux source package in Xenial:
  Triaged

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-03-14 Thread Leann Ogasawara
** Also affects: linux (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu Trusty)
   Status: New => Triaged

** Changed in: linux (Ubuntu Trusty)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Trusty)
 Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)

** Changed in: linux (Ubuntu Xenial)
   Status: Confirmed => Triaged

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Trusty:
  Triaged
Status in linux source package in Xenial:
  Triaged

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-03-14 Thread Brian Moyles
Also, to call it out again, this appears to affect Trusty's LTS kernel,
too (it's not clear how one marks a bug as such from the Launchpad UI)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Confirmed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-03-14 Thread Brian Moyles
For the sake of completeness on this one, I installed the following
mainline packages on an AWS m5.large instance running 16.04.3 w/
4.4.0-112-generic

- linux-headers-4.16.0-041600rc4_4.16.0-041600rc4.201803041930_all.deb
- linux-headers-4.16.0-041600rc4-generic_4.16.0-041600rc4.201803041930_amd64.deb
- linux-image-4.16.0-041600rc4-generic_4.16.0-041600rc4.201803041930_amd64.deb

This does NOT trigger the bug, either via `sysctl -a` or `sysctl
kernel.ibrs_dump` as `/proc/sys/kernel/ibrs_dump` does not exist.  This
is the same behavior on Bionic w/ 4.15.


** Tags added: kernel-fixed-upstream

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Confirmed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-03-14 Thread Brian Moyles
It's worth noting, too, that this does not happen on Bionic @  4.15
(using Ubuntu 4.15.0-1001.1-aws 4.15.3) but it does happen on Trusty
(using Ubuntu 3.13.0-143.192-generic 3.13.11-ckt39)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Confirmed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-03-14 Thread Scott Emmons
Returning to confirmed status - easily reproducible with LTS kernels.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Confirmed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-03-14 Thread Scott Emmons
We use LTS kernels, so no - unfortunately we cannot.

** Changed in: linux (Ubuntu Xenial)
   Status: Incomplete => Confirmed

** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Confirmed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-03-14 Thread Joseph Salisbury
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v4.16 kernel[0].

If this bug is fixed in the mainline kernel, please add the following
tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag:
'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as
"Confirmed".


Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.16-rc4


** Changed in: linux (Ubuntu)
   Importance: Undecided => Medium

** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Tags added: kernel-da-key

** Changed in: linux (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Xenial)
   Status: New => Incomplete

** Changed in: linux (Ubuntu)
   Status: Confirmed => Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Xenial:
  Incomplete

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging

2018-03-13 Thread Brian Moyles
We do not use apport and this is easily reproducible. If there is any
pointed information I can provide beyond what I've already submitted,
please let me know.

** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1755627

Title:
  ibrs/ibpb fixes result in excessive kernel logging

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Since at least kernel 4.4.0-116, every invocation of `sysctl -a`
  results in kernel logs similar to the following:

  % sysctl -a &>/dev/null; dmesg -T | tail -8
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0

  The output varies with the number of CPUs.

  After digging a bit, it turns out this is triggered upon every read of
  `kernel.ibrs_dump`:

  % for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; 
sleep 1; done
  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0

  kernel.ibrs_dump = 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
  [Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
  [Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
  [Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
  [Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0

  
  Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic 
4.4.98 per /proc/version_signature

  Normally this would not be the biggest concern but we have tooling
  that gathers instance info on a schedule, including sysctl output,
  thus resulting in the kernel ring buffer being full of nothing but
  said output in most cases and hindering live troubleshooting as a
  result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp