Kernel-hardening archive on lore.kernel.org
 help / color / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Kristen Carlson Accardi <kristen@linux.intel.com>,
	mingo@redhat.com, bp@alien8.de, arjan@linux.intel.com,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	kernel-hardening@lists.openwall.com, rick.p.edgecombe@intel.com
Subject: Re: [PATCH v2 0/9] Function Granular KASLR
Date: Thu, 21 May 2020 16:30:23 -0700
Message-ID: <202005211604.86AE1C2@keescook> (raw)
In-Reply-To: <87367sudpl.fsf@nanos.tec.linutronix.de>

On Fri, May 22, 2020 at 12:26:30AM +0200, Thomas Gleixner wrote:
> I understand how this is supposed to work, but I fail to find an
> explanation how all of this is preserving the text subsections we have,
> i.e. .kprobes.text, .entry.text ...?

I had the same question when I first started looking at earlier versions
of this series! :)

> I assume that the functions in these subsections are reshuffled within
> their own randomized address space so that __xxx_text_start and
> __xxx_text_end markers still make sense, right?

No, but perhaps in the future. Right now, they are entirely ignored and
left untouched. The current series only looks at the sections produced
by -ffunction-sections, which is to say only things named ".text.$thing"
(e.g. ".text.func1", ".text.func2"). Since the "special" text sections
in the kernel are named ".$thing.text" (specifically to avoid other
long-standing linker logic that does similar .text.* pattern matches)
they get ignored by FGKASLR right now too.

Even more specifically, they're ignored because all of these special
_input_ sections are actually manually collected by the linker script
into the ".text" _output_ section, which FGKASLR ignores -- it can only
randomize the final output sections (and has no basic block visibility
into the section contents), so everything in .text is untouched. Because
these special sections are collapsed into the single .text output
section is why we've needed the __$thing_start and __$thing_end symbols
manually constructed by the linker scripts: we lose input section
location/size details once the linker collects them into an output
section.

> I'm surely too tired to figure it out from the patches, but you really
> want to explain that very detailed for mere mortals who are not deep
> into this magic as you are.

Yeah, it's worth calling out, especially since it's an area of future
work -- I think if we can move the special sections out of .text into
their own output sections that can get randomized and we'll have section
position/size information available without the manual ..._start/_end
symbols. But this will require work with the compiler and linker to get
what's needed relative to -ffunction-sections, teach the kernel about
the new way of getting _start/_end, etc etc.

So, before any of that, just .text.* is a good first step, and after
that I think next would be getting .text randomized relative to the other
.text.* sections (IIUC, it is entirely untouched currently, so only the
standard KASLR base offset moves it around). Only after that do we start
poking around trying to munge the special section contents (which
requires use solving a few problems simultaneously). :)

-- 
Kees Cook

  reply index

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-21 16:56 Kristen Carlson Accardi
2020-05-21 16:56 ` [PATCH v2 1/9] objtool: Do not assume order of parent/child functions Kristen Carlson Accardi
2020-05-21 16:56 ` [PATCH v2 2/9] x86: tools/relocs: Support >64K section headers Kristen Carlson Accardi
2020-05-21 16:56 ` [PATCH v2 3/9] x86/boot: Allow a "silent" kaslr random byte fetch Kristen Carlson Accardi
2020-05-21 16:56 ` [PATCH v2 4/9] x86: Makefile: Add build and config option for CONFIG_FG_KASLR Kristen Carlson Accardi
2020-05-21 20:00   ` Kees Cook
2020-05-21 16:56 ` [PATCH v2 5/9] x86: Make sure _etext includes function sections Kristen Carlson Accardi
2020-05-21 18:11   ` Kees Cook
2020-05-21 16:56 ` [PATCH v2 6/9] x86/tools: Add relative relocs for randomized functions Kristen Carlson Accardi
2020-05-21 19:54   ` Kees Cook
2020-05-21 16:56 ` [PATCH v2 7/9] x86: Add support for function granular KASLR Kristen Carlson Accardi
2020-05-21 21:08   ` Kees Cook
2020-05-21 21:42     ` Kristen Carlson Accardi
2020-05-21 16:56 ` [PATCH v2 8/9] kallsyms: Hide layout Kristen Carlson Accardi
2020-05-21 21:14   ` Kees Cook
2020-05-21 16:56 ` [PATCH v2 9/9] module: Reorder functions Kristen Carlson Accardi
2020-05-21 21:33   ` Kees Cook
2020-05-21 21:54 ` [PATCH v2 0/9] Function Granular KASLR Kees Cook
2020-05-21 22:26 ` Thomas Gleixner
2020-05-21 23:30   ` Kees Cook [this message]
2020-05-21 23:43     ` Thomas Gleixner
2020-05-21 23:44     ` Kristen Carlson Accardi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202005211604.86AE1C2@keescook \
    --to=keescook@chromium.org \
    --cc=arjan@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kristen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Kernel-hardening archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernel-hardening/0 kernel-hardening/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernel-hardening kernel-hardening/ https://lore.kernel.org/kernel-hardening \
		kernel-hardening@lists.openwall.com
	public-inbox-index kernel-hardening

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.openwall.lists.kernel-hardening


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git