diff mbox series

[RFC,v2] selinux: security: Move selinux_state to a separate page

Message ID 1610099389-28329-1-git-send-email-pnagar@codeaurora.org (mailing list archive)
State New
Headers show
Series [RFC,v2] selinux: security: Move selinux_state to a separate page | expand

Commit Message

Preeti Nagar Jan. 8, 2021, 9:49 a.m. UTC
The changes introduce a new security feature, RunTime Integrity Check
(RTIC), designed to protect Linux Kernel at runtime. The motivation
behind these changes is:
1. The system protection offered by SE for Android relies on the
assumption of kernel integrity. If the kernel itself is compromised (by
a perhaps as yet unknown future vulnerability), SE for Android security
mechanisms could potentially be disabled and rendered ineffective.
2. Qualcomm Snapdragon devices use Secure Boot, which adds cryptographic
checks to each stage of the boot-up process, to assert the authenticity
of all secure software images that the device executes.  However, due to
various vulnerabilities in SW modules, the integrity of the system can be
compromised at any time after device boot-up, leading to un-authorized
SW executing.

The feature's idea is to move some sensitive kernel structures to a
separate page and monitor further any unauthorized changes to these,
from higher Exception Levels using stage 2 MMU. Moving these to a
different page will help avoid getting page faults from un-related data.
Using this mechanism, some sensitive variables of the kernel which are
initialized after init or are updated rarely can also be protected from
simple overwrites and attacks trying to modify these.

Currently, the change moves selinux_state structure to a separate page. In
future we plan to move more security-related kernel assets to this page to
enhance protection.

We want to seek your suggestions and comments on the idea and the changes
in the patch.

Signed-off-by: Preeti Nagar <pnagar@codeaurora.org>
---
 include/asm-generic/vmlinux.lds.h | 10 ++++++++++
 include/linux/init.h              |  4 ++++
 security/Kconfig                  | 10 ++++++++++
 security/selinux/hooks.c          |  4 ++++
 4 files changed, 28 insertions(+)

Comments

Miguel Ojeda Jan. 8, 2021, 3:25 p.m. UTC | #1
On Fri, Jan 8, 2021 at 10:52 AM Preeti Nagar <pnagar@codeaurora.org> wrote:
>
> We want to seek your suggestions and comments on the idea and the changes
> in the patch.

Not sure why I was Cc'd, but I have a quick comment nevertheless.

> +#ifdef CONFIG_SECURITY_RTIC
> +struct selinux_state selinux_state __rticdata;
> +#else
>  struct selinux_state selinux_state;
> +#endif

If you define an empty __rticdata for the !CONFIG case, then we don't
need #ifdefs for uses like this.

Cheers,
Miguel
Miguel Ojeda Jan. 8, 2021, 3:28 p.m. UTC | #2
On Fri, Jan 8, 2021 at 10:52 AM Preeti Nagar <pnagar@codeaurora.org> wrote:
>
> We want to seek your suggestions and comments on the idea and the changes
> in the patch.

Cc'ing Nick manually since his email domain was (again :-) incorrect.

Cheers,
Miguel
Casey Schaufler Jan. 8, 2021, 5:11 p.m. UTC | #3
On 1/8/2021 1:49 AM, Preeti Nagar wrote:
> The changes introduce a new security feature, RunTime Integrity Check
> (RTIC), designed to protect Linux Kernel at runtime. The motivation
> behind these changes is:
> 1. The system protection offered by SE for Android relies on the
> assumption of kernel integrity. If the kernel itself is compromised (by
> a perhaps as yet unknown future vulnerability), SE for Android security
> mechanisms could potentially be disabled and rendered ineffective.
> 2. Qualcomm Snapdragon devices use Secure Boot, which adds cryptographic
> checks to each stage of the boot-up process, to assert the authenticity
> of all secure software images that the device executes.  However, due to
> various vulnerabilities in SW modules, the integrity of the system can be
> compromised at any time after device boot-up, leading to un-authorized
> SW executing.

It would be helpful if you characterized the "various vulnerabilities"
rather than simply asserting their existence. This would allow the reviewer
to determine if the proposed patch addresses the issue.

>
> The feature's idea is to move some sensitive kernel structures to a
> separate page and monitor further any unauthorized changes to these,
> from higher Exception Levels using stage 2 MMU. Moving these to a
> different page will help avoid getting page faults from un-related data.

I've always been a little slow when it comes to understanding the
details of advanced memory management facilities. That's part of
why I work in access control. Could you expand this a bit, so that
someone who doesn't already know how your stage 2 MMU works might
be able to evaluate what you're doing here.

> Using this mechanism, some sensitive variables of the kernel which are
> initialized after init or are updated rarely can also be protected from
> simple overwrites and attacks trying to modify these.

How would this interact with or complement __read_mostly?

>
> Currently, the change moves selinux_state structure to a separate page. In
> future we plan to move more security-related kernel assets to this page to
> enhance protection.

What's special about selinux_state? What about the SELinux policy?
How would I, as maintainer of the Smack security module, know if
some Smack data should be treated the same way? 

>
> We want to seek your suggestions and comments on the idea and the changes
> in the patch.
>
> Signed-off-by: Preeti Nagar <pnagar@codeaurora.org>
> ---
>  include/asm-generic/vmlinux.lds.h | 10 ++++++++++
>  include/linux/init.h              |  4 ++++
>  security/Kconfig                  | 10 ++++++++++
>  security/selinux/hooks.c          |  4 ++++
>  4 files changed, 28 insertions(+)
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index b2b3d81..158dbc2 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -770,6 +770,15 @@
>  		*(.scommon)						\
>  	}
>  
> +#ifdef CONFIG_SECURITY_RTIC
> +#define RTIC_BSS							\
> +	. = ALIGN(PAGE_SIZE);						\
> +	KEEP(*(.bss.rtic))						\
> +	. = ALIGN(PAGE_SIZE);
> +#else
> +#define RTIC_BSS
> +#endif
> +
>  /*
>   * Allow archectures to redefine BSS_FIRST_SECTIONS to add extra
>   * sections to the front of bss.
> @@ -782,6 +791,7 @@
>  	. = ALIGN(bss_align);						\
>  	.bss : AT(ADDR(.bss) - LOAD_OFFSET) {				\
>  		BSS_FIRST_SECTIONS					\
> +		RTIC_BSS						\
>  		. = ALIGN(PAGE_SIZE);					\
>  		*(.bss..page_aligned)					\
>  		. = ALIGN(PAGE_SIZE);					\
> diff --git a/include/linux/init.h b/include/linux/init.h
> index 7b53cb3..617adcf 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -300,6 +300,10 @@ void __init parse_early_options(char *cmdline);
>  /* Data marked not to be saved by software suspend */
>  #define __nosavedata __section(".data..nosave")
>  
> +#ifdef CONFIG_SECURITY_RTIC
> +#define __rticdata  __section(".bss.rtic")
> +#endif
> +
>  #ifdef MODULE
>  #define __exit_p(x) x
>  #else
> diff --git a/security/Kconfig b/security/Kconfig
> index 7561f6f..66b61b9 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -291,5 +291,15 @@ config LSM
>  
>  source "security/Kconfig.hardening"
>  
> +config SECURITY_RTIC
> +        bool "RunTime Integrity Check feature"

Shouldn't this depend on the architecture(s) supporting the
feature?

> +        help
> +	  RTIC(RunTime Integrity Check) feature is to protect Linux kernel
> +	  at runtime. This relocates some of the security sensitive kernel
> +	  structures to a separate page aligned special section.
> +
> +	  This is to enable monitoring and protection of these kernel assets
> +	  from a higher exception level(EL) against any unauthorized changes.

"if you are unsure ..."

> +
>  endmenu
>  
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 6b1826f..7add17c 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -104,7 +104,11 @@
>  #include "audit.h"
>  #include "avc_ss.h"
>  
> +#ifdef CONFIG_SECURITY_RTIC
> +struct selinux_state selinux_state __rticdata;
> +#else
>  struct selinux_state selinux_state;
> +#endif

Shouldn't the __rticdata tag be applied always, and its
definition take care of the cases where it doesn't do anything?

>  
>  /* SECMARK reference count */
>  static atomic_t selinux_secmark_refcount = ATOMIC_INIT(0);
Nick Desaulniers Jan. 9, 2021, 1:01 a.m. UTC | #4
Via:
https://lore.kernel.org/lkml/1610099389-28329-1-git-send-email-pnagar@codeaurora.org/

> diff --git a/include/linux/init.h b/include/linux/init.h
> index 7b53cb3..617adcf 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -300,6 +300,10 @@ void __init parse_early_options(char *cmdline);
>  /* Data marked not to be saved by software suspend */
>  #define __nosavedata __section(".data..nosave")
>  
> +#ifdef CONFIG_SECURITY_RTIC
> +#define __rticdata  __section(".bss.rtic")

if you put:

#else
#define __rticdata

here, then you wouldn't need to label each datum you put in there.

> +#endif
> +
>  #ifdef MODULE
>  #define __exit_p(x) x
>  #else

> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -104,7 +104,11 @@
>  #include "audit.h"
>  #include "avc_ss.h"
>  
> +#ifdef CONFIG_SECURITY_RTIC
> +struct selinux_state selinux_state __rticdata;
> +#else
>  struct selinux_state selinux_state;
> +#endif

so you could then drop the if-def here.


Happy to see this resolved when building with LLD+LTO, which has been a
problem in the past.

Disabling selinux is a common attack vector on Android devices, so happy
to see some effort towards mitigation.  You might want to communicate
the feature more to existing OEMs that are using your chipsets that
support this feature.
Preeti Nagar Jan. 11, 2021, 6:25 a.m. UTC | #5
On 2021-01-08 20:55, Miguel Ojeda wrote:
> On Fri, Jan 8, 2021 at 10:52 AM Preeti Nagar <pnagar@codeaurora.org> 
> wrote:
>> 
>> We want to seek your suggestions and comments on the idea and the 
>> changes
>> in the patch.
> 
> Not sure why I was Cc'd, but I have a quick comment nevertheless.
> 
>> +#ifdef CONFIG_SECURITY_RTIC
>> +struct selinux_state selinux_state __rticdata;
>> +#else
>>  struct selinux_state selinux_state;
>> +#endif
> 
> If you define an empty __rticdata for the !CONFIG case, then we don't
> need #ifdefs for uses like this.
> 
> Cheers,
> Miguel
Thank you for the review! Will update this change in the next version of 
the patch soon.

Thanks,
Preeti
Preeti Nagar Jan. 11, 2021, 9:51 a.m. UTC | #6
On 2021-01-09 06:31, Nick Desaulniers wrote:
> Via:
> https://lore.kernel.org/lkml/1610099389-28329-1-git-send-email-pnagar@codeaurora.org/
> 
>> diff --git a/include/linux/init.h b/include/linux/init.h
>> index 7b53cb3..617adcf 100644
>> --- a/include/linux/init.h
>> +++ b/include/linux/init.h
>> @@ -300,6 +300,10 @@ void __init parse_early_options(char *cmdline);
>>  /* Data marked not to be saved by software suspend */
>>  #define __nosavedata __section(".data..nosave")
>> 
>> +#ifdef CONFIG_SECURITY_RTIC
>> +#define __rticdata  __section(".bss.rtic")
> 
> if you put:
> 
> #else
> #define __rticdata
> 
> here, then you wouldn't need to label each datum you put in there.
> 
>> +#endif
>> +
>>  #ifdef MODULE
>>  #define __exit_p(x) x
>>  #else
> 
>> --- a/security/selinux/hooks.c
>> +++ b/security/selinux/hooks.c
>> @@ -104,7 +104,11 @@
>>  #include "audit.h"
>>  #include "avc_ss.h"
>> 
>> +#ifdef CONFIG_SECURITY_RTIC
>> +struct selinux_state selinux_state __rticdata;
>> +#else
>>  struct selinux_state selinux_state;
>> +#endif
> 
> so you could then drop the if-def here.
Will update this in next version, thank you for the suggestion.

> Happy to see this resolved when building with LLD+LTO, which has been a
> problem in the past.
Yes, downstream we have this verified with LTO configs enabled. Let us 
know if
you are suggesting to check anything additionally here.

> Disabling selinux is a common attack vector on Android devices, so 
> happy
> to see some effort towards mitigation.  You might want to communicate
> the feature more to existing OEMs that are using your chipsets that
> support this feature.
Glad to know the idea looks good! Yes, we will work on that, will 
communicate
internally as well, thank you.
Preeti Nagar Jan. 12, 2021, 9:36 a.m. UTC | #7
On 2021-01-08 22:41, Casey Schaufler wrote:
> On 1/8/2021 1:49 AM, Preeti Nagar wrote:
>> The changes introduce a new security feature, RunTime Integrity Check
>> (RTIC), designed to protect Linux Kernel at runtime. The motivation
>> behind these changes is:
>> 1. The system protection offered by SE for Android relies on the
>> assumption of kernel integrity. If the kernel itself is compromised 
>> (by
>> a perhaps as yet unknown future vulnerability), SE for Android 
>> security
>> mechanisms could potentially be disabled and rendered ineffective.
>> 2. Qualcomm Snapdragon devices use Secure Boot, which adds 
>> cryptographic
>> checks to each stage of the boot-up process, to assert the 
>> authenticity
>> of all secure software images that the device executes.  However, due 
>> to
>> various vulnerabilities in SW modules, the integrity of the system can 
>> be
>> compromised at any time after device boot-up, leading to un-authorized
>> SW executing.
> 
> It would be helpful if you characterized the "various vulnerabilities"
> rather than simply asserting their existence. This would allow the 
> reviewer
> to determine if the proposed patch addresses the issue.
> 
There might not currently be vulnerabilities, but the system is meant 
more
specifically to harden valuable assets against future compromises. The 
key
value add is a third party independent entity keeping a watch on crucial
kernel assets.

>> 
>> The feature's idea is to move some sensitive kernel structures to a
>> separate page and monitor further any unauthorized changes to these,
>> from higher Exception Levels using stage 2 MMU. Moving these to a
>> different page will help avoid getting page faults from un-related 
>> data.
> 
> I've always been a little slow when it comes to understanding the
> details of advanced memory management facilities. That's part of
> why I work in access control. Could you expand this a bit, so that
> someone who doesn't already know how your stage 2 MMU works might
> be able to evaluate what you're doing here.
> 
Sure, will include more details. The mechanism we have been working on
removes the write permissions for HLOS in the stage 2 page tables for
the regions to be monitored, such that any modification attempts to 
these
will lead to faults being generated and handled by handlers. If the
protected assets are moved to a separate page, faults will be generated
corresponding to change attempts to these assets only. If not moved to a
separate page, write attempts to un-related data which is present on the
monitored pages will also be generated.

>> Using this mechanism, some sensitive variables of the kernel which are
>> initialized after init or are updated rarely can also be protected 
>> from
>> simple overwrites and attacks trying to modify these.
> 
> How would this interact with or complement __read_mostly?
> 
Currently, the mechanism we are working on developing is
independent of __read_mostly. This is something we can look more into
while working further on the mechanism.

>> 
>> Currently, the change moves selinux_state structure to a separate 
>> page. In
>> future we plan to move more security-related kernel assets to this 
>> page to
>> enhance protection.
> 
> What's special about selinux_state? What about the SELinux policy?
> How would I, as maintainer of the Smack security module, know if
> some Smack data should be treated the same way?
> 
We are investigating more of the SELinux related and other kernel assets
which can be included in the protection. The basis of selinux_state is
because disabling of SELinux is one of the common attack vectors in
Android. We understand any kernel assets, unauthorized changes to which
can give way to security or any other type of attack can be considered 
to
be a potential asset to be added to the protection.

>> 
>> We want to seek your suggestions and comments on the idea and the 
>> changes
>> in the patch.
>> 
>> Signed-off-by: Preeti Nagar <pnagar@codeaurora.org>
>> ---
>>  include/asm-generic/vmlinux.lds.h | 10 ++++++++++
>>  include/linux/init.h              |  4 ++++
>>  security/Kconfig                  | 10 ++++++++++
>>  security/selinux/hooks.c          |  4 ++++
>>  4 files changed, 28 insertions(+)
>> 
>> diff --git a/include/asm-generic/vmlinux.lds.h 
>> b/include/asm-generic/vmlinux.lds.h
>> index b2b3d81..158dbc2 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -770,6 +770,15 @@
>>  		*(.scommon)						\
>>  	}
>> 
>> +#ifdef CONFIG_SECURITY_RTIC
>> +#define RTIC_BSS							\
>> +	. = ALIGN(PAGE_SIZE);						\
>> +	KEEP(*(.bss.rtic))						\
>> +	. = ALIGN(PAGE_SIZE);
>> +#else
>> +#define RTIC_BSS
>> +#endif
>> +
>>  /*
>>   * Allow archectures to redefine BSS_FIRST_SECTIONS to add extra
>>   * sections to the front of bss.
>> @@ -782,6 +791,7 @@
>>  	. = ALIGN(bss_align);						\
>>  	.bss : AT(ADDR(.bss) - LOAD_OFFSET) {				\
>>  		BSS_FIRST_SECTIONS					\
>> +		RTIC_BSS						\
>>  		. = ALIGN(PAGE_SIZE);					\
>>  		*(.bss..page_aligned)					\
>>  		. = ALIGN(PAGE_SIZE);					\
>> diff --git a/include/linux/init.h b/include/linux/init.h
>> index 7b53cb3..617adcf 100644
>> --- a/include/linux/init.h
>> +++ b/include/linux/init.h
>> @@ -300,6 +300,10 @@ void __init parse_early_options(char *cmdline);
>>  /* Data marked not to be saved by software suspend */
>>  #define __nosavedata __section(".data..nosave")
>> 
>> +#ifdef CONFIG_SECURITY_RTIC
>> +#define __rticdata  __section(".bss.rtic")
>> +#endif
>> +
>>  #ifdef MODULE
>>  #define __exit_p(x) x
>>  #else
>> diff --git a/security/Kconfig b/security/Kconfig
>> index 7561f6f..66b61b9 100644
>> --- a/security/Kconfig
>> +++ b/security/Kconfig
>> @@ -291,5 +291,15 @@ config LSM
>> 
>>  source "security/Kconfig.hardening"
>> 
>> +config SECURITY_RTIC
>> +        bool "RunTime Integrity Check feature"
> 
> Shouldn't this depend on the architecture(s) supporting the
> feature?
> 
>> +        help
>> +	  RTIC(RunTime Integrity Check) feature is to protect Linux kernel
>> +	  at runtime. This relocates some of the security sensitive kernel
>> +	  structures to a separate page aligned special section.
>> +
>> +	  This is to enable monitoring and protection of these kernel assets
>> +	  from a higher exception level(EL) against any unauthorized 
>> changes.
> 
> "if you are unsure ..."
> 
We just thought keeping it generic might be a better idea, thus, moved 
the
changes to generic files from arch-specific files and thus, kept config 
also
independent of the arch. Can surely make this config arch dependent if 
that is
a better approach?

>> +
>>  endmenu
>> 
>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> index 6b1826f..7add17c 100644
>> --- a/security/selinux/hooks.c
>> +++ b/security/selinux/hooks.c
>> @@ -104,7 +104,11 @@
>>  #include "audit.h"
>>  #include "avc_ss.h"
>> 
>> +#ifdef CONFIG_SECURITY_RTIC
>> +struct selinux_state selinux_state __rticdata;
>> +#else
>>  struct selinux_state selinux_state;
>> +#endif
> 
> Shouldn't the __rticdata tag be applied always, and its
> definition take care of the cases where it doesn't do anything?
> 
Will update this change in the next version of the patch. Thank you.

>> 
>>  /* SECMARK reference count */
>>  static atomic_t selinux_secmark_refcount = ATOMIC_INIT(0);
Casey Schaufler Jan. 12, 2021, 5:06 p.m. UTC | #8
On 1/12/2021 1:36 AM, pnagar@codeaurora.org wrote:
> On 2021-01-08 22:41, Casey Schaufler wrote:
>> On 1/8/2021 1:49 AM, Preeti Nagar wrote:
>>> The changes introduce a new security feature, RunTime Integrity Check
>>> (RTIC), designed to protect Linux Kernel at runtime. The motivation
>>> behind these changes is:
>>> 1. The system protection offered by SE for Android relies on the
>>> assumption of kernel integrity. If the kernel itself is compromised (by
>>> a perhaps as yet unknown future vulnerability), SE for Android security
>>> mechanisms could potentially be disabled and rendered ineffective.
>>> 2. Qualcomm Snapdragon devices use Secure Boot, which adds cryptographic
>>> checks to each stage of the boot-up process, to assert the authenticity
>>> of all secure software images that the device executes.  However, due to
>>> various vulnerabilities in SW modules, the integrity of the system can be
>>> compromised at any time after device boot-up, leading to un-authorized
>>> SW executing.
>>
>> It would be helpful if you characterized the "various vulnerabilities"
>> rather than simply asserting their existence. This would allow the reviewer
>> to determine if the proposed patch addresses the issue.
>>
> There might not currently be vulnerabilities, but the system is meant more
> specifically to harden valuable assets against future compromises. The key
> value add is a third party independent entity keeping a watch on crucial
> kernel assets.

Could you characterize the potential vulnerabilities, then?
Seriously, there's a gazillion ways data integrity can be
compromised. Which of those are addressed?

>
>>>
>>> The feature's idea is to move some sensitive kernel structures to a
>>> separate page and monitor further any unauthorized changes to these,
>>> from higher Exception Levels using stage 2 MMU. Moving these to a
>>> different page will help avoid getting page faults from un-related data.
>>
>> I've always been a little slow when it comes to understanding the
>> details of advanced memory management facilities. That's part of
>> why I work in access control. Could you expand this a bit, so that
>> someone who doesn't already know how your stage 2 MMU works might
>> be able to evaluate what you're doing here.
>>
> Sure, will include more details. The mechanism we have been working on
> removes the write permissions for HLOS in the stage 2 page tables for
> the regions to be monitored, such that any modification attempts to these
> will lead to faults being generated and handled by handlers. If the
> protected assets are moved to a separate page, faults will be generated
> corresponding to change attempts to these assets only. If not moved to a
> separate page, write attempts to un-related data which is present on the
> monitored pages will also be generated.

Thanks.

>
>>> Using this mechanism, some sensitive variables of the kernel which are
>>> initialized after init or are updated rarely can also be protected from
>>> simple overwrites and attacks trying to modify these.
>>
>> How would this interact with or complement __read_mostly?
>>
> Currently, the mechanism we are working on developing is
> independent of __read_mostly. This is something we can look more into
> while working further on the mechanism.

Please either integrate the two or explain how they differ.
It appears that you haven't considered how you might exploit
or expand the existing mechanism.

>
>>>
>>> Currently, the change moves selinux_state structure to a separate page. In
>>> future we plan to move more security-related kernel assets to this page to
>>> enhance protection.
>>
>> What's special about selinux_state? What about the SELinux policy?
>> How would I, as maintainer of the Smack security module, know if
>> some Smack data should be treated the same way?
>>
> We are investigating more of the SELinux related and other kernel assets
> which can be included in the protection. The basis of selinux_state is
> because disabling of SELinux is one of the common attack vectors in
> Android. We understand any kernel assets, unauthorized changes to which
> can give way to security or any other type of attack can be considered to
> be a potential asset to be added to the protection.

Yeah, I get that. It looks like this could be a useful mechanism
beyond SELinux. No point in hoarding it.

>
>>>
>>> We want to seek your suggestions and comments on the idea and the changes
>>> in the patch.
>>>
>>> Signed-off-by: Preeti Nagar <pnagar@codeaurora.org>
>>> ---
>>>  include/asm-generic/vmlinux.lds.h | 10 ++++++++++
>>>  include/linux/init.h              |  4 ++++
>>>  security/Kconfig                  | 10 ++++++++++
>>>  security/selinux/hooks.c          |  4 ++++
>>>  4 files changed, 28 insertions(+)
>>>
>>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>>> index b2b3d81..158dbc2 100644
>>> --- a/include/asm-generic/vmlinux.lds.h
>>> +++ b/include/asm-generic/vmlinux.lds.h
>>> @@ -770,6 +770,15 @@
>>>          *(.scommon)                        \
>>>      }
>>>
>>> +#ifdef CONFIG_SECURITY_RTIC
>>> +#define RTIC_BSS                            \
>>> +    . = ALIGN(PAGE_SIZE);                        \
>>> +    KEEP(*(.bss.rtic))                        \
>>> +    . = ALIGN(PAGE_SIZE);
>>> +#else
>>> +#define RTIC_BSS
>>> +#endif
>>> +
>>>  /*
>>>   * Allow archectures to redefine BSS_FIRST_SECTIONS to add extra
>>>   * sections to the front of bss.
>>> @@ -782,6 +791,7 @@
>>>      . = ALIGN(bss_align);                        \
>>>      .bss : AT(ADDR(.bss) - LOAD_OFFSET) {                \
>>>          BSS_FIRST_SECTIONS                    \
>>> +        RTIC_BSS                        \
>>>          . = ALIGN(PAGE_SIZE);                    \
>>>          *(.bss..page_aligned)                    \
>>>          . = ALIGN(PAGE_SIZE);                    \
>>> diff --git a/include/linux/init.h b/include/linux/init.h
>>> index 7b53cb3..617adcf 100644
>>> --- a/include/linux/init.h
>>> +++ b/include/linux/init.h
>>> @@ -300,6 +300,10 @@ void __init parse_early_options(char *cmdline);
>>>  /* Data marked not to be saved by software suspend */
>>>  #define __nosavedata __section(".data..nosave")
>>>
>>> +#ifdef CONFIG_SECURITY_RTIC
>>> +#define __rticdata  __section(".bss.rtic")
>>> +#endif
>>> +
>>>  #ifdef MODULE
>>>  #define __exit_p(x) x
>>>  #else
>>> diff --git a/security/Kconfig b/security/Kconfig
>>> index 7561f6f..66b61b9 100644
>>> --- a/security/Kconfig
>>> +++ b/security/Kconfig
>>> @@ -291,5 +291,15 @@ config LSM
>>>
>>>  source "security/Kconfig.hardening"
>>>
>>> +config SECURITY_RTIC
>>> +        bool "RunTime Integrity Check feature"
>>
>> Shouldn't this depend on the architecture(s) supporting the
>> feature?
>>
>>> +        help
>>> +      RTIC(RunTime Integrity Check) feature is to protect Linux kernel
>>> +      at runtime. This relocates some of the security sensitive kernel
>>> +      structures to a separate page aligned special section.
>>> +
>>> +      This is to enable monitoring and protection of these kernel assets
>>> +      from a higher exception level(EL) against any unauthorized changes.
>>
>> "if you are unsure ..."
>>
> We just thought keeping it generic might be a better idea, thus, moved the
> changes to generic files from arch-specific files and thus, kept config also
> independent of the arch. Can surely make this config arch dependent if that is
> a better approach?

It's kind of silly to enable this if the hardware doesn't
support it, isn't it?

>
>>> +
>>>  endmenu
>>>
>>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>>> index 6b1826f..7add17c 100644
>>> --- a/security/selinux/hooks.c
>>> +++ b/security/selinux/hooks.c
>>> @@ -104,7 +104,11 @@
>>>  #include "audit.h"
>>>  #include "avc_ss.h"
>>>
>>> +#ifdef CONFIG_SECURITY_RTIC
>>> +struct selinux_state selinux_state __rticdata;
>>> +#else
>>>  struct selinux_state selinux_state;
>>> +#endif
>>
>> Shouldn't the __rticdata tag be applied always, and its
>> definition take care of the cases where it doesn't do anything?
>>
> Will update this change in the next version of the patch. Thank you.

I saw that several other people had the same comment.

>
>>>
>>>  /* SECMARK reference count */
>>>  static atomic_t selinux_secmark_refcount = ATOMIC_INIT(0);
David Howells Jan. 13, 2021, 10:56 a.m. UTC | #9
Casey Schaufler <casey@schaufler-ca.com> wrote:

> >> How would this interact with or complement __read_mostly?
> >>
> > Currently, the mechanism we are working on developing is
> > independent of __read_mostly. This is something we can look more into
> > while working further on the mechanism.
> 
> Please either integrate the two or explain how they differ.
> It appears that you haven't considered how you might exploit
> or expand the existing mechanism.

I think __read_mostly is about grouping stuff together that's rarely going to
be read to make the CPU's data cache more efficient.  It doesn't stop people
writing to such a variable.

David
Preeti Nagar Jan. 18, 2021, 6:15 a.m. UTC | #10
On 2021-01-13 16:26, David Howells wrote:
> Casey Schaufler <casey@schaufler-ca.com> wrote:
> 
>> >> How would this interact with or complement __read_mostly?
>> >>
>> > Currently, the mechanism we are working on developing is
>> > independent of __read_mostly. This is something we can look more into
>> > while working further on the mechanism.
>> 
>> Please either integrate the two or explain how they differ.
>> It appears that you haven't considered how you might exploit
>> or expand the existing mechanism.
> 
> I think __read_mostly is about grouping stuff together that's rarely 
> going to
> be read to make the CPU's data cache more efficient.  It doesn't stop 
> people
> writing to such a variable.
> 
> David
Thank you for sharing!
diff mbox series

Patch

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index b2b3d81..158dbc2 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -770,6 +770,15 @@ 
 		*(.scommon)						\
 	}
 
+#ifdef CONFIG_SECURITY_RTIC
+#define RTIC_BSS							\
+	. = ALIGN(PAGE_SIZE);						\
+	KEEP(*(.bss.rtic))						\
+	. = ALIGN(PAGE_SIZE);
+#else
+#define RTIC_BSS
+#endif
+
 /*
  * Allow archectures to redefine BSS_FIRST_SECTIONS to add extra
  * sections to the front of bss.
@@ -782,6 +791,7 @@ 
 	. = ALIGN(bss_align);						\
 	.bss : AT(ADDR(.bss) - LOAD_OFFSET) {				\
 		BSS_FIRST_SECTIONS					\
+		RTIC_BSS						\
 		. = ALIGN(PAGE_SIZE);					\
 		*(.bss..page_aligned)					\
 		. = ALIGN(PAGE_SIZE);					\
diff --git a/include/linux/init.h b/include/linux/init.h
index 7b53cb3..617adcf 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -300,6 +300,10 @@  void __init parse_early_options(char *cmdline);
 /* Data marked not to be saved by software suspend */
 #define __nosavedata __section(".data..nosave")
 
+#ifdef CONFIG_SECURITY_RTIC
+#define __rticdata  __section(".bss.rtic")
+#endif
+
 #ifdef MODULE
 #define __exit_p(x) x
 #else
diff --git a/security/Kconfig b/security/Kconfig
index 7561f6f..66b61b9 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -291,5 +291,15 @@  config LSM
 
 source "security/Kconfig.hardening"
 
+config SECURITY_RTIC
+        bool "RunTime Integrity Check feature"
+        help
+	  RTIC(RunTime Integrity Check) feature is to protect Linux kernel
+	  at runtime. This relocates some of the security sensitive kernel
+	  structures to a separate page aligned special section.
+
+	  This is to enable monitoring and protection of these kernel assets
+	  from a higher exception level(EL) against any unauthorized changes.
+
 endmenu
 
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 6b1826f..7add17c 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -104,7 +104,11 @@ 
 #include "audit.h"
 #include "avc_ss.h"
 
+#ifdef CONFIG_SECURITY_RTIC
+struct selinux_state selinux_state __rticdata;
+#else
 struct selinux_state selinux_state;
+#endif
 
 /* SECMARK reference count */
 static atomic_t selinux_secmark_refcount = ATOMIC_INIT(0);