* Re: [PATCH 2/3] x86: Move CPU feature test out of uaccess region
From: Marco Elver @ 2019-06-03 9:03 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Peter Zijlstra, Andrey Ryabinin, Dmitry Vyukov,
Alexander Potapenko, Andrey Konovalov, Mark Rutland,
Jonathan Corbet, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
the arch/x86 maintainers, Arnd Bergmann, Josh Poimboeuf,
open list:DOCUMENTATION, LKML, linux-arch, kasan-dev
In-Reply-To: <3B49EF08-147F-451C-AA5B-FC4E1B8568EE@zytor.com>
Thanks for the clarification.
I found that static_cpu_has was replaced by static_cpu_has_safe:
https://lkml.org/lkml/2016/1/24/29 -- so is it fair to assume that
both are equally safe at this point?
I have sent a follow-up patch which uses static_cpu_has:
http://lkml.kernel.org/r/20190531150828.157832-3-elver@google.com
Many thanks!
-- Marco
On Sat, 1 Jun 2019 at 03:13, <hpa@zytor.com> wrote:
>
> On May 31, 2019 2:57:36 AM PDT, Marco Elver <elver@google.com> wrote:
> >On Wed, 29 May 2019 at 16:29, <hpa@zytor.com> wrote:
> >>
> >> On May 29, 2019 7:15:00 AM PDT, Marco Elver <elver@google.com> wrote:
> >> >This patch is a pre-requisite for enabling KASAN bitops
> >> >instrumentation:
> >> >moves boot_cpu_has feature test out of the uaccess region, as
> >> >boot_cpu_has uses test_bit. With instrumentation, the KASAN check
> >would
> >> >otherwise be flagged by objtool.
> >> >
> >> >This approach is preferred over adding the explicit kasan_check_*
> >> >functions to the uaccess whitelist of objtool, as the case here
> >appears
> >> >to be the only one.
> >> >
> >> >Signed-off-by: Marco Elver <elver@google.com>
> >> >---
> >> >v1:
> >> >* This patch replaces patch: 'tools/objtool: add kasan_check_* to
> >> > uaccess whitelist'
> >> >---
> >> > arch/x86/ia32/ia32_signal.c | 9 ++++++++-
> >> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >> >
> >> >diff --git a/arch/x86/ia32/ia32_signal.c
> >b/arch/x86/ia32/ia32_signal.c
> >> >index 629d1ee05599..12264e3c9c43 100644
> >> >--- a/arch/x86/ia32/ia32_signal.c
> >> >+++ b/arch/x86/ia32/ia32_signal.c
> >> >@@ -333,6 +333,7 @@ int ia32_setup_rt_frame(int sig, struct ksignal
> >> >*ksig,
> >> > void __user *restorer;
> >> > int err = 0;
> >> > void __user *fpstate = NULL;
> >> >+ bool has_xsave;
> >> >
> >> > /* __copy_to_user optimizes that into a single 8 byte store
> >*/
> >> > static const struct {
> >> >@@ -352,13 +353,19 @@ int ia32_setup_rt_frame(int sig, struct
> >ksignal
> >> >*ksig,
> >> > if (!access_ok(frame, sizeof(*frame)))
> >> > return -EFAULT;
> >> >
> >> >+ /*
> >> >+ * Move non-uaccess accesses out of uaccess region if not
> >strictly
> >> >+ * required; this also helps avoid objtool flagging these
> >accesses
> >> >with
> >> >+ * instrumentation enabled.
> >> >+ */
> >> >+ has_xsave = boot_cpu_has(X86_FEATURE_XSAVE);
> >> > put_user_try {
> >> > put_user_ex(sig, &frame->sig);
> >> > put_user_ex(ptr_to_compat(&frame->info),
> >&frame->pinfo);
> >> > put_user_ex(ptr_to_compat(&frame->uc), &frame->puc);
> >> >
> >> > /* Create the ucontext. */
> >> >- if (boot_cpu_has(X86_FEATURE_XSAVE))
> >> >+ if (has_xsave)
> >> > put_user_ex(UC_FP_XSTATE,
> >&frame->uc.uc_flags);
> >> > else
> >> > put_user_ex(0, &frame->uc.uc_flags);
> >>
> >> This was meant to use static_cpu_has(). Why did that get dropped?
> >
> >I couldn't find any mailing list thread referring to why this doesn't
> >use static_cpu_has, do you have any background?
> >
> >static_cpu_has also solves the UACCESS warning.
> >
> >If you confirm it is safe to change to static_cpu_has(), I will change
> >this patch. Note that I should then also change
> >arch/x86/kernel/signal.c to mirror the change for 32bit (although
> >KASAN is not supported for 32bit x86).
> >
> >Thanks,
> >-- Marco
>
> I believe at some point the intent was that boot_cpu_has() was safer and could be used everywhere.
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* [char-misc-next 0/7] mei: docs: move documentation under driver-api
From: Tomas Winkler @ 2019-06-03 9:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Alexander Usyskin, linux-kernel, Tomas Winkler, Jonathan Corbet,
linux-doc
Move mei documentation under driver-api, convert the docs to rst,
fix the outdated information, update broken links, and add new docs.
Tomas Winkler (7):
mei: docs: move documentation under driver-api
mei: docs: move iamt docs to a iamt.rst file
mei: docs: update mei documentation
mei: docs: update mei client bus documentation.
mei: docs: add a short description for nfc behind mei
mei: docs: add hdcp documentation
mei: docs: fix broken links in iamt documentation.
Documentation/driver-api/index.rst | 1 +
Documentation/driver-api/mei/hdcp.rst | 32 +++
Documentation/driver-api/mei/iamt.rst | 101 +++++++
Documentation/driver-api/mei/index.rst | 23 ++
.../driver-api/mei/mei-client-bus.rst | 168 +++++++++++
Documentation/driver-api/mei/mei.rst | 176 ++++++++++++
Documentation/driver-api/mei/nfc.rst | 28 ++
.../misc-devices/mei/mei-client-bus.txt | 141 ----------
Documentation/misc-devices/mei/mei.txt | 266 ------------------
MAINTAINERS | 2 +-
drivers/misc/mei/hdcp/mei_hdcp.c | 11 +-
11 files changed, 534 insertions(+), 415 deletions(-)
create mode 100644 Documentation/driver-api/mei/hdcp.rst
create mode 100644 Documentation/driver-api/mei/iamt.rst
create mode 100644 Documentation/driver-api/mei/index.rst
create mode 100644 Documentation/driver-api/mei/mei-client-bus.rst
create mode 100644 Documentation/driver-api/mei/mei.rst
create mode 100644 Documentation/driver-api/mei/nfc.rst
delete mode 100644 Documentation/misc-devices/mei/mei-client-bus.txt
delete mode 100644 Documentation/misc-devices/mei/mei.txt
--
2.20.1
^ permalink raw reply
* [char-misc-next 1/7] mei: docs: move documentation under driver-api
From: Tomas Winkler @ 2019-06-03 9:14 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Alexander Usyskin, linux-kernel, Tomas Winkler, Jonathan Corbet,
linux-doc
In-Reply-To: <20190603091406.28915-1-tomas.winkler@intel.com>
Move mei driver documentation under Documentation/driver-api/
Perform some minimal formating changes to produce correct sphinx rendering
and add index.rst
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
Documentation/driver-api/index.rst | 1 +
Documentation/driver-api/mei/index.rst | 22 +++
.../mei/mei-client-bus.rst} | 135 ++++++++++--------
.../mei/mei.txt => driver-api/mei/mei.rst} | 30 +---
MAINTAINERS | 2 +-
5 files changed, 104 insertions(+), 86 deletions(-)
create mode 100644 Documentation/driver-api/mei/index.rst
rename Documentation/{misc-devices/mei/mei-client-bus.txt => driver-api/mei/mei-client-bus.rst} (54%)
rename Documentation/{misc-devices/mei/mei.txt => driver-api/mei/mei.rst} (94%)
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index d26308af6036..0dbaa987aa11 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -42,6 +42,7 @@ available subsections can be seen below.
target
mtdnand
miscellaneous
+ mei/index
w1
rapidio
s390-drivers
diff --git a/Documentation/driver-api/mei/index.rst b/Documentation/driver-api/mei/index.rst
new file mode 100644
index 000000000000..35c1117d8366
--- /dev/null
+++ b/Documentation/driver-api/mei/index.rst
@@ -0,0 +1,22 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: <isonum.txt>
+
+===================================================
+Intel(R) Management Engine Interface (Intel(R) MEI)
+===================================================
+
+**Copyright** |copy| 2019 Intel Corporation
+
+
+.. only:: html
+
+ .. class:: toc-title
+
+ Table of Contents
+
+.. toctree::
+ :maxdepth: 2
+
+ mei
+ mei-client-bus
diff --git a/Documentation/misc-devices/mei/mei-client-bus.txt b/Documentation/driver-api/mei/mei-client-bus.rst
similarity index 54%
rename from Documentation/misc-devices/mei/mei-client-bus.txt
rename to Documentation/driver-api/mei/mei-client-bus.rst
index 743be4ec8989..a26a85453bdf 100644
--- a/Documentation/misc-devices/mei/mei-client-bus.txt
+++ b/Documentation/driver-api/mei/mei-client-bus.rst
@@ -1,3 +1,6 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================================
Intel(R) Management Engine (ME) Client bus API
==============================================
@@ -22,22 +25,24 @@ MEI CL bus API
A driver implementation for an MEI Client is very similar to existing bus
based device drivers. The driver registers itself as an MEI CL bus driver through
-the mei_cl_driver structure:
+the ``struct mei_cl_driver`` structure:
+
+.. code-block:: C
-struct mei_cl_driver {
- struct device_driver driver;
- const char *name;
+ struct mei_cl_driver {
+ struct device_driver driver;
+ const char *name;
- const struct mei_cl_device_id *id_table;
+ const struct mei_cl_device_id *id_table;
- int (*probe)(struct mei_cl_device *dev, const struct mei_cl_id *id);
- int (*remove)(struct mei_cl_device *dev);
-};
+ int (*probe)(struct mei_cl_device *dev, const struct mei_cl_id *id);
+ int (*remove)(struct mei_cl_device *dev);
+ };
-struct mei_cl_id {
- char name[MEI_NAME_SIZE];
- kernel_ulong_t driver_info;
-};
+ struct mei_cl_id {
+ char name[MEI_NAME_SIZE];
+ kernel_ulong_t driver_info;
+ };
The mei_cl_id structure allows the driver to bind itself against a device name.
@@ -61,58 +66,62 @@ Example
As a theoretical example let's pretend the ME comes with a "contact" NFC IP.
The driver init and exit routines for this device would look like:
-#define CONTACT_DRIVER_NAME "contact"
+.. code-block:: C
-static struct mei_cl_device_id contact_mei_cl_tbl[] = {
- { CONTACT_DRIVER_NAME, },
+ #define CONTACT_DRIVER_NAME "contact"
- /* required last entry */
- { }
-};
-MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl);
+ static struct mei_cl_device_id contact_mei_cl_tbl[] = {
+ { CONTACT_DRIVER_NAME, },
-static struct mei_cl_driver contact_driver = {
- .id_table = contact_mei_tbl,
- .name = CONTACT_DRIVER_NAME,
+ /* required last entry */
+ { }
+ };
+ MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl);
- .probe = contact_probe,
- .remove = contact_remove,
-};
+ static struct mei_cl_driver contact_driver = {
+ .id_table = contact_mei_tbl,
+ .name = CONTACT_DRIVER_NAME,
-static int contact_init(void)
-{
- int r;
+ .probe = contact_probe,
+ .remove = contact_remove,
+ };
- r = mei_cl_driver_register(&contact_driver);
- if (r) {
- pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n");
- return r;
- }
+ static int contact_init(void)
+ {
+ int r;
+
+ r = mei_cl_driver_register(&contact_driver);
+ if (r) {
+ pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n");
+ return r;
+ }
- return 0;
-}
+ return 0;
+ }
-static void __exit contact_exit(void)
-{
- mei_cl_driver_unregister(&contact_driver);
-}
+ static void __exit contact_exit(void)
+ {
+ mei_cl_driver_unregister(&contact_driver);
+ }
-module_init(contact_init);
-module_exit(contact_exit);
+ module_init(contact_init);
+ module_exit(contact_exit);
And the driver's simplified probe routine would look like that:
-int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id)
-{
- struct contact_driver *contact;
+.. code-block:: C
- [...]
- mei_cl_enable_device(dev);
+ int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id)
+ {
+ struct contact_driver *contact;
- mei_cl_register_event_cb(dev, contact_event_cb, contact);
+ [...]
+ mei_cl_enable_device(dev);
- return 0;
-}
+ mei_cl_register_event_cb(dev, contact_event_cb, contact);
+
+ return 0;
+ }
In the probe routine the driver first enable the MEI device and then registers
an ME bus event handler which is as close as it can get to registering a
@@ -122,20 +131,22 @@ the pending events:
#define MAX_NFC_PAYLOAD 128
-static void contact_event_cb(struct mei_cl_device *dev, u32 events,
- void *context)
-{
- struct contact_driver *contact = context;
+.. code-block:: C
+
+ static void contact_event_cb(struct mei_cl_device *dev, u32 events,
+ void *context)
+ {
+ struct contact_driver *contact = context;
- if (events & BIT(MEI_EVENT_RX)) {
- u8 payload[MAX_NFC_PAYLOAD];
- int payload_size;
+ if (events & BIT(MEI_EVENT_RX)) {
+ u8 payload[MAX_NFC_PAYLOAD];
+ int payload_size;
- payload_size = mei_recv(dev, payload, MAX_NFC_PAYLOAD);
- if (payload_size <= 0)
- return;
+ payload_size = mei_recv(dev, payload, MAX_NFC_PAYLOAD);
+ if (payload_size <= 0)
+ return;
- /* Hook to the NFC subsystem */
- nfc_hci_recv_frame(contact->hdev, payload, payload_size);
+ /* Hook to the NFC subsystem */
+ nfc_hci_recv_frame(contact->hdev, payload, payload_size);
+ }
}
-}
diff --git a/Documentation/misc-devices/mei/mei.txt b/Documentation/driver-api/mei/mei.rst
similarity index 94%
rename from Documentation/misc-devices/mei/mei.txt
rename to Documentation/driver-api/mei/mei.rst
index 2b80a0cd621f..5aa3a5e6496a 100644
--- a/Documentation/misc-devices/mei/mei.txt
+++ b/Documentation/driver-api/mei/mei.rst
@@ -1,5 +1,4 @@
-Intel(R) Management Engine Interface (Intel(R) MEI)
-===================================================
+.. SPDX-License-Identifier: GPL-2.0
Introduction
============
@@ -70,6 +69,8 @@ user to access it.
A code snippet for an application communicating with Intel AMTHI client:
+.. code-block:: C
+
struct mei_connect_client_data data;
fd = open(MEI_DEVICE);
@@ -93,8 +94,8 @@ A code snippet for an application communicating with Intel AMTHI client:
close(fd);
-IOCTL
-=====
+IOCTLs
+======
The Intel MEI Driver supports the following IOCTL commands:
IOCTL_MEI_CONNECT_CLIENT Connect to firmware Feature (client).
@@ -114,8 +115,7 @@ The Intel MEI Driver supports the following IOCTL commands:
error returns:
EINVAL Wrong IOCTL Number
- ENODEV Device or Connection is not initialized or ready.
- (e.g. Wrong UUID)
+ ENODEV Device or Connection is not initialized or ready. (e.g. Wrong UUID)
ENOMEM Unable to allocate memory to client internal data.
EFAULT Fatal Error (e.g. Unable to access user input data)
EBUSY Connection Already Open
@@ -241,26 +241,10 @@ watchdog is 120 seconds.
If the Intel AMT is not enabled in the firmware then the watchdog client won't enumerate
on the me client bus and watchdog devices won't be exposed.
-
Supported Chipsets
==================
+82X38/X48 Express and newer
-7 Series Chipset Family
-6 Series Chipset Family
-5 Series Chipset Family
-4 Series Chipset Family
-Mobile 4 Series Chipset Family
-ICH9
-82946GZ/GL
-82G35 Express
-82Q963/Q965
-82P965/G965
-Mobile PM965/GM965
-Mobile GME965/GLE960
-82Q35 Express
-82G33/G31/P35/P31 Express
-82Q33 Express
-82X38/X48 Express
---
linux-mei@linux.intel.com
diff --git a/MAINTAINERS b/MAINTAINERS
index 5cfbea4ce575..bfe48cbea84c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8021,7 +8021,7 @@ F: include/uapi/linux/mei.h
F: include/linux/mei_cl_bus.h
F: drivers/misc/mei/*
F: drivers/watchdog/mei_wdt.c
-F: Documentation/misc-devices/mei/*
+F: Documentation/driver-api/mei/*
F: samples/mei/*
INTEL MENLOW THERMAL DRIVER
--
2.20.1
^ permalink raw reply related
* [char-misc-next 2/7] mei: docs: move iamt docs to a iamt.rst file
From: Tomas Winkler @ 2019-06-03 9:14 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Alexander Usyskin, linux-kernel, Tomas Winkler, Jonathan Corbet,
linux-doc
In-Reply-To: <20190603091406.28915-1-tomas.winkler@intel.com>
Move intel amt documentation to a seprate file.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
Documentation/driver-api/mei/iamt.rst | 106 +++++++++++++++++++++++++
Documentation/driver-api/mei/index.rst | 1 +
Documentation/driver-api/mei/mei.rst | 100 -----------------------
3 files changed, 107 insertions(+), 100 deletions(-)
create mode 100644 Documentation/driver-api/mei/iamt.rst
diff --git a/Documentation/driver-api/mei/iamt.rst b/Documentation/driver-api/mei/iamt.rst
new file mode 100644
index 000000000000..6dcf5b16e958
--- /dev/null
+++ b/Documentation/driver-api/mei/iamt.rst
@@ -0,0 +1,106 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Intel(R) Active Management Technology (Intel AMT)
+=================================================
+
+Prominent usage of the Intel ME Interface is to communicate with Intel(R)
+Active Management Technology (Intel AMT) implemented in firmware running on
+the Intel ME.
+
+Intel AMT provides the ability to manage a host remotely out-of-band (OOB)
+even when the operating system running on the host processor has crashed or
+is in a sleep state.
+
+Some examples of Intel AMT usage are:
+ - Monitoring hardware state and platform components
+ - Remote power off/on (useful for green computing or overnight IT
+ maintenance)
+ - OS updates
+ - Storage of useful platform information such as software assets
+ - Built-in hardware KVM
+ - Selective network isolation of Ethernet and IP protocol flows based
+ on policies set by a remote management console
+ - IDE device redirection from remote management console
+
+Intel AMT (OOB) communication is based on SOAP (deprecated
+starting with Release 6.0) over HTTP/S or WS-Management protocol over
+HTTP/S that are received from a remote management console application.
+
+For more information about Intel AMT:
+http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
+
+
+Intel AMT Applications
+======================
+
+ 1) Intel Local Management Service (Intel LMS)
+
+ Applications running locally on the platform communicate with Intel AMT Release
+ 2.0 and later releases in the same way that network applications do via SOAP
+ over HTTP (deprecated starting with Release 6.0) or with WS-Management over
+ SOAP over HTTP. This means that some Intel AMT features can be accessed from a
+ local application using the same network interface as a remote application
+ communicating with Intel AMT over the network.
+
+ When a local application sends a message addressed to the local Intel AMT host
+ name, the Intel LMS, which listens for traffic directed to the host name,
+ intercepts the message and routes it to the Intel MEI.
+ For more information:
+ http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
+ Under "About Intel AMT" => "Local Access"
+
+ For downloading Intel LMS:
+ http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
+
+ The Intel LMS opens a connection using the Intel MEI driver to the Intel LMS
+ firmware feature using a defined UUID and then communicates with the feature
+ using a protocol called Intel AMT Port Forwarding Protocol (Intel APF protocol).
+ The protocol is used to maintain multiple sessions with Intel AMT from a
+ single application.
+
+ See the protocol specification in the Intel AMT Software Development Kit (SDK)
+ http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
+ Under "SDK Resources" => "Intel(R) vPro(TM) Gateway (MPS)"
+ => "Information for Intel(R) vPro(TM) Gateway Developers"
+ => "Description of the Intel AMT Port Forwarding (APF) Protocol"
+
+ 2) Intel AMT Remote configuration using a Local Agent
+
+ A Local Agent enables IT personnel to configure Intel AMT out-of-the-box
+ without requiring installing additional data to enable setup. The remote
+ configuration process may involve an ISV-developed remote configuration
+ agent that runs on the host.
+ For more information:
+ http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
+ Under "Setup and Configuration of Intel AMT" =>
+ "SDK Tools Supporting Setup and Configuration" =>
+ "Using the Local Agent Sample"
+
+ An open source Intel AMT configuration utility, implementing a local agent
+ that accesses the Intel MEI driver, can be found here:
+ http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
+
+
+Intel AMT OS Health Watchdog
+============================
+
+The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog.
+Whenever the OS hangs or crashes, Intel AMT will send an event
+to any subscriber to this event. This mechanism means that
+IT knows when a platform crashes even when there is a hard failure on the host.
+
+The Intel AMT Watchdog is composed of two parts:
+ 1) Firmware feature - receives the heartbeats
+ and sends an event when the heartbeats stop.
+ 2) Intel MEI iAMT watchdog driver - connects to the watchdog feature,
+ configures the watchdog and sends the heartbeats.
+
+The Intel iAMT watchdog MEI driver uses the kernel watchdog API to configure
+the Intel AMT Watchdog and to send heartbeats to it. The default timeout of the
+watchdog is 120 seconds.
+
+If the Intel AMT is not enabled in the firmware then the watchdog client won't enumerate
+on the me client bus and watchdog devices won't be exposed.
+
+---
+linux-mei@linux.intel.com
diff --git a/Documentation/driver-api/mei/index.rst b/Documentation/driver-api/mei/index.rst
index 35c1117d8366..d261afac6852 100644
--- a/Documentation/driver-api/mei/index.rst
+++ b/Documentation/driver-api/mei/index.rst
@@ -20,3 +20,4 @@ Intel(R) Management Engine Interface (Intel(R) MEI)
mei
mei-client-bus
+ iamt
diff --git a/Documentation/driver-api/mei/mei.rst b/Documentation/driver-api/mei/mei.rst
index 5aa3a5e6496a..c7f10a4b46ff 100644
--- a/Documentation/driver-api/mei/mei.rst
+++ b/Documentation/driver-api/mei/mei.rst
@@ -17,33 +17,6 @@ Each Intel ME feature (Intel ME Client) is addressed by a GUID/UUID and
each client has its own protocol. The protocol is message-based with a
header and payload up to 512 bytes.
-Prominent usage of the Intel ME Interface is to communicate with Intel(R)
-Active Management Technology (Intel AMT) implemented in firmware running on
-the Intel ME.
-
-Intel AMT provides the ability to manage a host remotely out-of-band (OOB)
-even when the operating system running on the host processor has crashed or
-is in a sleep state.
-
-Some examples of Intel AMT usage are:
- - Monitoring hardware state and platform components
- - Remote power off/on (useful for green computing or overnight IT
- maintenance)
- - OS updates
- - Storage of useful platform information such as software assets
- - Built-in hardware KVM
- - Selective network isolation of Ethernet and IP protocol flows based
- on policies set by a remote management console
- - IDE device redirection from remote management console
-
-Intel AMT (OOB) communication is based on SOAP (deprecated
-starting with Release 6.0) over HTTP/S or WS-Management protocol over
-HTTP/S that are received from a remote management console application.
-
-For more information about Intel AMT:
-http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
-
-
Intel MEI Driver
================
@@ -169,82 +142,9 @@ The Intel MEI Driver supports the following IOCTL commands:
in order to receive an event
-Intel ME Applications
-=====================
-
- 1) Intel Local Management Service (Intel LMS)
-
- Applications running locally on the platform communicate with Intel AMT Release
- 2.0 and later releases in the same way that network applications do via SOAP
- over HTTP (deprecated starting with Release 6.0) or with WS-Management over
- SOAP over HTTP. This means that some Intel AMT features can be accessed from a
- local application using the same network interface as a remote application
- communicating with Intel AMT over the network.
-
- When a local application sends a message addressed to the local Intel AMT host
- name, the Intel LMS, which listens for traffic directed to the host name,
- intercepts the message and routes it to the Intel MEI.
- For more information:
- http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
- Under "About Intel AMT" => "Local Access"
-
- For downloading Intel LMS:
- http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
-
- The Intel LMS opens a connection using the Intel MEI driver to the Intel LMS
- firmware feature using a defined UUID and then communicates with the feature
- using a protocol called Intel AMT Port Forwarding Protocol (Intel APF protocol).
- The protocol is used to maintain multiple sessions with Intel AMT from a
- single application.
-
- See the protocol specification in the Intel AMT Software Development Kit (SDK)
- http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
- Under "SDK Resources" => "Intel(R) vPro(TM) Gateway (MPS)"
- => "Information for Intel(R) vPro(TM) Gateway Developers"
- => "Description of the Intel AMT Port Forwarding (APF) Protocol"
-
- 2) Intel AMT Remote configuration using a Local Agent
-
- A Local Agent enables IT personnel to configure Intel AMT out-of-the-box
- without requiring installing additional data to enable setup. The remote
- configuration process may involve an ISV-developed remote configuration
- agent that runs on the host.
- For more information:
- http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
- Under "Setup and Configuration of Intel AMT" =>
- "SDK Tools Supporting Setup and Configuration" =>
- "Using the Local Agent Sample"
-
- An open source Intel AMT configuration utility, implementing a local agent
- that accesses the Intel MEI driver, can be found here:
- http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
-
-
-Intel AMT OS Health Watchdog
-============================
-
-The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog.
-Whenever the OS hangs or crashes, Intel AMT will send an event
-to any subscriber to this event. This mechanism means that
-IT knows when a platform crashes even when there is a hard failure on the host.
-
-The Intel AMT Watchdog is composed of two parts:
- 1) Firmware feature - receives the heartbeats
- and sends an event when the heartbeats stop.
- 2) Intel MEI iAMT watchdog driver - connects to the watchdog feature,
- configures the watchdog and sends the heartbeats.
-
-The Intel iAMT watchdog MEI driver uses the kernel watchdog API to configure
-the Intel AMT Watchdog and to send heartbeats to it. The default timeout of the
-watchdog is 120 seconds.
-
-If the Intel AMT is not enabled in the firmware then the watchdog client won't enumerate
-on the me client bus and watchdog devices won't be exposed.
Supported Chipsets
==================
82X38/X48 Express and newer
-
----
linux-mei@linux.intel.com
--
2.20.1
^ permalink raw reply related
* [char-misc-next 3/7] mei: docs: update mei documentation
From: Tomas Winkler @ 2019-06-03 9:14 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Alexander Usyskin, linux-kernel, Tomas Winkler, Jonathan Corbet,
linux-doc
In-Reply-To: <20190603091406.28915-1-tomas.winkler@intel.com>
The mei driver went via multiple changes, update
the documentation and fix formatting.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
Documentation/driver-api/mei/mei.rst | 96 ++++++++++++++++++----------
1 file changed, 61 insertions(+), 35 deletions(-)
diff --git a/Documentation/driver-api/mei/mei.rst b/Documentation/driver-api/mei/mei.rst
index c7f10a4b46ff..c800d8e5f422 100644
--- a/Documentation/driver-api/mei/mei.rst
+++ b/Documentation/driver-api/mei/mei.rst
@@ -5,34 +5,32 @@ Introduction
The Intel Management Engine (Intel ME) is an isolated and protected computing
resource (Co-processor) residing inside certain Intel chipsets. The Intel ME
-provides support for computer/IT management features. The feature set
-depends on the Intel chipset SKU.
+provides support for computer/IT management and security features.
+The actual feature set depends on the Intel chipset SKU.
The Intel Management Engine Interface (Intel MEI, previously known as HECI)
is the interface between the Host and Intel ME. This interface is exposed
-to the host as a PCI device. The Intel MEI Driver is in charge of the
-communication channel between a host application and the Intel ME feature.
+to the host as a PCI device, actually multiple PCI devices might be exposed.
+The Intel MEI Driver is in charge of the communication channel between
+a host application and the Intel ME features.
-Each Intel ME feature (Intel ME Client) is addressed by a GUID/UUID and
+Each Intel ME feature, or Intel ME Client is addressed by a unique GUID and
each client has its own protocol. The protocol is message-based with a
-header and payload up to 512 bytes.
+header and payload up to maximal number of bytes advertised by the client,
+upon connection.
Intel MEI Driver
================
-The driver exposes a misc device called /dev/mei.
+The driver exposes a character device with device nodes /dev/meiX.
An application maintains communication with an Intel ME feature while
-/dev/mei is open. The binding to a specific feature is performed by calling
-MEI_CONNECT_CLIENT_IOCTL, which passes the desired UUID.
+/dev/meiX is open. The binding to a specific feature is performed by calling
+:c:macro:`MEI_CONNECT_CLIENT_IOCTL`, which passes the desired GUID.
The number of instances of an Intel ME feature that can be opened
at the same time depends on the Intel ME feature, but most of the
features allow only a single instance.
-The Intel AMT Host Interface (Intel AMTHI) feature supports multiple
-simultaneous user connected applications. The Intel MEI driver
-handles this internally by maintaining request queues for the applications.
-
The driver is transparent to data that are passed between firmware feature
and host application.
@@ -40,6 +38,8 @@ Because some of the Intel ME features can change the system
configuration, the driver by default allows only a privileged
user to access it.
+The session is terminated calling :c:func:`close(int fd)`.
+
A code snippet for an application communicating with Intel AMTHI client:
.. code-block:: C
@@ -47,13 +47,13 @@ A code snippet for an application communicating with Intel AMTHI client:
struct mei_connect_client_data data;
fd = open(MEI_DEVICE);
- data.d.in_client_uuid = AMTHI_UUID;
+ data.d.in_client_uuid = AMTHI_GUID;
ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &data);
printf("Ver=%d, MaxLen=%ld\n",
- data.d.in_client_uuid.protocol_version,
- data.d.in_client_uuid.max_msg_length);
+ data.d.in_client_uuid.protocol_version,
+ data.d.in_client_uuid.max_msg_length);
[...]
@@ -67,60 +67,86 @@ A code snippet for an application communicating with Intel AMTHI client:
close(fd);
-IOCTLs
-======
+User space API
+
+IOCTLs:
+=======
The Intel MEI Driver supports the following IOCTL commands:
- IOCTL_MEI_CONNECT_CLIENT Connect to firmware Feature (client).
- usage:
- struct mei_connect_client_data clientData;
- ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &clientData);
+IOCTL_MEI_CONNECT_CLIENT
+-------------------------
+Connect to firmware Feature/Client.
+
+.. code-block:: none
+
+ Usage:
- inputs:
- mei_connect_client_data struct contain the following
- input field:
+ struct mei_connect_client_data client_data;
- in_client_uuid - UUID of the FW Feature that needs
+ ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &client_data);
+
+ Inputs:
+
+ struct mei_connect_client_data - contain the following
+ Input field:
+
+ in_client_uuid - GUID of the FW Feature that needs
to connect to.
- outputs:
+ Outputs:
out_client_properties - Client Properties: MTU and Protocol Version.
- error returns:
+ Error returns:
+
+ ENOTTY No such client (i.e. wrong GUID) or connection is not allowed.
EINVAL Wrong IOCTL Number
- ENODEV Device or Connection is not initialized or ready. (e.g. Wrong UUID)
+ ENODEV Device or Connection is not initialized or ready.
ENOMEM Unable to allocate memory to client internal data.
EFAULT Fatal Error (e.g. Unable to access user input data)
EBUSY Connection Already Open
+:Note:
max_msg_length (MTU) in client properties describes the maximum
data that can be sent or received. (e.g. if MTU=2K, can send
requests up to bytes 2k and received responses up to 2k bytes).
- IOCTL_MEI_NOTIFY_SET: enable or disable event notifications
+
+IOCTL_MEI_NOTIFY_SET
+---------------------
+Enable or disable event notifications.
+
+
+.. code-block:: none
Usage:
+
uint32_t enable;
+
ioctl(fd, IOCTL_MEI_NOTIFY_SET, &enable);
- Inputs:
+
uint32_t enable = 1;
or
uint32_t enable[disable] = 0;
Error returns:
+
+
EINVAL Wrong IOCTL Number
ENODEV Device is not initialized or the client not connected
ENOMEM Unable to allocate memory to client internal data.
EFAULT Fatal Error (e.g. Unable to access user input data)
EOPNOTSUPP if the device doesn't support the feature
+:Note:
The client must be connected in order to enable notification events
- IOCTL_MEI_NOTIFY_GET : retrieve event
+IOCTL_MEI_NOTIFY_GET
+--------------------
+Retrieve event
+
+.. code-block:: none
Usage:
uint32_t event;
@@ -137,7 +163,7 @@ The Intel MEI Driver supports the following IOCTL commands:
EFAULT Fatal Error (e.g. Unable to access user input data)
EOPNOTSUPP if the device doesn't support the feature
+:Note:
The client must be connected and event notification has to be enabled
in order to receive an event
--
2.20.1
^ permalink raw reply related
* [char-misc-next 4/7] mei: docs: update mei client bus documentation.
From: Tomas Winkler @ 2019-06-03 9:14 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Alexander Usyskin, linux-kernel, Tomas Winkler, Jonathan Corbet,
linux-doc
In-Reply-To: <20190603091406.28915-1-tomas.winkler@intel.com>
The mei client bus API has changed significantly from
time it was documented, and had required update.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
.../driver-api/mei/mei-client-bus.rst | 162 +++++++++---------
1 file changed, 85 insertions(+), 77 deletions(-)
diff --git a/Documentation/driver-api/mei/mei-client-bus.rst b/Documentation/driver-api/mei/mei-client-bus.rst
index a26a85453bdf..7310dd45c484 100644
--- a/Documentation/driver-api/mei/mei-client-bus.rst
+++ b/Documentation/driver-api/mei/mei-client-bus.rst
@@ -8,13 +8,13 @@ Intel(R) Management Engine (ME) Client bus API
Rationale
=========
-MEI misc character device is useful for dedicated applications to send and receive
+The MEI character device is useful for dedicated applications to send and receive
data to the many FW appliance found in Intel's ME from the user space.
-However for some of the ME functionalities it make sense to leverage existing software
+However, for some of the ME functionalities it makes sense to leverage existing software
stack and expose them through existing kernel subsystems.
In order to plug seamlessly into the kernel device driver model we add kernel virtual
-bus abstraction on top of the MEI driver. This allows implementing linux kernel drivers
+bus abstraction on top of the MEI driver. This allows implementing Linux kernel drivers
for the various MEI features as a stand alone entities found in their respective subsystem.
Existing device drivers can even potentially be re-used by adding an MEI CL bus layer to
the existing code.
@@ -23,9 +23,9 @@ the existing code.
MEI CL bus API
==============
-A driver implementation for an MEI Client is very similar to existing bus
+A driver implementation for an MEI Client is very similar to any other existing bus
based device drivers. The driver registers itself as an MEI CL bus driver through
-the ``struct mei_cl_driver`` structure:
+the ``struct mei_cl_driver`` structure defined in :file:`include/linux/mei_cl_bus.c`
.. code-block:: C
@@ -39,25 +39,38 @@ the ``struct mei_cl_driver`` structure:
int (*remove)(struct mei_cl_device *dev);
};
- struct mei_cl_id {
- char name[MEI_NAME_SIZE];
+
+
+The mei_cl_device_id structure defined in :file:`include/linux/mod_devicetable.h` allows a
+driver to bind itself against a device name.
+
+.. code-block:: C
+
+ struct mei_cl_device_id {
+ char name[MEI_CL_NAME_SIZE];
+ uuid_le uuid;
+ __u8 version;
kernel_ulong_t driver_info;
};
-The mei_cl_id structure allows the driver to bind itself against a device name.
+To actually register a driver on the ME Client bus one must call the :c:func:`mei_cl_add_driver`
+API. This is typically called at module initialization time.
+
+Once the driver is registered and bound to the device, a driver will typically
+try to do some I/O on this bus and this should be done through the :c:func:`mei_cl_send`
+and :c:func:`mei_cl_recv` functions. More detailed information is in :ref:`api` section.
+
+In order for a driver to be notified about pending traffic or event, the driver
+should register a callback via :c:func:`mei_cl_devev_register_rx_cb` and
+:c:func:`mei_cldev_register_notify_cb` function respectively.
-To actually register a driver on the ME Client bus one must call the mei_cl_add_driver()
-API. This is typically called at module init time.
+.. _api:
+
+API:
+----
+.. kernel-doc:: drivers/misc/mei/bus.c
+ :export: drivers/misc/mei/bus.c
-Once registered on the ME Client bus, a driver will typically try to do some I/O on
-this bus and this should be done through the mei_cl_send() and mei_cl_recv()
-routines. The latter is synchronous (blocks and sleeps until data shows up).
-In order for drivers to be notified of pending events waiting for them (e.g.
-an Rx event) they can register an event handler through the
-mei_cl_register_event_cb() routine. Currently only the MEI_EVENT_RX event
-will trigger an event handler call and the driver implementation is supposed
-to call mei_recv() from the event handler in order to fetch the pending
-received buffers.
Example
@@ -68,85 +81,80 @@ The driver init and exit routines for this device would look like:
.. code-block:: C
- #define CONTACT_DRIVER_NAME "contact"
+ #define CONTACT_DRIVER_NAME "contact"
- static struct mei_cl_device_id contact_mei_cl_tbl[] = {
- { CONTACT_DRIVER_NAME, },
+ static struct mei_cl_device_id contact_mei_cl_tbl[] = {
+ { CONTACT_DRIVER_NAME, },
- /* required last entry */
- { }
- };
- MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl);
+ /* required last entry */
+ { }
+ };
+ MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl);
- static struct mei_cl_driver contact_driver = {
- .id_table = contact_mei_tbl,
- .name = CONTACT_DRIVER_NAME,
+ static struct mei_cl_driver contact_driver = {
+ .id_table = contact_mei_tbl,
+ .name = CONTACT_DRIVER_NAME,
- .probe = contact_probe,
- .remove = contact_remove,
- };
+ .probe = contact_probe,
+ .remove = contact_remove,
+ };
- static int contact_init(void)
- {
- int r;
+ static int contact_init(void)
+ {
+ int r;
- r = mei_cl_driver_register(&contact_driver);
- if (r) {
- pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n");
- return r;
- }
+ r = mei_cl_driver_register(&contact_driver);
+ if (r) {
+ pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n");
+ return r;
+ }
- return 0;
- }
+ return 0;
+ }
- static void __exit contact_exit(void)
- {
- mei_cl_driver_unregister(&contact_driver);
- }
+ static void __exit contact_exit(void)
+ {
+ mei_cl_driver_unregister(&contact_driver);
+ }
- module_init(contact_init);
- module_exit(contact_exit);
+ module_init(contact_init);
+ module_exit(contact_exit);
And the driver's simplified probe routine would look like that:
.. code-block:: C
- int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id)
- {
- struct contact_driver *contact;
+ int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id)
+ {
+ [...]
+ mei_cldev_enable(dev);
- [...]
- mei_cl_enable_device(dev);
+ mei_cldev_register_rx_cb(dev, contact_rx_cb);
- mei_cl_register_event_cb(dev, contact_event_cb, contact);
-
- return 0;
- }
+ return 0;
+ }
In the probe routine the driver first enable the MEI device and then registers
-an ME bus event handler which is as close as it can get to registering a
-threaded IRQ handler.
-The handler implementation will typically call some I/O routine depending on
-the pending events:
-
-#define MAX_NFC_PAYLOAD 128
+an rx handler which is as close as it can get to registering a threaded IRQ handler.
+The handler implementation will typically call :c:func:`mei_cldev_recv` and then
+process received data.
.. code-block:: C
- static void contact_event_cb(struct mei_cl_device *dev, u32 events,
- void *context)
- {
- struct contact_driver *contact = context;
+ #define MAX_PAYLOAD 128
+ #define HDR_SIZE 4
+ static void conntact_rx_cb(struct mei_cl_device *cldev)
+ {
+ struct contact *c = mei_cldev_get_drvdata(cldev);
+ unsigned char payload[MAX_PAYLOAD];
+ ssize_t payload_sz;
+
+ payload_sz = mei_cldev_recv(cldev, payload, MAX_PAYLOAD)
+ if (reply_size < HDR_SIZE) {
+ return;
+ }
- if (events & BIT(MEI_EVENT_RX)) {
- u8 payload[MAX_NFC_PAYLOAD];
- int payload_size;
+ c->process_rx(payload);
- payload_size = mei_recv(dev, payload, MAX_NFC_PAYLOAD);
- if (payload_size <= 0)
- return;
+ }
- /* Hook to the NFC subsystem */
- nfc_hci_recv_frame(contact->hdev, payload, payload_size);
- }
- }
--
2.20.1
^ permalink raw reply related
* [char-misc-next 5/7] mei: docs: add a short description for nfc behind mei
From: Tomas Winkler @ 2019-06-03 9:14 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Alexander Usyskin, linux-kernel, Tomas Winkler, Jonathan Corbet,
linux-doc
In-Reply-To: <20190603091406.28915-1-tomas.winkler@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
Documentation/driver-api/mei/index.rst | 2 +-
.../driver-api/mei/mei-client-bus.rst | 7 +++++
Documentation/driver-api/mei/nfc.rst | 28 +++++++++++++++++++
3 files changed, 36 insertions(+), 1 deletion(-)
create mode 100644 Documentation/driver-api/mei/nfc.rst
diff --git a/Documentation/driver-api/mei/index.rst b/Documentation/driver-api/mei/index.rst
index d261afac6852..3a22b522ee78 100644
--- a/Documentation/driver-api/mei/index.rst
+++ b/Documentation/driver-api/mei/index.rst
@@ -16,7 +16,7 @@ Intel(R) Management Engine Interface (Intel(R) MEI)
Table of Contents
.. toctree::
- :maxdepth: 2
+ :maxdepth: 3
mei
mei-client-bus
diff --git a/Documentation/driver-api/mei/mei-client-bus.rst b/Documentation/driver-api/mei/mei-client-bus.rst
index 7310dd45c484..bfe28ebc3ca8 100644
--- a/Documentation/driver-api/mei/mei-client-bus.rst
+++ b/Documentation/driver-api/mei/mei-client-bus.rst
@@ -158,3 +158,10 @@ process received data.
}
+MEI Client Bus Drivers
+======================
+
+.. toctree::
+ :maxdepth: 2
+
+ nfc
diff --git a/Documentation/driver-api/mei/nfc.rst b/Documentation/driver-api/mei/nfc.rst
new file mode 100644
index 000000000000..b5b6fc96f85e
--- /dev/null
+++ b/Documentation/driver-api/mei/nfc.rst
@@ -0,0 +1,28 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+MEI NFC
+-------
+
+Some Intel 8 and 9 Serieses chipsets supports NFC devices connected behind
+the Intel Management Engine controller.
+MEI client bus exposes the NFC chips as NFC phy devices and enables
+binding with Microread and NXP PN544 NFC device driver from the Linux NFC
+subsystem.
+
+.. kernel-render:: DOT
+ :alt: MEI NFC digraph
+ :caption: **MEI NFC** Stack
+
+ digraph NFC {
+ cl_nfc -> me_cl_nfc;
+ "drivers/nfc/mei_phy" -> cl_nfc [lhead=bus];
+ "drivers/nfc/microread/mei" -> cl_nfc;
+ "drivers/nfc/microread/mei" -> "drivers/nfc/mei_phy";
+ "drivers/nfc/pn544/mei" -> cl_nfc;
+ "drivers/nfc/pn544/mei" -> "drivers/nfc/mei_phy";
+ "net/nfc" -> "drivers/nfc/microread/mei";
+ "net/nfc" -> "drivers/nfc/pn544/mei";
+ "neard" -> "net/nfc";
+ cl_nfc [label="mei/bus(nfc)"];
+ me_cl_nfc [label="me fw (nfc)"];
+ }
--
2.20.1
^ permalink raw reply related
* [char-misc-next 6/7] mei: docs: add hdcp documentation
From: Tomas Winkler @ 2019-06-03 9:14 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Alexander Usyskin, linux-kernel, Tomas Winkler, Jonathan Corbet,
linux-doc
In-Reply-To: <20190603091406.28915-1-tomas.winkler@intel.com>
1. Add a short ducumentation for MEI HDCP driver,
and fix DOC comments in drivers/misc/mei/hdcp/mei_hdcp.c
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
Documentation/driver-api/mei/hdcp.rst | 32 +++++++++++++++++++
.../driver-api/mei/mei-client-bus.rst | 1 +
drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++----
3 files changed, 37 insertions(+), 7 deletions(-)
create mode 100644 Documentation/driver-api/mei/hdcp.rst
diff --git a/Documentation/driver-api/mei/hdcp.rst b/Documentation/driver-api/mei/hdcp.rst
new file mode 100644
index 000000000000..e85a065b1cdc
--- /dev/null
+++ b/Documentation/driver-api/mei/hdcp.rst
@@ -0,0 +1,32 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+HDCP:
+=====
+
+ME FW as a security engine provides the capability for setting up
+HDCP2.2 protocol negotiation between the Intel graphics device and
+an HDC2.2 sink.
+
+ME FW prepares HDCP2.2 negotiation parameters, signs and encrypts them
+according the HDCP 2.2 spec. The Intel graphics sends the created blob
+to the HDCP2.2 sink.
+
+Similarly, the HDCP2.2 sink's response is transferred to ME FW
+for decryption and verification.
+
+Once all the steps of HDCP2.2 negotiation are completed,
+upon request ME FW will configure the port as authenticated and supply
+the HDCP encryption keys to Intel graphics hardware.
+
+
+mei_hdcp driver
+---------------
+.. kernel-doc:: drivers/misc/mei/hdcp/mei_hdcp.c
+ :doc: MEI_HDCP Client Driver
+
+mei_hdcp api
+------------
+
+.. kernel-doc:: drivers/misc/mei/hdcp/mei_hdcp.c
+ :functions:
+
diff --git a/Documentation/driver-api/mei/mei-client-bus.rst b/Documentation/driver-api/mei/mei-client-bus.rst
index bfe28ebc3ca8..f242b3f8d6aa 100644
--- a/Documentation/driver-api/mei/mei-client-bus.rst
+++ b/Documentation/driver-api/mei/mei-client-bus.rst
@@ -164,4 +164,5 @@ MEI Client Bus Drivers
.. toctree::
:maxdepth: 2
+ hdcp
nfc
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index b07000202d4a..ed816939fb32 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -2,7 +2,7 @@
/*
* Copyright © 2019 Intel Corporation
*
- * Mei_hdcp.c: HDCP client driver for mei bus
+ * mei_hdcp.c: HDCP client driver for mei bus
*
* Author:
* Ramalingam C <ramalingam.c@intel.com>
@@ -11,12 +11,9 @@
/**
* DOC: MEI_HDCP Client Driver
*
- * This is a client driver to the mei_bus to make the HDCP2.2 services of
- * ME FW available for the interested consumers like I915.
- *
- * This module will act as a translation layer between HDCP protocol
- * implementor(I915) and ME FW by translating HDCP2.2 authentication
- * messages to ME FW command payloads and vice versa.
+ * The mei_hdcp driver acts as a translation layer between HDCP 2.2
+ * protocol implementer (I915) and ME FW by translating HDCP2.2
+ * negotiation messages to ME FW command payloads and vice versa.
*/
#include <linux/module.h>
--
2.20.1
^ permalink raw reply related
* [char-misc-next 7/7] mei: docs: fix broken links in iamt documentation.
From: Tomas Winkler @ 2019-06-03 9:14 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Alexander Usyskin, linux-kernel, Tomas Winkler, Jonathan Corbet,
linux-doc
In-Reply-To: <20190603091406.28915-1-tomas.winkler@intel.com>
The iAMT documentation moved from http:// https://,
and LMS is moved to github.com
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
Documentation/driver-api/mei/iamt.rst | 105 ++++++++++++--------------
1 file changed, 50 insertions(+), 55 deletions(-)
diff --git a/Documentation/driver-api/mei/iamt.rst b/Documentation/driver-api/mei/iamt.rst
index 6dcf5b16e958..6ef3e613684b 100644
--- a/Documentation/driver-api/mei/iamt.rst
+++ b/Documentation/driver-api/mei/iamt.rst
@@ -27,62 +27,57 @@ starting with Release 6.0) over HTTP/S or WS-Management protocol over
HTTP/S that are received from a remote management console application.
For more information about Intel AMT:
-http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
+https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm
Intel AMT Applications
-======================
-
- 1) Intel Local Management Service (Intel LMS)
-
- Applications running locally on the platform communicate with Intel AMT Release
- 2.0 and later releases in the same way that network applications do via SOAP
- over HTTP (deprecated starting with Release 6.0) or with WS-Management over
- SOAP over HTTP. This means that some Intel AMT features can be accessed from a
- local application using the same network interface as a remote application
- communicating with Intel AMT over the network.
-
- When a local application sends a message addressed to the local Intel AMT host
- name, the Intel LMS, which listens for traffic directed to the host name,
- intercepts the message and routes it to the Intel MEI.
- For more information:
- http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
- Under "About Intel AMT" => "Local Access"
-
- For downloading Intel LMS:
- http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
-
- The Intel LMS opens a connection using the Intel MEI driver to the Intel LMS
- firmware feature using a defined UUID and then communicates with the feature
- using a protocol called Intel AMT Port Forwarding Protocol (Intel APF protocol).
- The protocol is used to maintain multiple sessions with Intel AMT from a
- single application.
-
- See the protocol specification in the Intel AMT Software Development Kit (SDK)
- http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
- Under "SDK Resources" => "Intel(R) vPro(TM) Gateway (MPS)"
- => "Information for Intel(R) vPro(TM) Gateway Developers"
- => "Description of the Intel AMT Port Forwarding (APF) Protocol"
-
- 2) Intel AMT Remote configuration using a Local Agent
-
- A Local Agent enables IT personnel to configure Intel AMT out-of-the-box
- without requiring installing additional data to enable setup. The remote
- configuration process may involve an ISV-developed remote configuration
- agent that runs on the host.
- For more information:
- http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
- Under "Setup and Configuration of Intel AMT" =>
- "SDK Tools Supporting Setup and Configuration" =>
- "Using the Local Agent Sample"
-
- An open source Intel AMT configuration utility, implementing a local agent
- that accesses the Intel MEI driver, can be found here:
- http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
-
+----------------------
+
+ 1) Intel Local Management Service (Intel LMS)
+
+ Applications running locally on the platform communicate with Intel AMT Release
+ 2.0 and later releases in the same way that network applications do via SOAP
+ over HTTP (deprecated starting with Release 6.0) or with WS-Management over
+ SOAP over HTTP. This means that some Intel AMT features can be accessed from a
+ local application using the same network interface as a remote application
+ communicating with Intel AMT over the network.
+
+ When a local application sends a message addressed to the local Intel AMT host
+ name, the Intel LMS, which listens for traffic directed to the host name,
+ intercepts the message and routes it to the Intel MEI.
+ For more information:
+ https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm
+ Under "About Intel AMT" => "Local Access"
+
+ For downloading Intel LMS:
+ https://github.com/intel/lms
+
+ The Intel LMS opens a connection using the Intel MEI driver to the Intel LMS
+ firmware feature using a defined GUID and then communicates with the feature
+ using a protocol called Intel AMT Port Forwarding Protocol (Intel APF protocol).
+ The protocol is used to maintain multiple sessions with Intel AMT from a
+ single application.
+
+ See the protocol specification in the Intel AMT Software Development Kit (SDK)
+ https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm
+ Under "SDK Resources" => "Intel(R) vPro(TM) Gateway (MPS)"
+ => "Information for Intel(R) vPro(TM) Gateway Developers"
+ => "Description of the Intel AMT Port Forwarding (APF) Protocol"
+
+ 2) Intel AMT Remote configuration using a Local Agent
+
+ A Local Agent enables IT personnel to configure Intel AMT out-of-the-box
+ without requiring installing additional data to enable setup. The remote
+ configuration process may involve an ISV-developed remote configuration
+ agent that runs on the host.
+ For more information:
+ https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm
+ Under "Setup and Configuration of Intel AMT" =>
+ "SDK Tools Supporting Setup and Configuration" =>
+ "Using the Local Agent Sample"
Intel AMT OS Health Watchdog
-============================
+----------------------------
The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog.
Whenever the OS hangs or crashes, Intel AMT will send an event
@@ -90,10 +85,10 @@ to any subscriber to this event. This mechanism means that
IT knows when a platform crashes even when there is a hard failure on the host.
The Intel AMT Watchdog is composed of two parts:
- 1) Firmware feature - receives the heartbeats
- and sends an event when the heartbeats stop.
- 2) Intel MEI iAMT watchdog driver - connects to the watchdog feature,
- configures the watchdog and sends the heartbeats.
+ 1) Firmware feature - receives the heartbeats
+ and sends an event when the heartbeats stop.
+ 2) Intel MEI iAMT watchdog driver - connects to the watchdog feature,
+ configures the watchdog and sends the heartbeats.
The Intel iAMT watchdog MEI driver uses the kernel watchdog API to configure
the Intel AMT Watchdog and to send heartbeats to it. The default timeout of the
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 2/3] ima: don't ignore INTEGRITY_UNKNOWN EVM status
From: Roberto Sassu @ 2019-06-03 9:25 UTC (permalink / raw)
To: Mimi Zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <1559217621.4008.7.camel@linux.ibm.com>
On 5/30/2019 2:00 PM, Mimi Zohar wrote:
> On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
>> Currently, ima_appraise_measurement() ignores the EVM status when
>> evm_verifyxattr() returns INTEGRITY_UNKNOWN. If a file has a valid
>> security.ima xattr with type IMA_XATTR_DIGEST or IMA_XATTR_DIGEST_NG,
>> ima_appraise_measurement() returns INTEGRITY_PASS regardless of the EVM
>> status. The problem is that the EVM status is overwritten with the
>>> appraisal statu
>
> Roberto, your framing of this problem is harsh and misleading. IMA
> and EVM are intentionally independent of each other and can be
> configured independently of each other. The intersection of the two
> is the call to evm_verifyxattr(). INTEGRITY_UNKNOWN is returned for a
> number of reasons - when EVM is not configured, the EVM hmac key has
> not yet been loaded, the protected security attribute is unknown, or
> the file is not in policy.
>
> This patch does not differentiate between any of the above cases,
> requiring mutable files to always be protected by EVM, when specified
> as an "ima_appraise=" option on the boot command line.
>
> IMA could be extended to require EVM on a per IMA policy rule basis.
> Instead of framing allowing IMA file hashes without EVM as a bug that
> has existed from the very beginning, now that IMA/EVM have matured and
> is being used, you could frame it as extending IMA or hardening.
I'm seeing it from the perspective of an administrator that manages an
already hardened system, and expects that the system only grants access
to files with a valid signature/HMAC. That system would not enforce this
behavior if EVM keys are removed and the digest in security.ima is set
to the actual file digest.
Framing it as a bug rather than an extension would in my opinion help to
convince people about the necessity to switch to the safe mode, if their
system is already hardened.
>> This patch mitigates the issue by selecting signature verification as the
>> only method allowed for appraisal when EVM is not initialized. Since the
>> new behavior might break user space, it must be turned on by adding the
>> '-evm' suffix to the value of the ima_appraise= kernel option.
>>
>> Fixes: 2fe5d6def1672 ("ima: integrity appraisal extension")
>> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
>> Cc: stable@vger.kernel.org
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 3 ++-
>> security/integrity/ima/ima_appraise.c | 8 ++++++++
>> 2 files changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 138f6664b2e2..d84a2e612b93 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1585,7 +1585,8 @@
>> Set number of hash buckets for inode cache.
>>
>> ima_appraise= [IMA] appraise integrity measurements
>> - Format: { "off" | "enforce" | "fix" | "log" }
>> + Format: { "off" | "enforce" | "fix" | "log" |
>> + "enforce-evm" | "log-evm" }
>
> Is it necessary to define both "enforce-evm" and "log-evm"? Perhaps
> defining "require-evm" is sufficient.
ima_appraise= accepts as values modes of operation. I consider the -evm
suffix as a modifier of already defined modes.
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
^ permalink raw reply
* Re: [PATCH v3 1/4] f2fs: Lower threshold for disable_cp_again
From: Chao Yu @ 2019-06-03 10:33 UTC (permalink / raw)
To: Daniel Rosenberg, Jaegeuk Kim, Jonathan Corbet, linux-f2fs-devel
Cc: linux-kernel, linux-doc, linux-fsdevel, kernel-team
In-Reply-To: <20190530004906.261170-2-drosen@google.com>
On 2019/5/30 8:49, Daniel Rosenberg wrote:
> The existing threshold for allowable holes at checkpoint=disable time is
> too high. The OVP space contains reserved segments, which are always in
> the form of free segments. These must be subtracted from the OVP value.
>
> The current threshold is meant to be the maximum value of holes of a
> single type we can have and still guarantee that we can fill the disk
> without failing to find space for a block of a given type.
>
> If the disk is full, ignoring current reserved, which only helps us,
> the amount of unused blocks is equal to the OVP area. Of that, there
> are reserved segments, which must be free segments, and the rest of the
> ovp area, which can come from either free segments or holes. The maximum
> possible amount of holes is OVP-reserved.
>
> Now, consider the disk when mounting with checkpoint=disable.
> We must be able to fill all available free space with either data or
> node blocks. When we start with checkpoint=disable, holes are locked to
> their current type. Say we have H of one type of hole, and H+X of the
> other. We can fill H of that space with arbitrary typed blocks via SSR.
> For the remaining H+X blocks, we may not have any of a given block type
> left at all. For instance, if we were to fill the disk entirely with
> blocks of the type with fewer holes, the H+X blocks of the opposite type
> would not be used. If H+X > OVP-reserved, there would be more holes than
> could possibly exist, and we would have failed to find a suitable block
> earlier on, leading to a crash in update_sit_entry.
>
> If H+X <= OVP-reserved, then the holes end up effectively masked by the OVP
> region in this case.
>
> Signed-off-by: Daniel Rosenberg <drosen@google.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Thanks,
^ permalink raw reply
* Re: [PATCH v3 2/4] f2fs: Fix root reserved on remount
From: Chao Yu @ 2019-06-03 10:34 UTC (permalink / raw)
To: Daniel Rosenberg, Jaegeuk Kim, Jonathan Corbet, linux-f2fs-devel
Cc: linux-kernel, linux-doc, linux-fsdevel, kernel-team
In-Reply-To: <20190530004906.261170-3-drosen@google.com>
On 2019/5/30 8:49, Daniel Rosenberg wrote:
> On a remount, you can currently set root reserved if it was not
> previously set. This can cause an underflow if reserved has been set to
> a very high value, since then root reserved + current reserved could be
> greater than user_block_count. inc_valid_block_count later subtracts out
> these values from user_block_count, causing an underflow.
>
> Signed-off-by: Daniel Rosenberg <drosen@google.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Thanks,
^ permalink raw reply
* Re: [PATCH v3 3/4] f2fs: Fix accounting for unusable blocks
From: Chao Yu @ 2019-06-03 10:39 UTC (permalink / raw)
To: Daniel Rosenberg, Jaegeuk Kim, Jonathan Corbet, linux-f2fs-devel
Cc: linux-kernel, linux-doc, linux-fsdevel, kernel-team
In-Reply-To: <20190530004906.261170-4-drosen@google.com>
On 2019/5/30 8:49, Daniel Rosenberg wrote:
> Fixes possible underflows when dealing with unusable blocks.
>
> Signed-off-by: Daniel Rosenberg <drosen@google.com>
> ---
> fs/f2fs/f2fs.h | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 9b3d9977cd1ef..a39cc4ffeb4b1 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -1769,8 +1769,12 @@ static inline int inc_valid_block_count(struct f2fs_sb_info *sbi,
>
> if (!__allow_reserved_blocks(sbi, inode, true))
> avail_user_block_count -= F2FS_OPTION(sbi).root_reserved_blocks;
> - if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED)))
> - avail_user_block_count -= sbi->unusable_block_count;
> + if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED))) {
> + if (avail_user_block_count > sbi->unusable_block_count)
> + avail_user_block_count = 0;
avail_user_block_count -= sbi->unusable_block_count;
> + else
> + avail_user_block_count -= sbi->unusable_block_count;
avail_user_block_count = 0;
Thanks,
> + }
> if (unlikely(sbi->total_valid_block_count > avail_user_block_count)) {
> diff = sbi->total_valid_block_count - avail_user_block_count;
> if (diff > *count)
> @@ -1970,7 +1974,7 @@ static inline int inc_valid_node_count(struct f2fs_sb_info *sbi,
> struct inode *inode, bool is_inode)
> {
> block_t valid_block_count;
> - unsigned int valid_node_count;
> + unsigned int valid_node_count, user_block_count;
> int err;
>
> if (is_inode) {
> @@ -1997,10 +2001,11 @@ static inline int inc_valid_node_count(struct f2fs_sb_info *sbi,
>
> if (!__allow_reserved_blocks(sbi, inode, false))
> valid_block_count += F2FS_OPTION(sbi).root_reserved_blocks;
> + user_block_count = sbi->user_block_count;
> if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED)))
> - valid_block_count += sbi->unusable_block_count;
> + user_block_count -= sbi->unusable_block_count;
>
> - if (unlikely(valid_block_count > sbi->user_block_count)) {
> + if (unlikely(valid_block_count > user_block_count)) {
> spin_unlock(&sbi->stat_lock);
> goto enospc;
> }
>
^ permalink raw reply
* Re: [PATCH v8 3/7] s390/pci: add support for IOMMU default DMA mode build options
From: Sebastian Ott @ 2019-06-03 11:51 UTC (permalink / raw)
To: Zhen Lei
Cc: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Gerald Schaefer,
Martin Schwidefsky, Heiko Carstens, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Tony Luck, Fenghua Yu,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H . Peter Anvin,
David Woodhouse, iommu, linux-kernel, linux-s390, linuxppc-dev,
x86, linux-ia64, Hanjun Guo
In-Reply-To: <20190530034831.4184-4-thunder.leizhen@huawei.com>
On Thu, 30 May 2019, Zhen Lei wrote:
> The default DMA mode is LAZY on s390, this patch make it can be set to
> STRICT at build time. It can be overridden by boot option.
>
> There is no functional change.
>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Acked-by: Sebastian Ott <sebott@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v2 2/2] tracing/kprobe: Add kprobe_event= boot parameter
From: Masami Hiramatsu @ 2019-06-03 11:52 UTC (permalink / raw)
To: Anders Roxell
Cc: Steven Rostedt, Masami Hiramatsu, Ingo Molnar, Naveen N . Rao,
Anil S Keshavamurthy, David S . Miller, Linux Kernel Mailing List,
linux-doc
In-Reply-To: <CADYN=9L2Lz9xgsP7jn3UNMOtAYtg6fAb1hbv=OJ_Xi4dA0Z5NQ@mail.gmail.com>
Hi Anders,
Sorry for replying later.
On Tue, 28 May 2019 15:39:15 +0200
Anders Roxell <anders.roxell@linaro.org> wrote:
> On Tue, 28 May 2019 at 14:36, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > On Tue, 28 May 2019 14:23:43 +0200
> > Anders Roxell <anders.roxell@linaro.org> wrote:
> >
> > > On Wed, 22 May 2019 at 10:32, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> > > >
> > > > Add kprobe_event= boot parameter to define kprobe events
> > > > at boot time.
> > > > The definition syntax is similar to tracefs/kprobe_events
> > > > interface, but use ',' and ';' instead of ' ' and '\n'
> > > > respectively. e.g.
> > > >
> > > > kprobe_event=p,vfs_read,$arg1,$arg2
> > > >
> > > > This puts a probe on vfs_read with argument1 and 2, and
> > > > enable the new event.
> > > >
> > > > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> > >
> > > I built an arm64 kernel from todays linux-next tag next-20190528 and
> > > ran in to this issue when I booted it up in qemu:
Thank you for reporting!
> [ 9.020354][ T1] Kprobe smoke test: started
> [ 9.064132][ T1] Internal error: aarch64 BRK: f2000004 [#1] PREEMPT SMP
> [ 9.067084][ T1] Modules linked in:
> [ 9.068772][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 5.2.0-rc2-next-20190528-00019-g9a6008710716 #8
> [ 9.072893][ T1] Hardware name: linux,dummy-virt (DT)
> [ 9.075143][ T1] pstate: 80400005 (Nzcv daif +PAN -UAO)
> [ 9.077528][ T1] pc : kprobe_target+0x0/0x30
> [ 9.079479][ T1] lr : init_test_probes+0x134/0x540
> [ 9.081611][ T1] sp : ffff80003f51fbe0
> [ 9.083331][ T1] x29: ffff80003f51fbe0 x28: ffff200013c17820
> [ 9.085906][ T1] x27: ffff200015d3ab40 x26: ffff2000122bb120
> [ 9.088491][ T1] x25: 0000000000000000 x24: ffff200013c08ae0
> [ 9.091068][ T1] x23: ffff200015d39000 x22: ffff200013a15ac8
> [ 9.093667][ T1] x21: 1ffff00007ea3f86 x20: ffff200015d39420
> [ 9.096214][ T1] x19: ffff2000122bad20 x18: 0000000000001400
> [ 9.098831][ T1] x17: 0000000000000000 x16: ffff80003f510040
> [ 9.101410][ T1] x15: 0000000000001480 x14: 1ffff00007ea3ea2
> [ 9.103963][ T1] x13: 00000000f1f1f1f1 x12: ffff040002782e0d
> [ 9.106549][ T1] x11: 1fffe40002782e0c x10: ffff040002782e0c
> [ 9.109120][ T1] x9 : 1fffe40002782e0c x8 : dfff200000000000
> [ 9.111676][ T1] x7 : ffff040002782e0d x6 : ffff200013c17067
> [ 9.114234][ T1] x5 : ffff80003f510040 x4 : 0000000000000000
> [ 9.116843][ T1] x3 : ffff200010427508 x2 : 0000000000000000
> [ 9.119409][ T1] x1 : ffff200010426e10 x0 : 0000000000a6326b
> [ 9.121980][ T1] Call trace:
> [ 9.123380][ T1] kprobe_target+0x0/0x30
> [ 9.125205][ T1] init_kprobes+0x2b8/0x300
> [ 9.127074][ T1] do_one_initcall+0x4c0/0xa68
> [ 9.129076][ T1] kernel_init_freeable+0x3c4/0x4e4
> [ 9.131234][ T1] kernel_init+0x14/0x1fc
> [ 9.133032][ T1] ret_from_fork+0x10/0x18
> [ 9.134908][ T1] Code: a9446bf9 f9402bfb a8d87bfd d65f03c0 (d4200080)
> [ 9.137845][ T1] ---[ end trace 49243ee03446b072 ]---
> [ 9.140114][ T1] Kernel panic - not syncing: Fatal exception
> [ 9.142684][ T1] ---[ end Kernel panic - not syncing: Fatal exception ]---
Ah, I think you hit this in [1/2], not this change.
I guess arm64's breakpoint handler is not initialized at postcore_initcall().
I have to check the arch depend implementation on arm64.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/2] tracing/kprobe: Add kprobe_event= boot parameter
From: Masami Hiramatsu @ 2019-06-03 12:41 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Anders Roxell, Steven Rostedt, Ingo Molnar, Naveen N . Rao,
Anil S Keshavamurthy, David S . Miller, Linux Kernel Mailing List,
linux-doc
In-Reply-To: <20190603205238.3cef1ef724bda35d11369ea7@kernel.org>
On Mon, 3 Jun 2019 20:52:38 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> Hi Anders,
>
> Sorry for replying later.
>
> On Tue, 28 May 2019 15:39:15 +0200
> Anders Roxell <anders.roxell@linaro.org> wrote:
>
> > On Tue, 28 May 2019 at 14:36, Steven Rostedt <rostedt@goodmis.org> wrote:
> > >
> > > On Tue, 28 May 2019 14:23:43 +0200
> > > Anders Roxell <anders.roxell@linaro.org> wrote:
> > >
> > > > On Wed, 22 May 2019 at 10:32, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> > > > >
> > > > > Add kprobe_event= boot parameter to define kprobe events
> > > > > at boot time.
> > > > > The definition syntax is similar to tracefs/kprobe_events
> > > > > interface, but use ',' and ';' instead of ' ' and '\n'
> > > > > respectively. e.g.
> > > > >
> > > > > kprobe_event=p,vfs_read,$arg1,$arg2
> > > > >
> > > > > This puts a probe on vfs_read with argument1 and 2, and
> > > > > enable the new event.
> > > > >
> > > > > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> > > >
> > > > I built an arm64 kernel from todays linux-next tag next-20190528 and
> > > > ran in to this issue when I booted it up in qemu:
>
> Thank you for reporting!
>
>
> > [ 9.020354][ T1] Kprobe smoke test: started
> > [ 9.064132][ T1] Internal error: aarch64 BRK: f2000004 [#1] PREEMPT SMP
> > [ 9.067084][ T1] Modules linked in:
> > [ 9.068772][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> > 5.2.0-rc2-next-20190528-00019-g9a6008710716 #8
> > [ 9.072893][ T1] Hardware name: linux,dummy-virt (DT)
> > [ 9.075143][ T1] pstate: 80400005 (Nzcv daif +PAN -UAO)
> > [ 9.077528][ T1] pc : kprobe_target+0x0/0x30
> > [ 9.079479][ T1] lr : init_test_probes+0x134/0x540
> > [ 9.081611][ T1] sp : ffff80003f51fbe0
> > [ 9.083331][ T1] x29: ffff80003f51fbe0 x28: ffff200013c17820
> > [ 9.085906][ T1] x27: ffff200015d3ab40 x26: ffff2000122bb120
> > [ 9.088491][ T1] x25: 0000000000000000 x24: ffff200013c08ae0
> > [ 9.091068][ T1] x23: ffff200015d39000 x22: ffff200013a15ac8
> > [ 9.093667][ T1] x21: 1ffff00007ea3f86 x20: ffff200015d39420
> > [ 9.096214][ T1] x19: ffff2000122bad20 x18: 0000000000001400
> > [ 9.098831][ T1] x17: 0000000000000000 x16: ffff80003f510040
> > [ 9.101410][ T1] x15: 0000000000001480 x14: 1ffff00007ea3ea2
> > [ 9.103963][ T1] x13: 00000000f1f1f1f1 x12: ffff040002782e0d
> > [ 9.106549][ T1] x11: 1fffe40002782e0c x10: ffff040002782e0c
> > [ 9.109120][ T1] x9 : 1fffe40002782e0c x8 : dfff200000000000
> > [ 9.111676][ T1] x7 : ffff040002782e0d x6 : ffff200013c17067
> > [ 9.114234][ T1] x5 : ffff80003f510040 x4 : 0000000000000000
> > [ 9.116843][ T1] x3 : ffff200010427508 x2 : 0000000000000000
> > [ 9.119409][ T1] x1 : ffff200010426e10 x0 : 0000000000a6326b
> > [ 9.121980][ T1] Call trace:
> > [ 9.123380][ T1] kprobe_target+0x0/0x30
> > [ 9.125205][ T1] init_kprobes+0x2b8/0x300
> > [ 9.127074][ T1] do_one_initcall+0x4c0/0xa68
> > [ 9.129076][ T1] kernel_init_freeable+0x3c4/0x4e4
> > [ 9.131234][ T1] kernel_init+0x14/0x1fc
> > [ 9.133032][ T1] ret_from_fork+0x10/0x18
> > [ 9.134908][ T1] Code: a9446bf9 f9402bfb a8d87bfd d65f03c0 (d4200080)
> > [ 9.137845][ T1] ---[ end trace 49243ee03446b072 ]---
> > [ 9.140114][ T1] Kernel panic - not syncing: Fatal exception
> > [ 9.142684][ T1] ---[ end Kernel panic - not syncing: Fatal exception ]---
>
> Ah, I think you hit this in [1/2], not this change.
>
> I guess arm64's breakpoint handler is not initialized at postcore_initcall().
> I have to check the arch depend implementation on arm64.
Yes, for some reason, arm64 breakpoint handler vector is initalized in arch_initcall().
Let's move init_kprobes to subsys_initcall, which is called before fs_initcall.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/3] ima: don't ignore INTEGRITY_UNKNOWN EVM status
From: Mimi Zohar @ 2019-06-03 12:48 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <e6b31aa9-0319-1805-bdfc-3ddde5884494@huawei.com>
On Mon, 2019-06-03 at 11:25 +0200, Roberto Sassu wrote:
> On 5/30/2019 2:00 PM, Mimi Zohar wrote:
> > On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
> >> Currently, ima_appraise_measurement() ignores the EVM status when
> >> evm_verifyxattr() returns INTEGRITY_UNKNOWN. If a file has a valid
> >> security.ima xattr with type IMA_XATTR_DIGEST or IMA_XATTR_DIGEST_NG,
> >> ima_appraise_measurement() returns INTEGRITY_PASS regardless of the EVM
> >> status. The problem is that the EVM status is overwritten with the
> >>> appraisal status
> >
> > Roberto, your framing of this problem is harsh and misleading. IMA
> > and EVM are intentionally independent of each other and can be
> > configured independently of each other. The intersection of the two
> > is the call to evm_verifyxattr(). INTEGRITY_UNKNOWN is returned for a
> > number of reasons - when EVM is not configured, the EVM hmac key has
> > not yet been loaded, the protected security attribute is unknown, or
> > the file is not in policy.
> >
> > This patch does not differentiate between any of the above cases,
> > requiring mutable files to always be protected by EVM, when specified
> > as an "ima_appraise=" option on the boot command line.
> >
> > IMA could be extended to require EVM on a per IMA policy rule basis.
> > Instead of framing allowing IMA file hashes without EVM as a bug that
> > has existed from the very beginning, now that IMA/EVM have matured and
> > is being used, you could frame it as extending IMA or hardening.
>
> I'm seeing it from the perspective of an administrator that manages an
> already hardened system, and expects that the system only grants access
> to files with a valid signature/HMAC. That system would not enforce this
> behavior if EVM keys are removed and the digest in security.ima is set
> to the actual file digest.
>
> Framing it as a bug rather than an extension would in my opinion help to
> convince people about the necessity to switch to the safe mode, if their
> system is already hardened.
I don't disagree with you that people should be using EVM to protect
IMA hashes. If you claim this is a bug in the design from the very
beginning, then there needs some explanation as to why it was
upstreamed as it was. My review of this patch provided that
context/background.
Mimi
>
>
> >> This patch mitigates the issue by selecting signature verification as the
> >> only method allowed for appraisal when EVM is not initialized. Since the
> >> new behavior might break user space, it must be turned on by adding the
> >> '-evm' suffix to the value of the ima_appraise= kernel option.
> >>
> >> Fixes: 2fe5d6def1672 ("ima: integrity appraisal extension")
> >> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> >> Cc: stable@vger.kernel.org
>
^ permalink raw reply
* Re: [PATCH v2 2/3] ima: don't ignore INTEGRITY_UNKNOWN EVM status
From: James Bottomley @ 2019-06-03 13:43 UTC (permalink / raw)
To: Roberto Sassu, Mimi Zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <e6b31aa9-0319-1805-bdfc-3ddde5884494@huawei.com>
On Mon, 2019-06-03 at 11:25 +0200, Roberto Sassu wrote:
> On 5/30/2019 2:00 PM, Mimi Zohar wrote:
> > On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
> > > Currently, ima_appraise_measurement() ignores the EVM status when
> > > evm_verifyxattr() returns INTEGRITY_UNKNOWN. If a file has a
> > > valid security.ima xattr with type IMA_XATTR_DIGEST or
> > > IMA_XATTR_DIGEST_NG, ima_appraise_measurement() returns
> > > INTEGRITY_PASS regardless of the EVM status. The problem is that
> > > the EVM status is overwritten with the appraisal statu
> >
> > Roberto, your framing of this problem is harsh and misleading. IMA
> > and EVM are intentionally independent of each other and can be
> > configured independently of each other. The intersection of the
> > two is the call to evm_verifyxattr(). INTEGRITY_UNKNOWN is
> > returned for a number of reasons - when EVM is not configured, the
> > EVM hmac key has not yet been loaded, the protected security
> > attribute is unknown, or the file is not in policy.
> >
> > This patch does not differentiate between any of the above cases,
> > requiring mutable files to always be protected by EVM, when
> > specified as an "ima_appraise=" option on the boot command line.
> >
> > IMA could be extended to require EVM on a per IMA policy rule
> > basis. Instead of framing allowing IMA file hashes without EVM as a
> > bug that has existed from the very beginning, now that IMA/EVM have
> > matured and is being used, you could frame it as extending IMA
> > or hardening.
>
> I'm seeing it from the perspective of an administrator that manages
> an already hardened system, and expects that the system only grants
> access to files with a valid signature/HMAC. That system would not
> enforce this behavior if EVM keys are removed and the digest in
> security.ima is set to the actual file digest.
>
> Framing it as a bug rather than an extension would in my opinion help
> to convince people about the necessity to switch to the safe mode, if
> their system is already hardened.
I have a use case for IMA where I use it to enforce immutability of
containers. In this use case, the cluster admin places hashes on
executables as the image is unpacked so that if an executable file is
changed, IMA will cause an execution failure. For this use case, I
don't care about the EVM, in fact we don't use it, because the only
object is to fail execution if a binary is mutated.
So I can see your use case requires IMA+EVM, but requiring it would
cause more complexity for my use case.
James
^ permalink raw reply
* Re: [PATCH v2 2/3] ima: don't ignore INTEGRITY_UNKNOWN EVM status
From: Chuck Lever @ 2019-06-03 14:24 UTC (permalink / raw)
To: James Bottomley, Roberto Sassu
Cc: Mimi Zohar, dmitry.kasatkin, Matthew Garrett, linux-integrity,
linux-security-module, linux-doc, Linux Kernel Mailing List,
silviu.vlasceanu, stable
In-Reply-To: <1559569401.5052.17.camel@HansenPartnership.com>
> On Jun 3, 2019, at 9:43 AM, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> On Mon, 2019-06-03 at 11:25 +0200, Roberto Sassu wrote:
>> On 5/30/2019 2:00 PM, Mimi Zohar wrote:
>>> On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
>>>> Currently, ima_appraise_measurement() ignores the EVM status when
>>>> evm_verifyxattr() returns INTEGRITY_UNKNOWN. If a file has a
>>>> valid security.ima xattr with type IMA_XATTR_DIGEST or
>>>> IMA_XATTR_DIGEST_NG, ima_appraise_measurement() returns
>>>> INTEGRITY_PASS regardless of the EVM status. The problem is that
>>>> the EVM status is overwritten with the appraisal statu
>>>
>>> Roberto, your framing of this problem is harsh and misleading. IMA
>>> and EVM are intentionally independent of each other and can be
>>> configured independently of each other. The intersection of the
>>> two is the call to evm_verifyxattr(). INTEGRITY_UNKNOWN is
>>> returned for a number of reasons - when EVM is not configured, the
>>> EVM hmac key has not yet been loaded, the protected security
>>> attribute is unknown, or the file is not in policy.
>>>
>>> This patch does not differentiate between any of the above cases,
>>> requiring mutable files to always be protected by EVM, when
>>> specified as an "ima_appraise=" option on the boot command line.
>>>
>>> IMA could be extended to require EVM on a per IMA policy rule
>>> basis. Instead of framing allowing IMA file hashes without EVM as a
>>> bug that has existed from the very beginning, now that IMA/EVM have
>>> matured and is being used, you could frame it as extending IMA
>>> or hardening.
>>
>> I'm seeing it from the perspective of an administrator that manages
>> an already hardened system, and expects that the system only grants
>> access to files with a valid signature/HMAC. That system would not
>> enforce this behavior if EVM keys are removed and the digest in
>> security.ima is set to the actual file digest.
>>
>> Framing it as a bug rather than an extension would in my opinion help
>> to convince people about the necessity to switch to the safe mode, if
>> their system is already hardened.
>
> I have a use case for IMA where I use it to enforce immutability of
> containers. In this use case, the cluster admin places hashes on
> executables as the image is unpacked so that if an executable file is
> changed, IMA will cause an execution failure. For this use case, I
> don't care about the EVM, in fact we don't use it, because the only
> object is to fail execution if a binary is mutated.
>
> So I can see your use case requires IMA+EVM, but requiring it would
> cause more complexity for my use case.
... and would not work at all for the current NFS IMA implementation.
--
Chuck Lever
^ permalink raw reply
* Re: [PATCH v2 2/3] ima: don't ignore INTEGRITY_UNKNOWN EVM status
From: Roberto Sassu @ 2019-06-03 14:29 UTC (permalink / raw)
To: James Bottomley, Mimi Zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <1559569401.5052.17.camel@HansenPartnership.com>
On 6/3/2019 3:43 PM, James Bottomley wrote:
> On Mon, 2019-06-03 at 11:25 +0200, Roberto Sassu wrote:
>> On 5/30/2019 2:00 PM, Mimi Zohar wrote:
>>> On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
>>>> Currently, ima_appraise_measurement() ignores the EVM status when
>>>> evm_verifyxattr() returns INTEGRITY_UNKNOWN. If a file has a
>>>> valid security.ima xattr with type IMA_XATTR_DIGEST or
>>>> IMA_XATTR_DIGEST_NG, ima_appraise_measurement() returns
>>>> INTEGRITY_PASS regardless of the EVM status. The problem is that
>>>> the EVM status is overwritten with the appraisal statu
>>>
>>> Roberto, your framing of this problem is harsh and misleading. IMA
>>> and EVM are intentionally independent of each other and can be
>>> configured independently of each other. The intersection of the
>>> two is the call to evm_verifyxattr(). INTEGRITY_UNKNOWN is
>>> returned for a number of reasons - when EVM is not configured, the
>>> EVM hmac key has not yet been loaded, the protected security
>>> attribute is unknown, or the file is not in policy.
>>>
>>> This patch does not differentiate between any of the above cases,
>>> requiring mutable files to always be protected by EVM, when
>>> specified as an "ima_appraise=" option on the boot command line.
>>>
>>> IMA could be extended to require EVM on a per IMA policy rule
>>> basis. Instead of framing allowing IMA file hashes without EVM as a
>>> bug that has existed from the very beginning, now that IMA/EVM have
>>> matured and is being used, you could frame it as extending IMA
>>> or hardening.
>>
>> I'm seeing it from the perspective of an administrator that manages
>> an already hardened system, and expects that the system only grants
>> access to files with a valid signature/HMAC. That system would not
>> enforce this behavior if EVM keys are removed and the digest in
>> security.ima is set to the actual file digest.
>>
>> Framing it as a bug rather than an extension would in my opinion help
>> to convince people about the necessity to switch to the safe mode, if
>> their system is already hardened.
>
> I have a use case for IMA where I use it to enforce immutability of
> containers. In this use case, the cluster admin places hashes on
> executables as the image is unpacked so that if an executable file is
> changed, IMA will cause an execution failure. For this use case, I
> don't care about the EVM, in fact we don't use it, because the only
> object is to fail execution if a binary is mutated.
How would you prevent root in the container from updating security.ima?
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
^ permalink raw reply
* Re: [PATCH v2 2/3] ima: don't ignore INTEGRITY_UNKNOWN EVM status
From: James Bottomley @ 2019-06-03 14:31 UTC (permalink / raw)
To: Roberto Sassu, Mimi Zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <3667fbd4-b6ed-6a76-9ff4-84ec3c2dda12@huawei.com>
On Mon, 2019-06-03 at 16:29 +0200, Roberto Sassu wrote:
> On 6/3/2019 3:43 PM, James Bottomley wrote:
> > On Mon, 2019-06-03 at 11:25 +0200, Roberto Sassu wrote:
> > > On 5/30/2019 2:00 PM, Mimi Zohar wrote:
> > > > On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
> > > > > Currently, ima_appraise_measurement() ignores the EVM status
> > > > > when evm_verifyxattr() returns INTEGRITY_UNKNOWN. If a file
> > > > > has a valid security.ima xattr with type IMA_XATTR_DIGEST or
> > > > > IMA_XATTR_DIGEST_NG, ima_appraise_measurement() returns
> > > > > INTEGRITY_PASS regardless of the EVM status. The problem is
> > > > > that the EVM status is overwritten with the appraisal statu
> > > >
> > > > Roberto, your framing of this problem is harsh and
> > > > misleading. IMA and EVM are intentionally independent of each
> > > > other and can be configured independently of each other. The
> > > > intersection of the two is the call to
> > > > evm_verifyxattr(). INTEGRITY_UNKNOWN is
> > > > returned for a number of reasons - when EVM is not configured,
> > > > the EVM hmac key has not yet been loaded, the protected
> > > > security attribute is unknown, or the file is not in policy.
> > > >
> > > > This patch does not differentiate between any of the above
> > > > cases, requiring mutable files to always be protected by EVM,
> > > > when specified as an "ima_appraise=" option on the boot command
> > > > line.
> > > >
> > > > IMA could be extended to require EVM on a per IMA policy rule
> > > > basis. Instead of framing allowing IMA file hashes without EVM
> > > > as a bug that has existed from the very beginning, now that
> > > > IMA/EVM have matured and is being used, you could frame it as
> > > > extending IMA or hardening.
> > >
> > > I'm seeing it from the perspective of an administrator that
> > > manages an already hardened system, and expects that the system
> > > only grants access to files with a valid signature/HMAC. That
> > > system would not enforce this behavior if EVM keys are removed
> > > and the digest in security.ima is set to the actual file digest.
> > >
> > > Framing it as a bug rather than an extension would in my opinion
> > > help to convince people about the necessity to switch to the safe
> > > mode, if their system is already hardened.
> >
> > I have a use case for IMA where I use it to enforce immutability of
> > containers. In this use case, the cluster admin places hashes on
> > executables as the image is unpacked so that if an executable file
> > is changed, IMA will cause an execution failure. For this use
> > case, I don't care about the EVM, in fact we don't use it, because
> > the only object is to fail execution if a binary is mutated.
>
> How would you prevent root in the container from updating
> security.ima?
We don't. We only guarantee immutability for unprivileged containers,
so root can't be inside.
James
^ permalink raw reply
* Re: [PATCH v2 2/3] ima: don't ignore INTEGRITY_UNKNOWN EVM status
From: Roberto Sassu @ 2019-06-03 14:44 UTC (permalink / raw)
To: James Bottomley, Mimi Zohar, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-security-module, linux-doc, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <1559572305.5052.19.camel@HansenPartnership.com>
On 6/3/2019 4:31 PM, James Bottomley wrote:
> On Mon, 2019-06-03 at 16:29 +0200, Roberto Sassu wrote:
>> On 6/3/2019 3:43 PM, James Bottomley wrote:
>>> On Mon, 2019-06-03 at 11:25 +0200, Roberto Sassu wrote:
>>>> On 5/30/2019 2:00 PM, Mimi Zohar wrote:
>>>>> On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
>>>>>> Currently, ima_appraise_measurement() ignores the EVM status
>>>>>> when evm_verifyxattr() returns INTEGRITY_UNKNOWN. If a file
>>>>>> has a valid security.ima xattr with type IMA_XATTR_DIGEST or
>>>>>> IMA_XATTR_DIGEST_NG, ima_appraise_measurement() returns
>>>>>> INTEGRITY_PASS regardless of the EVM status. The problem is
>>>>>> that the EVM status is overwritten with the appraisal statu
>>>>>
>>>>> Roberto, your framing of this problem is harsh and
>>>>> misleading. IMA and EVM are intentionally independent of each
>>>>> other and can be configured independently of each other. The
>>>>> intersection of the two is the call to
>>>>> evm_verifyxattr(). INTEGRITY_UNKNOWN is
>>>>> returned for a number of reasons - when EVM is not configured,
>>>>> the EVM hmac key has not yet been loaded, the protected
>>>>> security attribute is unknown, or the file is not in policy.
>>>>>
>>>>> This patch does not differentiate between any of the above
>>>>> cases, requiring mutable files to always be protected by EVM,
>>>>> when specified as an "ima_appraise=" option on the boot command
>>>>> line.
>>>>>
>>>>> IMA could be extended to require EVM on a per IMA policy rule
>>>>> basis. Instead of framing allowing IMA file hashes without EVM
>>>>> as a bug that has existed from the very beginning, now that
>>>>> IMA/EVM have matured and is being used, you could frame it as
>>>>> extending IMA or hardening.
>>>>
>>>> I'm seeing it from the perspective of an administrator that
>>>> manages an already hardened system, and expects that the system
>>>> only grants access to files with a valid signature/HMAC. That
>>>> system would not enforce this behavior if EVM keys are removed
>>>> and the digest in security.ima is set to the actual file digest.
>>>>
>>>> Framing it as a bug rather than an extension would in my opinion
>>>> help to convince people about the necessity to switch to the safe
>>>> mode, if their system is already hardened.
>>>
>>> I have a use case for IMA where I use it to enforce immutability of
>>> containers. In this use case, the cluster admin places hashes on
>>> executables as the image is unpacked so that if an executable file
>>> is changed, IMA will cause an execution failure. For this use
>>> case, I don't care about the EVM, in fact we don't use it, because
>>> the only object is to fail execution if a binary is mutated.
>>
>> How would you prevent root in the container from updating
>> security.ima?
>
> We don't. We only guarantee immutability for unprivileged containers,
> so root can't be inside.
Ok.
Regarding the new behavior, this must be explicitly enabled by adding
ima_appraise=enforce-evm or log-evm to the kernel command line.
Otherwise, the current behavior is preserved with this patch. Would this
be ok?
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
^ permalink raw reply
* Re: [f2fs-dev] [PATCH v3 4/4] f2fs: Add option to limit required GC for checkpoint=disable
From: Chao Yu @ 2019-06-03 15:15 UTC (permalink / raw)
To: Daniel Rosenberg, Jaegeuk Kim, Chao Yu, Jonathan Corbet,
linux-f2fs-devel
Cc: linux-fsdevel, kernel-team, linux-kernel, linux-doc
In-Reply-To: <20190530004906.261170-5-drosen@google.com>
On 2019-5-30 8:49, Daniel Rosenberg via Linux-f2fs-devel wrote:
> This extends the checkpoint option to allow checkpoint=disable:%u[%]
> This allows you to specify what how much of the disk you are willing
> to lose access to while mounting with checkpoint=disable. If the amount
> lost would be higher, the mount will return -EAGAIN. This can be given
> as a percent of total space, or in blocks.
>
> Currently, we need to run garbage collection until the amount of holes
> is smaller than the OVP space. With the new option, f2fs can mark
> space as unusable up front instead of requiring garbage collection until
> the number of holes is small enough.
>
> Signed-off-by: Daniel Rosenberg <drosen@google.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Thanks,
^ permalink raw reply
* [PATCH v4] Allow to exclude specific file types in LoadPin
From: Ke Wu @ 2019-06-03 18:36 UTC (permalink / raw)
To: Kees Cook, Jonathan Corbet, James Morris, Serge E. Hallyn
Cc: linux-doc, linux-kernel, linux-security-module, Ke Wu
In-Reply-To: <20190529224350.6460-1-mikewu@google.com>
Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
make sure loaded kernel module and kernel image are trusted. This
patch adds a kernel command line option "loadpin.exclude" which
allows to exclude specific file types from LoadPin. This is useful
when people want to use different mechanisms to verify module and
kernel image while still use LoadPin to protect the integrity of
other files kernel loads.
Signed-off-by: Ke Wu <mikewu@google.com>
---
Changelog since v3:
- Undo patch v3 change.
- Use ignore_read_file_id rahther than kernel_read_file_str when
iterating to prevent out-of-bounds write.
Changelog since v2:
- Make size of exclude_read_files and ignore_read_file_id to be
equal to the size of kernel_read_file_str.
Changelog since v1:
- Mark ignore_read_file_id with __ro_after_init.
- Mark parse_exclude() with __init.
- Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
Documentation/admin-guide/LSM/LoadPin.rst | 10 ++++++
security/loadpin/loadpin.c | 44 +++++++++++++++++++++++
2 files changed, 54 insertions(+)
diff --git a/Documentation/admin-guide/LSM/LoadPin.rst b/Documentation/admin-guide/LSM/LoadPin.rst
index 32070762d24c..716ad9b23c9a 100644
--- a/Documentation/admin-guide/LSM/LoadPin.rst
+++ b/Documentation/admin-guide/LSM/LoadPin.rst
@@ -19,3 +19,13 @@ block device backing the filesystem is not read-only, a sysctl is
created to toggle pinning: ``/proc/sys/kernel/loadpin/enabled``. (Having
a mutable filesystem means pinning is mutable too, but having the
sysctl allows for easy testing on systems with a mutable filesystem.)
+
+It's also possible to exclude specific file types from LoadPin using kernel
+command line option "``loadpin.exclude``". By default, all files are
+included, but they can be excluded using kernel command line option such
+as "``loadpin.exclude=kernel-module,kexec-image``". This allows to use
+different mechanisms such as ``CONFIG_MODULE_SIG`` and
+``CONFIG_KEXEC_VERIFY_SIG`` to verify kernel module and kernel image while
+still use LoadPin to protect the integrity of other files kernel loads. The
+full list of valid file types can be found in ``kernel_read_file_str``
+defined in ``include/linux/fs.h``.
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index 055fb0a64169..ae59b812f4c8 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -45,6 +45,8 @@ static void report_load(const char *origin, struct file *file, char *operation)
}
static int enforce = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCE);
+static char *exclude_read_files[READING_MAX_ID];
+static int ignore_read_file_id[READING_MAX_ID] __ro_after_init;
static struct super_block *pinned_root;
static DEFINE_SPINLOCK(pinned_root_spinlock);
@@ -129,6 +131,13 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
struct super_block *load_root;
const char *origin = kernel_read_file_id_str(id);
+ /* If the file id is excluded, ignore the pinning. */
+ if ((unsigned int)id < ARRAY_SIZE(ignore_read_file_id) &&
+ ignore_read_file_id[id]) {
+ report_load(origin, file, "pinning-excluded");
+ return 0;
+ }
+
/* This handles the older init_module API that has a NULL file. */
if (!file) {
if (!enforce) {
@@ -187,10 +196,43 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(kernel_load_data, loadpin_load_data),
};
+static void __init parse_exclude(void)
+{
+ int i, j;
+ char *cur;
+
+ /* Robustness check: size of kernel_read_file_str should be size of
+ * ignore_read_file_id + 1.
+ */
+ BUILD_BUG_ON(ARRAY_SIZE(kernel_read_file_str) <
+ ARRAY_SIZE(ignore_read_file_id));
+
+ for (i = 0; i < ARRAY_SIZE(exclude_read_files); i++) {
+ cur = exclude_read_files[i];
+ if (!cur)
+ break;
+ if (*cur == '\0')
+ continue;
+
+ for (j = 0; j < ARRAY_SIZE(ignore_read_file_id); j++) {
+ if (strcmp(cur, kernel_read_file_str[j]) == 0) {
+ pr_info("excluding: %s\n",
+ kernel_read_file_str[j]);
+ ignore_read_file_id[j] = 1;
+ /*
+ * Can not break, because one read_file_str
+ * may map to more than on read_file_id.
+ */
+ }
+ }
+ }
+}
+
static int __init loadpin_init(void)
{
pr_info("ready to pin (currently %senforcing)\n",
enforce ? "" : "not ");
+ parse_exclude();
security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
return 0;
}
@@ -203,3 +245,5 @@ DEFINE_LSM(loadpin) = {
/* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
module_param(enforce, int, 0);
MODULE_PARM_DESC(enforce, "Enforce module/firmware pinning");
+module_param_array_named(exclude, exclude_read_files, charp, NULL, 0);
+MODULE_PARM_DESC(exclude, "Exclude pinning specific read file types");
--
2.22.0.rc1.311.g5d7573a151-goog
^ permalink raw reply related
* Re: [PATCH v3 3/4] f2fs: Fix accounting for unusable blocks
From: Jaegeuk Kim @ 2019-06-03 20:26 UTC (permalink / raw)
To: Chao Yu
Cc: Daniel Rosenberg, Jonathan Corbet, linux-f2fs-devel, linux-kernel,
linux-doc, linux-fsdevel, kernel-team
In-Reply-To: <c99079bd-99e1-e100-08f6-1e8adae5e722@huawei.com>
On 06/03, Chao Yu wrote:
> On 2019/5/30 8:49, Daniel Rosenberg wrote:
> > Fixes possible underflows when dealing with unusable blocks.
> >
> > Signed-off-by: Daniel Rosenberg <drosen@google.com>
> > ---
> > fs/f2fs/f2fs.h | 15 ++++++++++-----
> > 1 file changed, 10 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index 9b3d9977cd1ef..a39cc4ffeb4b1 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -1769,8 +1769,12 @@ static inline int inc_valid_block_count(struct f2fs_sb_info *sbi,
> >
> > if (!__allow_reserved_blocks(sbi, inode, true))
> > avail_user_block_count -= F2FS_OPTION(sbi).root_reserved_blocks;
> > - if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED)))
> > - avail_user_block_count -= sbi->unusable_block_count;
> > + if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED))) {
> > + if (avail_user_block_count > sbi->unusable_block_count)
> > + avail_user_block_count = 0;
>
> avail_user_block_count -= sbi->unusable_block_count;
>
> > + else
> > + avail_user_block_count -= sbi->unusable_block_count;
>
> avail_user_block_count = 0;
>
I fixed this.
Thanks,
> Thanks,
>
> > + }
> > if (unlikely(sbi->total_valid_block_count > avail_user_block_count)) {
> > diff = sbi->total_valid_block_count - avail_user_block_count;
> > if (diff > *count)
> > @@ -1970,7 +1974,7 @@ static inline int inc_valid_node_count(struct f2fs_sb_info *sbi,
> > struct inode *inode, bool is_inode)
> > {
> > block_t valid_block_count;
> > - unsigned int valid_node_count;
> > + unsigned int valid_node_count, user_block_count;
> > int err;
> >
> > if (is_inode) {
> > @@ -1997,10 +2001,11 @@ static inline int inc_valid_node_count(struct f2fs_sb_info *sbi,
> >
> > if (!__allow_reserved_blocks(sbi, inode, false))
> > valid_block_count += F2FS_OPTION(sbi).root_reserved_blocks;
> > + user_block_count = sbi->user_block_count;
> > if (unlikely(is_sbi_flag_set(sbi, SBI_CP_DISABLED)))
> > - valid_block_count += sbi->unusable_block_count;
> > + user_block_count -= sbi->unusable_block_count;
> >
> > - if (unlikely(valid_block_count > sbi->user_block_count)) {
> > + if (unlikely(valid_block_count > user_block_count)) {
> > spin_unlock(&sbi->stat_lock);
> > goto enospc;
> > }
> >
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox