Update the self-protection documentation, to mention also the use of the __wr_after_init attribute.
Signed-off-by: Igor Stoppa <[email protected]> CC: Andy Lutomirski <[email protected]> CC: Nadav Amit <[email protected]> CC: Matthew Wilcox <[email protected]> CC: Peter Zijlstra <[email protected]> CC: Kees Cook <[email protected]> CC: Dave Hansen <[email protected]> CC: Mimi Zohar <[email protected]> CC: Thiago Jung Bauermann <[email protected]> CC: Ahmed Soliman <[email protected]> CC: [email protected] CC: [email protected] CC: [email protected] CC: [email protected] --- 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
