|
Message-Id: <f0335476914a519f573d271ef062dc02b39885d1.1550097697.git.igor.stoppa@huawei.com> Date: Thu, 14 Feb 2019 00:41:36 +0200 From: Igor Stoppa <igor.stoppa@...il.com> To: Cc: Igor Stoppa <igor.stoppa@...wei.com>, Andy Lutomirski <luto@...capital.net>, Nadav Amit <nadav.amit@...il.com>, Matthew Wilcox <willy@...radead.org>, Peter Zijlstra <peterz@...radead.org>, Kees Cook <keescook@...omium.org>, Dave Hansen <dave.hansen@...ux.intel.com>, Mimi Zohar <zohar@...ux.vnet.ibm.com>, Thiago Jung Bauermann <bauerman@...ux.ibm.com>, Ahmed Soliman <ahmedsoliman@...a.vt.edu>, linux-integrity@...r.kernel.org, kernel-hardening@...ts.openwall.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org Subject: [RFC PATCH v5 07/12] __wr_after_init: Documentation: self-protection Update the self-protection documentation, to mention also the use of the __wr_after_init attribute. Signed-off-by: Igor Stoppa <igor.stoppa@...wei.com> CC: Andy Lutomirski <luto@...capital.net> CC: Nadav Amit <nadav.amit@...il.com> CC: Matthew Wilcox <willy@...radead.org> CC: Peter Zijlstra <peterz@...radead.org> CC: Kees Cook <keescook@...omium.org> CC: Dave Hansen <dave.hansen@...ux.intel.com> CC: Mimi Zohar <zohar@...ux.vnet.ibm.com> CC: Thiago Jung Bauermann <bauerman@...ux.ibm.com> CC: Ahmed Soliman <ahmedsoliman@...a.vt.edu> CC: linux-integrity@...r.kernel.org CC: kernel-hardening@...ts.openwall.com CC: linux-mm@...ck.org CC: linux-kernel@...r.kernel.org --- Documentation/security/self-protection.rst | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/security/self-protection.rst b/Documentation/security/self-protection.rst index f584fb74b4ff..df2614bc25b9 100644 --- a/Documentation/security/self-protection.rst +++ b/Documentation/security/self-protection.rst @@ -84,12 +84,14 @@ For variables that are initialized once at ``__init`` time, these can be marked with the (new and under development) ``__ro_after_init`` attribute. -What remains are variables that are updated rarely (e.g. GDT). These -will need another infrastructure (similar to the temporary exceptions -made to kernel code mentioned above) that allow them to spend the rest -of their lifetime read-only. (For example, when being updated, only the -CPU thread performing the update would be given uninterruptible write -access to the memory.) +Others, which are statically allocated, but still need to be updated +rarely, can be marked with the ``__wr_after_init`` attribute. + +The update mechanism must avoid exposing the data to rogue alterations +during the update. For example, only the CPU thread performing the update +would be given uninterruptible write access to the memory. + +Currently there is no protection available for data allocated dynamically. Segregation of kernel memory from userspace memory ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- 2.19.1
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.