Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1582982 > unrolled thread

Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX

Started byPavel Machek <pavel@ucw.cz>
First post2017-02-16 23:30 +0100
Last post2017-02-20 08:30 +0100
Articles 5 — 5 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and  CONFIG_DEBUG_MODULE_RONX Pavel Machek <pavel@ucw.cz> - 2017-02-16 23:30 +0100
    Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX Kees Cook <keescook@chromium.org> - 2017-02-17 02:10 +0100
      Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and  CONFIG_DEBUG_MODULE_RONX Helge Deller <deller@gmx.de> - 2017-02-17 09:30 +0100
      Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and  CONFIG_DEBUG_MODULE_RONX Mark Rutland <mark.rutland@arm.com> - 2017-02-17 19:30 +0100
      Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and  CONFIG_DEBUG_MODULE_RONX Ingo Molnar <mingo@kernel.org> - 2017-02-20 08:30 +0100

#1582982 — Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX

FromPavel Machek <pavel@ucw.cz>
Date2017-02-16 23:30 +0100
SubjectRe: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX
Message-ID<tbCIO-4eZ-27@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Hi!

>  
> -config DEBUG_RODATA
> +config STRICT_KERNEL_RWX
>  	bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
>  	depends on ARCH_HAS_STRICT_KERNEL_RWX
>  	default !ARCH_OPTIONAL_KERNEL_RWX ||

Debug features are expected to have runtime cost, so kconfig help is
silent about those. But there are runtime costs, right? It would be
nice to mention them in the help text...

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [next] | [standalone]


#1583011 — Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX

FromKees Cook <keescook@chromium.org>
Date2017-02-17 02:10 +0100
SubjectRe: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX
Message-ID<tbFdD-5Q6-13@gated-at.bofh.it>
In reply to#1582982
On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>>
>> -config DEBUG_RODATA
>> +config STRICT_KERNEL_RWX
>>       bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
>>       depends on ARCH_HAS_STRICT_KERNEL_RWX
>>       default !ARCH_OPTIONAL_KERNEL_RWX ||
>
> Debug features are expected to have runtime cost, so kconfig help is
> silent about those. But there are runtime costs, right? It would be
> nice to mention them in the help text...

It depends on the architecture. The prior help text for arm said:

         The tradeoff is that each region is padded to section-size (1MiB)
         boundaries (because their permissions are different and splitting
         the 1M pages into 4K ones causes TLB performance problems), which
         can waste memory.

parisc (somewhat inaccurately) said:

         This option may have a slight performance impact because a
         portion of the kernel code won't be covered by a TLB anymore.

IIUC, arm64 does what parisc is hinting at: mappings at the end are
broken down to PAGE_SIZE. On x86, IIUC, there's actually no change to
TLB performance due to how the mappings are already set up.

I'm not sure the best way to express this in the new help text. Do you
have some suggestions on wording? Personally, I don't really think
it's worth mentioning this in Kconfig help, which, in theory, is
supposed to limit how technical it gets. And I think the performance
impact is almost entirely negligible compared to the risks addressed.

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]


#1583195

FromHelge Deller <deller@gmx.de>
Date2017-02-17 09:30 +0100
Message-ID<tbM5s-1KD-9@gated-at.bofh.it>
In reply to#1583011
On 17.02.2017 02:08, Kees Cook wrote:
> On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> Hi!
>>
>>>
>>> -config DEBUG_RODATA
>>> +config STRICT_KERNEL_RWX
>>>       bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
>>>       depends on ARCH_HAS_STRICT_KERNEL_RWX
>>>       default !ARCH_OPTIONAL_KERNEL_RWX ||
>>
>> Debug features are expected to have runtime cost, so kconfig help is
>> silent about those. But there are runtime costs, right? It would be
>> nice to mention them in the help text...
> 
> It depends on the architecture. The prior help text for arm said:
> 
>          The tradeoff is that each region is padded to section-size (1MiB)
>          boundaries (because their permissions are different and splitting
>          the 1M pages into 4K ones causes TLB performance problems), which
>          can waste memory.
> 
> parisc (somewhat inaccurately) said:
> 
>          This option may have a slight performance impact because a
>          portion of the kernel code won't be covered by a TLB anymore.

The logic on parisc is actually:
If huge page support is enabled, we map 1MB pages (and behave like arm wrt alignments).
If huge page support is disabled we stay at 4k/PAGE_SIZE pages (without 1M alignment).
 
> IIUC, arm64 does what parisc is hinting at: mappings at the end are
> broken down to PAGE_SIZE. 

On parisc we never implemented that.

> On x86, IIUC, there's actually no change to
> TLB performance due to how the mappings are already set up.
> 
> I'm not sure the best way to express this in the new help text. Do you
> have some suggestions on wording? Personally, I don't really think
> it's worth mentioning this in Kconfig help,

I agree on this.

> which, in theory, is
> supposed to limit how technical it gets. And I think the performance
> impact is almost entirely negligible compared to the risks addressed.

Helge

[toc] | [prev] | [next] | [standalone]


#1583636

FromMark Rutland <mark.rutland@arm.com>
Date2017-02-17 19:30 +0100
Message-ID<tbVs5-7Mv-5@gated-at.bofh.it>
In reply to#1583011
On Thu, Feb 16, 2017 at 05:08:20PM -0800, Kees Cook wrote:
> On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> >>
> >> -config DEBUG_RODATA
> >> +config STRICT_KERNEL_RWX
> >>       bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
> >>       depends on ARCH_HAS_STRICT_KERNEL_RWX
> >>       default !ARCH_OPTIONAL_KERNEL_RWX ||
> >
> > Debug features are expected to have runtime cost, so kconfig help is
> > silent about those. But there are runtime costs, right? It would be
> > nice to mention them in the help text...
> 
> It depends on the architecture. The prior help text for arm said:
> 
>          The tradeoff is that each region is padded to section-size (1MiB)
>          boundaries (because their permissions are different and splitting
>          the 1M pages into 4K ones causes TLB performance problems), which
>          can waste memory.
> 
> parisc (somewhat inaccurately) said:
> 
>          This option may have a slight performance impact because a
>          portion of the kernel code won't be covered by a TLB anymore.
> 
> IIUC, arm64 does what parisc is hinting at: mappings at the end are
> broken down to PAGE_SIZE. On x86, IIUC, there's actually no change to
> TLB performance due to how the mappings are already set up.

On arm64, we split down to page granularity if needed, but use the
largest possible mapping we can (e.g. if we can use a 2M block, we do).

Because of the way we freed the init area, we already couldn't use
larger mappings anyway. Applying the strict permissions didn't come at a
measureable overhead in any real testing.

> I'm not sure the best way to express this in the new help text. Do you
> have some suggestions on wording? Personally, I don't really think
> it's worth mentioning this in Kconfig help, which, in theory, is
> supposed to limit how technical it gets. And I think the performance
> impact is almost entirely negligible compared to the risks addressed.

I also don't see much point in describing some hypothetical architecture
specific overhead here. In most cases this can't be turned off (so there
isn't anything to comapre it to, and hence no cost). Where people want
to turn it off, they already know why they wish to do so.

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]


#1584378

FromIngo Molnar <mingo@kernel.org>
Date2017-02-20 08:30 +0100
Message-ID<tcQA1-1Dz-9@gated-at.bofh.it>
In reply to#1583011
* Kees Cook <keescook@chromium.org> wrote:

> On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> >>
> >> -config DEBUG_RODATA
> >> +config STRICT_KERNEL_RWX
> >>       bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
> >>       depends on ARCH_HAS_STRICT_KERNEL_RWX
> >>       default !ARCH_OPTIONAL_KERNEL_RWX ||
> >
> > Debug features are expected to have runtime cost, so kconfig help is
> > silent about those. But there are runtime costs, right? It would be
> > nice to mention them in the help text...
> 
> It depends on the architecture. The prior help text for arm said:
> 
>          The tradeoff is that each region is padded to section-size (1MiB)
>          boundaries (because their permissions are different and splitting
>          the 1M pages into 4K ones causes TLB performance problems), which
>          can waste memory.
> 
> parisc (somewhat inaccurately) said:
> 
>          This option may have a slight performance impact because a
>          portion of the kernel code won't be covered by a TLB anymore.
> 
> IIUC, arm64 does what parisc is hinting at: mappings at the end are
> broken down to PAGE_SIZE. On x86, IIUC, there's actually no change to
> TLB performance due to how the mappings are already set up.

BTW., a good strategy with RAM sizes above say 4GB would be to just round up to 
the next large-TLB boundary (2MB) and waste 0-2MB of RAM - which is only 0.05% of 
4GB of RAM. On most workloads, especially with SSDs it's probably a positive RAM 
vs. performance trade-off.

Thanks,

	Ingo

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web