linux-kernel - Re: [PATCH v3 00/12] Enable Linear Address Space Separation support

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: <d6b79dd5d85a30baf2eb138036910890fb060e52.camel@intel.com>
Date:   Mon, 31 Jul 2023 22:36:56 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "Lutomirski, Andy" <luto@...nel.org>,
        "alexander.shishkin@...ux.intel.com" 
        <alexander.shishkin@...ux.intel.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Luck, Tony" <tony.luck@...el.com>,
        "Mehta, Sohil" <sohil.mehta@...el.com>
Subject: Re: [PATCH v3 00/12] Enable Linear Address Space Separation support

On Fri, 2023-06-09 at 21:36 +0300, Alexander Shishkin wrote:

What do NULL pointer de-references look like with LASS enabled? They
will be a #GP instead of a #PF, right? Currently the kernel prints out
several types of helpful messages:
 - "BUG: kernel NULL pointer dereference, address: %lx"
 - "BUG: unable to handle page fault for address: %px
 - "unable to execute userspace code (SMEP?) (uid: %d)"
 - etc

These will go away I guess, and you will get a more opaque "general
protection fault" message?

Assuming that is all right, I don't know if it might be worth tweaking
that #GP message, so people aren't confused when debugging. Something
that explains to turn off LASS to get more debugging info.

> Kernel accesses usually only happen to the kernel address space.
> However, there
> are valid reasons for kernel to access memory in the user half. For
> these cases
> (such as text poking and EFI runtime accesses), the kernel can
> temporarily
> suspend the enforcement of LASS by toggling SMAP (Supervisor Mode
> Access
> Prevention) using the stac()/clac() instructions.

CET introduces this unusual instruction called WRUSS. It allows you to
make user memory accesses while executing in the kernel. Because of
this special property, the CET shadow stack patches don't toggle
stac/clac while executing this instruction. So I think LASS will need
it to behave more like a normal userspace access from the kernel.
Shadow stack is not upstream yet, so just something to keep in mind for
the future.

Also, what is this series based on? I wasn't able to apply it.