linux-kernel - Re: [RFC PATCH 25/28] x86: Use PIE codegen for the core kernel

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <ZvUf7pkvq3m9wYjr@tassilo>
Date: Thu, 26 Sep 2024 01:48:46 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org,
	x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
	Andy Lutomirski <luto@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Uros Bizjak <ubizjak@...il.com>, Dennis Zhou <dennis@...nel.org>,
	Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Vitaly Kuznetsov <vkuznets@...hat.com>,
	Juergen Gross <jgross@...e.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Masahiro Yamada <masahiroy@...nel.org>, Kees Cook <kees@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Keith Packard <keithp@...thp.com>,
	Justin Stitt <justinstitt@...gle.com>,
	Josh Poimboeuf <jpoimboe@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>, hjl.tools@...il.com,
	hubicka@....cz
Subject: Re: [RFC PATCH 25/28] x86: Use PIE codegen for the core kernel

On Wed, Sep 25, 2024 at 11:23:39PM +0200, Ard Biesheuvel wrote:
> > What matters is what it does to general performance.
> >
> > Traditionally even on x86-64 PIC/E has a cost and the kernel model
> > was intended to avoid that.
> >
> 
> Is the x86_64 kernel C model specified anywhere, to your knowledge?

The basics are in the ABI. Maybe some of the details of TLS / stack
protector are missing (I guess that could be fixed, adding HJ)

Some of the motivation was also in early papers like
https://www.ucw.cz/~hubicka/papers/amd64/amd64.html

I'm copying Honza Hubicka who did the original work.

> 
> > From my perspective this patch kit doesn't fix a real problem,
> > it's all risk of performance regression with no gain.
> >
> 
> It's all in the cover letter and the commit logs so I won't rehash it
> here, but I understand that your priorities may be different from
> mine.

It sounded fairly nebulous to me. If Linux wanted to support a third tool chain
and it didn't support the kernel model yet it would be somehow easier.
Apart from the kernel model likely being one of the minor issues
in such a endeavour, I don't see a third tool chain othan than gcc and llvm
anywhere on the horizon?

> 
> I'll provide some numbers about the impact on code size. Are there any
> other performance related aspects that you think might be impacted by
> the use of position independent code generation?

Code size isn't a sufficient metric either.

Linux sometimes goes to great length for small gains, for example
there was a huge effort to avoid frame pointers, even though it's a
small percentage delta. PIC could well be larger than frame pointers.

You need to run it with some real workloads, e.g. some of the kernel
oriented workloads in 0day or phoronix, and see if there are
performance regressions.

Unfortunately for an intrusive change like this this might also vary for
different CPUs, so may need some more coverage.

-Andi