lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 16 Feb 2017 17:08:20 -0800
From:   Kees Cook <>
To:     Pavel Machek <>
Cc:     Laura Abbott <>,
        Mark Rutland <>,
        "" <>,
        Catalin Marinas <>,
        Heiko Carstens <>,
        "James E.J. Bottomley" <>,
        "H. Peter Anvin" <>,
        Rob Herring <>, Jessica Yu <>,
        Jonathan Corbet <>, Helge Deller <>,
        "" <>,
        Russell King <>,
        Ingo Molnar <>,
        Len Brown <>,
        "" <>,
        Will Deacon <>,
        Thomas Gleixner <>,
        linux-parisc <>,
        Linux PM list <>,
        "Rafael J. Wysocki" <>,
        LKML <>,
        Jason Wessel <>,
        Martin Schwidefsky <>,
        Robin Murphy <>

On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek <> wrote:
> Hi!
>> -config DEBUG_RODATA
>>       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 Cook
Pixel Security

Powered by blists - more mailing lists