linux-kernel - Re: [PATCH] Documentation/page_tables: Add info about MMU/TLB and Page Faults

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] [day] [month] [year] [list]

Message-ID: <2443562.jE0xQCEvom@suse>
Date:   Wed, 09 Aug 2023 15:27:53 +0200
From:   "Fabio M. De Francesco" <fmdefrancesco@...il.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Jonathan Corbet <corbet@....net>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Mike Rapoport <rppt@...nel.org>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ira Weiny <ira.weiny@...el.com>,
        Matthew Wilcox <willy@...radead.org>,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH] Documentation/page_tables: Add info about MMU/TLB and Page Faults

On lunedì 7 agosto 2023 11:40:30 CEST Linus Walleij wrote:
> Hi Fabio,
> 
> I'm back from vacation! Overall this documentation looks good and
> in line with the reset in this section.
> 
> On Fri, Jul 28, 2023 at 2:01 PM Fabio M. De Francesco
> 
> <fmdefrancesco@...il.com> wrote:
> > +One cause of page faults is due to bugs (or maliciously crafted 
addresses)
> > and +happens when a process tries to access a range of memory that it
> > doesn't have +permission to. This could be because the memory is reserved
> > for the kernel or +for another process, or because the process is trying 
to
> > write to a read-only +section of memory. When this happens, the kernel
> > sends a Segmentation Fault +(SIGSEGV) signal to the process, which usually
> > causes the process to terminate.
> This "segmentation fault" (SIGSEGV reads "signal segmentation violation)
> is actually a bit hard to understand for people not familiar
> with the 1970ies hardware. 

Linus,

Actually, I see a lot of "Segmentation fault (core dumped)" because I still 
develop in user space.

Stupid distractions are enough to get that message printed...

#include <stdio.h>
#include <malloc.h>

int main() {
        int *p1, *p2;
        p2 = malloc(sizeof(int));
        *p2 = 9;
        printf("*p2 is %d\n", *p1);
        return 0;
}

fabio@...e:/tmp> gcc -o test test.c 
fabio@...e:/tmp> ./test
Segmentation fault (core dumped)

Furthermore, everybody can still type "man signal.h" (document written in 
2017) and lookup the table of the POSIX signals and see that SIGSEGV is for 
"Invalid memory reference.". 
>
> [Snip]
>
> Other programs and the kernel memory are also in inaccessible segments,
> so accessing any of the own segments in the wrong way, or another programs
> segment, or an unmapped segment (virtual memory) would all result in the
> SIGSEGV opaque message "segmentation fault"
> 
> I don't know how to reflect this in a good way in the documentation
> though, maybe
> copy/paste/edit some of my text or I can try to write something as an
> additional patch if you prefer.

I suspect that people is much more used to get more "Segmentation fault" these 
days than in the 1970's (when developers probably were a little more careful 
with pointers - at least this is what I have heard about this subject :-)).

BTW, please feel free to change / extend this paragraph with a follow up 
patch.

Thanks for your comments,

Fabio
> Yours,
> Linus Walleij