<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/acpi/osl.c, branch linux-5.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-12-17T18:56:33Z</updated>
<entry>
<title>ACPI: OSL: only free map once in osl.c</title>
<updated>2019-12-17T18:56:33Z</updated>
<author>
<name>Francesco Ruggeri</name>
</author>
<published>2019-11-20T05:47:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b8b5c898b0081f6a180e01f5135b7b5b37493e10'/>
<id>urn:sha1:b8b5c898b0081f6a180e01f5135b7b5b37493e10</id>
<content type='text'>
commit 833a426cc471b6088011b3d67f1dc4e147614647 upstream.

acpi_os_map_cleanup checks map-&gt;refcount outside of acpi_ioremap_lock
before freeing the map. This creates a race condition the can result
in the map being freed more than once.
A panic can be caused by running

for ((i=0; i&lt;10; i++))
do
        for ((j=0; j&lt;100000; j++))
        do
                cat /sys/firmware/acpi/tables/data/BERT &gt;/dev/null
        done &amp;
done

This patch makes sure that only the process that drops the reference
to 0 does the freeing.

Fixes: b7c1fadd6c2e ("ACPI: Do not use krefs under a mutex in osl.c")
Signed-off-by: Francesco Ruggeri &lt;fruggeri@arista.com&gt;
Reviewed-by: Dmitry Safonov &lt;0x7f454c46@gmail.com&gt;
Cc: All applicable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge branch 'next-lockdown' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security</title>
<updated>2019-09-28T15:14:15Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2019-09-28T15:14:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d'/>
<id>urn:sha1:aefcf2f4b58155d27340ba5f9ddbe9513da8286d</id>
<content type='text'>
Pull kernel lockdown mode from James Morris:
 "This is the latest iteration of the kernel lockdown patchset, from
  Matthew Garrett, David Howells and others.

  From the original description:

    This patchset introduces an optional kernel lockdown feature,
    intended to strengthen the boundary between UID 0 and the kernel.
    When enabled, various pieces of kernel functionality are restricted.
    Applications that rely on low-level access to either hardware or the
    kernel may cease working as a result - therefore this should not be
    enabled without appropriate evaluation beforehand.

    The majority of mainstream distributions have been carrying variants
    of this patchset for many years now, so there's value in providing a
    doesn't meet every distribution requirement, but gets us much closer
    to not requiring external patches.

  There are two major changes since this was last proposed for mainline:

   - Separating lockdown from EFI secure boot. Background discussion is
     covered here: https://lwn.net/Articles/751061/

   -  Implementation as an LSM, with a default stackable lockdown LSM
      module. This allows the lockdown feature to be policy-driven,
      rather than encoding an implicit policy within the mechanism.

  The new locked_down LSM hook is provided to allow LSMs to make a
  policy decision around whether kernel functionality that would allow
  tampering with or examining the runtime state of the kernel should be
  permitted.

  The included lockdown LSM provides an implementation with a simple
  policy intended for general purpose use. This policy provides a coarse
  level of granularity, controllable via the kernel command line:

    lockdown={integrity|confidentiality}

  Enable the kernel lockdown feature. If set to integrity, kernel features
  that allow userland to modify the running kernel are disabled. If set to
  confidentiality, kernel features that allow userland to extract
  confidential information from the kernel are also disabled.

  This may also be controlled via /sys/kernel/security/lockdown and
  overriden by kernel configuration.

  New or existing LSMs may implement finer-grained controls of the
  lockdown features. Refer to the lockdown_reason documentation in
  include/linux/security.h for details.

  The lockdown feature has had signficant design feedback and review
  across many subsystems. This code has been in linux-next for some
  weeks, with a few fixes applied along the way.

  Stephen Rothwell noted that commit 9d1f8be5cf42 ("bpf: Restrict bpf
  when kernel lockdown is in confidentiality mode") is missing a
  Signed-off-by from its author. Matthew responded that he is providing
  this under category (c) of the DCO"

* 'next-lockdown' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (31 commits)
  kexec: Fix file verification on S390
  security: constify some arrays in lockdown LSM
  lockdown: Print current-&gt;comm in restriction messages
  efi: Restrict efivar_ssdt_load when the kernel is locked down
  tracefs: Restrict tracefs when the kernel is locked down
  debugfs: Restrict debugfs when the kernel is locked down
  kexec: Allow kexec_file() with appropriate IMA policy when locked down
  lockdown: Lock down perf when in confidentiality mode
  bpf: Restrict bpf when kernel lockdown is in confidentiality mode
  lockdown: Lock down tracing and perf kprobes when in confidentiality mode
  lockdown: Lock down /proc/kcore
  x86/mmiotrace: Lock down the testmmiotrace module
  lockdown: Lock down module params that specify hardware parameters (eg. ioport)
  lockdown: Lock down TIOCSSERIAL
  lockdown: Prohibit PCMCIA CIS storage when the kernel is locked down
  acpi: Disable ACPI table override if the kernel is locked down
  acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
  ACPI: Limit access to custom_method when the kernel is locked down
  x86/msr: Restrict MSR access when the kernel is locked down
  x86: Lock down IO port access when the kernel is locked down
  ...
</content>
</entry>
<entry>
<title>acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down</title>
<updated>2019-08-20T04:54:16Z</updated>
<author>
<name>Josh Boyer</name>
</author>
<published>2019-08-20T00:17:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=41fa1ee9c6d687afb05760dd349f361855f1d7f5'/>
<id>urn:sha1:41fa1ee9c6d687afb05760dd349f361855f1d7f5</id>
<content type='text'>
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to modify the workings of hardware. Reject
the option when the kernel is locked down. This requires some reworking
of the existing RSDP command line logic, since the early boot code also
makes use of a command-line passed RSDP when locating the SRAT table
before the lockdown code has been initialised. This is achieved by
separating the command line RSDP path in the early boot code from the
generic RSDP path, and then copying the command line RSDP into boot
params in the kernel proper if lockdown is not enabled. If lockdown is
enabled and an RSDP is provided on the command line, this will only be
used when parsing SRAT (which shouldn't permit kernel code execution)
and will be ignored in the rest of the kernel.

(Modified by Matthew Garrett in order to handle the early boot RSDP
environment)

Signed-off-by: Josh Boyer &lt;jwboyer@redhat.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Matthew Garrett &lt;mjg59@google.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
cc: Dave Young &lt;dyoung@redhat.com&gt;
cc: linux-acpi@vger.kernel.org
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
</content>
</entry>
<entry>
<title>acpi: Use built-in RCU list checking for acpi_ioremaps list</title>
<updated>2019-08-13T21:29:22Z</updated>
<author>
<name>Joel Fernandes (Google)</name>
</author>
<published>2019-07-16T22:12:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bee6f87166e9c6b8d81a7570995bd637e8da485a'/>
<id>urn:sha1:bee6f87166e9c6b8d81a7570995bd637e8da485a</id>
<content type='text'>
This commit applies the consolidated list_for_each_entry_rcu() support
for lockdep conditions.

Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Joel Fernandes (Google) &lt;joel@joelfernandes.org&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ACPI: OSL: Make a W=1 kernel-doc warning go away</title>
<updated>2019-06-04T15:21:11Z</updated>
<author>
<name>Qian Cai</name>
</author>
<published>2019-06-03T20:28:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9fe51603d953419b8da74f455269eca8e6b84228'/>
<id>urn:sha1:9fe51603d953419b8da74f455269eca8e6b84228</id>
<content type='text'>
It appears that kernel-doc does not understand the return type *__ref,

drivers/acpi/osl.c:306: warning: cannot understand function prototype:
'void __iomem *__ref acpi_os_map_iomem(acpi_physical_address phys,
acpi_size size)

Signed-off-by: Qian Cai &lt;cai@lca.pw&gt;
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157</title>
<updated>2019-05-30T18:26:37Z</updated>
<author>
<name>Thomas Gleixner</name>
</author>
<published>2019-05-27T06:55:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c942fddf8793b2013be8c901b47d0a8dc02bf99f'/>
<id>urn:sha1:c942fddf8793b2013be8c901b47d0a8dc02bf99f</id>
<content type='text'>
Based on 3 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version this program is distributed in the
  hope that it will be useful but without any warranty without even
  the implied warranty of merchantability or fitness for a particular
  purpose see the gnu general public license for more details

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version [author] [kishon] [vijay] [abraham]
  [i] [kishon]@[ti] [com] this program is distributed in the hope that
  it will be useful but without any warranty without even the implied
  warranty of merchantability or fitness for a particular purpose see
  the gnu general public license for more details

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version [author] [graeme] [gregory]
  [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i]
  [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema]
  [hk] [hemahk]@[ti] [com] this program is distributed in the hope
  that it will be useful but without any warranty without even the
  implied warranty of merchantability or fitness for a particular
  purpose see the gnu general public license for more details

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 1105 file(s).

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Allison Randal &lt;allison@lohutok.net&gt;
Reviewed-by: Richard Fontana &lt;rfontana@redhat.com&gt;
Reviewed-by: Kate Stewart &lt;kstewart@linuxfoundation.org&gt;
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ACPICA: Remove PCI bits from ACPICA when CONFIG_PCI is unset</title>
<updated>2018-12-20T09:19:49Z</updated>
<author>
<name>Sinan Kaya</name>
</author>
<published>2018-12-19T22:46:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bd23fac3eaaa8bd79c02a2f139f68ac6424a9a7c'/>
<id>urn:sha1:bd23fac3eaaa8bd79c02a2f139f68ac6424a9a7c</id>
<content type='text'>
Allow ACPI to be built without PCI support in place.

Signed-off-by: Sinan Kaya &lt;okaya@kernel.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge branches 'acpi-property' and 'acpi-sbs'</title>
<updated>2018-10-18T10:37:51Z</updated>
<author>
<name>Rafael J. Wysocki</name>
</author>
<published>2018-10-18T10:37:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0a1875ad29ef6436da3c184494b509697c8e0cf7'/>
<id>urn:sha1:0a1875ad29ef6436da3c184494b509697c8e0cf7</id>
<content type='text'>
* acpi-property:
  ACPI / property: Switch to bitmap_zalloc()

* acpi-sbs:
  ACPI / SBS: Fix rare oops when removing modules
  ACPI / SBS: Fix GPE storm on recent MacBookPro's
</content>
</entry>
<entry>
<title>ACPI / OSL: Use 'jiffies' as the time bassis for acpi_os_get_timer()</title>
<updated>2018-10-18T07:23:16Z</updated>
<author>
<name>Bart Van Assche</name>
</author>
<published>2018-10-17T20:24:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=83b2348e2755db48fa8f40fdb791f366fabc0ba0'/>
<id>urn:sha1:83b2348e2755db48fa8f40fdb791f366fabc0ba0</id>
<content type='text'>
Since acpi_os_get_timer() may be called after the timer subsystem has
been suspended, use the jiffies counter instead of ktime_get(). This
patch avoids that the following warning is reported during hibernation:

WARNING: CPU: 0 PID: 612 at kernel/time/timekeeping.c:751 ktime_get+0x116/0x120
RIP: 0010:ktime_get+0x116/0x120
Call Trace:
 acpi_os_get_timer+0xe/0x30
 acpi_ds_exec_begin_control_op+0x175/0x1de
 acpi_ds_exec_begin_op+0x2c7/0x39a
 acpi_ps_create_op+0x573/0x5e4
 acpi_ps_parse_loop+0x349/0x1220
 acpi_ps_parse_aml+0x25b/0x6da
 acpi_ps_execute_method+0x327/0x41b
 acpi_ns_evaluate+0x4e9/0x6f5
 acpi_ut_evaluate_object+0xd9/0x2f2
 acpi_rs_get_method_data+0x8f/0x114
 acpi_walk_resources+0x122/0x1b6
 acpi_pci_link_get_current.isra.2+0x157/0x280
 acpi_pci_link_set+0x32f/0x4a0
 irqrouter_resume+0x58/0x80
 syscore_resume+0x84/0x380
 hibernation_snapshot+0x20c/0x4f0
 hibernate+0x22d/0x3a6
 state_store+0x99/0xa0
 kobj_attr_store+0x37/0x50
 sysfs_kf_write+0x87/0xa0
 kernfs_fop_write+0x1a5/0x240
 __vfs_write+0xd2/0x410
 vfs_write+0x101/0x250
 ksys_write+0xab/0x120
 __x64_sys_write+0x43/0x50
 do_syscall_64+0x71/0x220
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Fixes: 164a08cee135 (ACPICA: Dispatcher: Introduce timeout mechanism for infinite loop detection)
Reported-by: Fengguang Wu &lt;fengguang.wu@intel.com&gt;
References: https://lists.01.org/pipermail/lkp/2018-April/008406.html
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Cc: 4.16+ &lt;stable@vger.kernel.org&gt; # 4.16+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI / SBS: Fix rare oops when removing modules</title>
<updated>2018-10-08T06:41:35Z</updated>
<author>
<name>Ronald Tschalär</name>
</author>
<published>2018-10-01T02:53:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=757c968c442397f1249bb775a7c8c03842e3e0c7'/>
<id>urn:sha1:757c968c442397f1249bb775a7c8c03842e3e0c7</id>
<content type='text'>
There was a small race when removing the sbshc module where
smbus_alarm() had queued acpi_smbus_callback() for deferred execution
but it hadn't been run yet, so that when it did run hc had been freed
and the module unloaded, resulting in an invalid paging request.

A similar race existed when removing the sbs module with regards to
acpi_sbs_callback() (which is called from acpi_smbus_callback()).

We therefore need to ensure no callbacks are pending or executing before
the cleanups are done and the modules are removed.

Signed-off-by: Ronald TschalÃ¤r &lt;ronald@innovation.ch&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
</feed>
