linux-kernel - Re: [PATCH v2 0/5] implement lightweight guard pages

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: <CACT4Y+Z=fjoOxn8NY8kYJd2CC1SkmjkmAmqSzJbQiU04G=BEvw@mail.gmail.com>
Date: Wed, 23 Oct 2024 11:17:05 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, David Hildenbrand <david@...hat.com>, fw@...eb.enyo.de, 
	James.Bottomley@...senpartnership.com, Liam.Howlett@...cle.com, 
	akpm@...ux-foundation.org, arnd@...db.de, brauner@...nel.org, 
	chris@...kel.net, deller@....de, hch@...radead.org, ink@...assic.park.msu.ru, 
	jannh@...gle.com, jcmvbkbc@...il.com, jeffxu@...omium.org, 
	jhubbard@...dia.com, linux-alpha@...r.kernel.org, linux-api@...r.kernel.org, 
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, linux-mips@...r.kernel.org, 
	linux-mm@...ck.org, linux-parisc@...r.kernel.org, mattst88@...il.com, 
	muchun.song@...ux.dev, paulmck@...nel.org, richard.henderson@...aro.org, 
	shuah@...nel.org, sidhartha.kumar@...cle.com, surenb@...gle.com, 
	tsbogend@...ha.franken.de, willy@...radead.org, elver@...gle.com, 
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2 0/5] implement lightweight guard pages

On Wed, 23 Oct 2024 at 11:06, Vlastimil Babka <vbabka@...e.cz> wrote:
>
> On 10/23/24 10:56, Dmitry Vyukov wrote:
> >>
> >> Overall while I sympathise with this, it feels dangerous and a pretty major
> >> change, because there'll be something somewhere that will break because it
> >> expects faults to be swallowed that we no longer do swallow.
> >>
> >> So I'd say it'd be something we should defer, but of course it's a highly
> >> user-facing change so how easy that would be I don't know.
> >>
> >> But I definitely don't think a 'introduce the ability to do cheap PROT_NONE
> >> guards' series is the place to also fundmentally change how user access
> >> page faults are handled within the kernel :)
> >
> > Will delivering signals on kernel access be a backwards compatible
> > change? Or will we need a different API? MADV_GUARD_POISON_KERNEL?
> > It's just somewhat painful to detect/update all userspace if we add
> > this feature in future. Can we say signal delivery on kernel accesses
> > is unspecified?
>
> Would adding signal delivery to guard PTEs only help enough the ASAN etc
> usecase? Wouldn't it be instead possible to add some prctl to opt-in the
> whole ASANized process to deliver all existing segfaults as signals instead
> of -EFAULT ?

ASAN per se does not need this (it does not use page protection).
However, if you mean bug detection tools in general, then, yes, that's
what I had in mind.
There are also things like stack guard pages in libc that would
benefit from that as well.

But I observed that some libraries intentionally use EFAULT to probe
for memory readability, i.e. use some cheap syscall to probe memory
before reading it. So changing behavior globally may not work.