linux-kernel - [RFC PATCH 0/3] ACPI: Flexible eject options to remove devices cautiously

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 27 Mar 2020 19:22:44 +0800
From:   Chester Lin <clin@...e.com>
To:     <rjw@...ysocki.net>, <lenb@...nel.org>, <robert.moore@...el.com>,
        <erik.kaneda@...el.com>, <gregkh@...uxfoundation.org>
CC:     <linux-acpi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <devel@...ica.org>, <jlee@...e.com>, <mhocko@...e.com>,
        Chester Lin <clin@...e.com>
Subject: [RFC PATCH 0/3] ACPI: Flexible eject options to remove devices cautiously

* This proposal is derived from https://lkml.org/lkml/2020/1/2/1401

Currently there are two ways to handle ACPI device ejection. When an eject
event happens on an ACPI container, the kernel sends a KOBJ_CHANGE event to
userland and userland has to deal with offline operation. For other device
types, acpi_scan_try_to_offline() is called and it tries to put target
device(s) offline and then removes all nodes once they are all offline.

However we found that sometimes applications could intensively access
resources on ejectable devices therefore they could have risk if ejection
suddenly happens and removes devices without any notification. In stead
of executing the offline callbakcs directly, I want to introduce an
additional approach, which uses 'request_offline' attributes to remind
the kernel to notify userland that some devices have been planning to be
removed, so the applications running on those targets can be prepared and
determine when offline tasks should be done based on current workload.

This approach is disabled by default so it will not affect systems which
still use the original way. Once it's enabled, the kernel will only
send change events as offline requests of target nodes to userland, so
firmware or userspace callers who raise eject requests will still have to
re-trigger eject events if necessary because the kernel will not track all
targets' offline status actively. However, I still add an 'auto_eject'
attribute for userland if it's required to periodically schedule an eject
event until the target has been removed.

To ensure that eject function can work properly since normal users might
not have their own offline/online handling, I would propose a generic udev
rule to systemd upstream as default in order to deal with change events
and take offline/online actions accordingly:

*Example: 80-acpi-hotplug-eject.rules
------------------------------------------------
# Generic rules for handling ACPI hotplug eject.

SUBSYSTEM=="*", ACTION=="change", ENV{EVENT}=="offline", ATTR{online}=="1", \
DEVPATH=="*", ATTR{online}="0"

SUBSYSTEM=="*", ACTION=="change", ENV{EVENT}=="online", ATTR{online}=="0", \
DEVPATH=="*", ATTR{online}="1"
------------------------------------------------

Chester Lin (3):
  ACPI: scan: add userland notification while handling eject events
  ACPI: scan: add cancel_eject and auto_eject attributes
  ACPI: scan: add a request_offline_recursive attribute

 Documentation/ABI/testing/sysfs-bus-acpi |  43 +++++++
 drivers/acpi/device_sysfs.c              | 154 ++++++++++++++++++++++-
 drivers/acpi/internal.h                  |   4 +-
 drivers/acpi/osl.c                       |  37 ++++--
 drivers/acpi/scan.c                      | 108 +++++++++++++++-
 include/acpi/acpi_bus.h                  |   8 ++
 6 files changed, 339 insertions(+), 15 deletions(-)

-- 
2.24.0