linux-hardening - Re: KFENCE: included in x86 defconfig?

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]

Date: Thu, 8 Feb 2024 13:01:55 +0100
From: Borislav Petkov <bp@...en8.de>
To: Marco Elver <elver@...gle.com>
Cc: Jakub Kicinski <kuba@...nel.org>, Matthieu Baerts <matttbe@...nel.org>,
	Alexander Potapenko <glider@...gle.com>,
	Dmitry Vyukov <dvyukov@...gle.com>, kasan-dev@...glegroups.com,
	Netdev <netdev@...r.kernel.org>, linux-hardening@...r.kernel.org,
	Kees Cook <keescook@...omium.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: KFENCE: included in x86 defconfig?

On Thu, Feb 08, 2024 at 12:12:19PM +0100, Marco Elver wrote:
> git log --grep 'BUG: KFENCE: '
> 
> There are more I'm aware of - also plenty I know of in downstream
> kernels (https://arxiv.org/pdf/2311.09394.pdf - Section 5.7).

Good.

> This is a problem shared by all other diagnostic and error reports the
> kernel produces.

Yes, and it becomes a problem if you expose it to the wider audience.

And yes, nothing new here - it is the same ol' question of getting good
bug reports.

> It's not a KASAN replacement, since it's sampling based.

I meant this: "Compared to KASAN, KFENCE trades performance for
precision."

And yeah, I did read what you pasted.

> From the Documentation: "KFENCE is designed to be enabled in
> production kernels, and has near zero performance overhead. Compared
> to KASAN, KFENCE trades performance for precision. The main motivation
> behind KFENCE's design, is that with enough total uptime KFENCE will
> detect bugs in code paths not typically exercised by non-production
> test workloads.

What is that double negation supposed to mean?

That it'll detect bugs in code paths that are typically exercised by
production test workloads?

> One way to quickly achieve a large enough total uptime is
> when the tool is deployed across a large fleet of machines."

In any case, I'll enable it on my test machines and see what happens.

> No reports are good. Doesn't mean absence of bugs though. :-)

As long as I don't know about them, I'm good. :-P

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette