linux-kernel - Re: [RFC PATCH 00/13] x86 User Interrupts 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]

Date:   Thu, 23 Sep 2021 07:46:43 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Greg KH <gregkh@...uxfoundation.org>,
        "Mehta, Sohil" <sohil.mehta@...el.com>
Cc:     "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Luck, Tony" <tony.luck@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        "Lutomirski, Andy" <luto@...nel.org>, Jens Axboe <axboe@...nel.dk>,
        Christian Brauner <christian@...uner.io>,
        Peter Zijlstra <peterz@...radead.org>,
        Shuah Khan <shuah@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Jonathan Corbet <corbet@....net>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        "Kammela, Gayatri" <gayatri.kammela@...el.com>,
        "Zeng, Guang" <guang.zeng@...el.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "Witt, Randy E" <randy.e.witt@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "Thomas, Ramesh" <ramesh.thomas@...el.com>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>
Subject: Re: [RFC PATCH 00/13] x86 User Interrupts support

On 9/23/21 7:09 AM, Greg KH wrote:
> And you forgot to mention that this is tied to one specific CPU type
> only.  Are syscalls allowed to be created that would only work on
> obscure cpus like this one?

Well, you have to start somewhere.  For example, when memory protection
keys went in, we added three syscalls:

> 329     common  pkey_mprotect           sys_pkey_mprotect
> 330     common  pkey_alloc              sys_pkey_alloc
> 331     common  pkey_free               sys_pkey_free

At the point that I started posting these, you couldn't even buy a
system with this feature.  For a while, there was only one Intel Xeon
generation that had support.

But, if you build it, they will come.  Today, there is powerpc support
and our friends at AMD added support to their processors.  In addition,
protection keys are found across Intel's entire CPU line: from big
Xeons, down to the little Atoms you find in Chromebooks.

I encourage everyone submitting new hardware features to include
information about where their feature will show up to end users *and* to
say how widely it will be available.  I'd actually prefer if maintainers
rejected patches that didn't have this information.