From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel Date: Tue, 21 May 2019 17:04:39 -0700 Message-ID: <201905211633.6C0BF0C2@keescook> References: <20190517144931.GA56186@arrakis.emea.arm.com> <20190521182932.sm4vxweuwo5ermyd@mbp> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20190521182932.sm4vxweuwo5ermyd@mbp> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Catalin Marinas Cc: Mark Rutland , kvm@vger.kernel.org, Szabolcs Nagy , Will Deacon , dri-devel@lists.freedesktop.org, Linux Memory Management List , Khalid Aziz , "open list:KERNEL SELFTEST FRAMEWORK" , Vincenzo Frascino , Jacob Bramley , Leon Romanovsky , linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org, Dmitry Vyukov , Dave Martin , Evgenii Stepanov , linux-media@vger.kernel.org, Kevin Brodsky , Ruben Ayrapetyan , Andrey Konovalov , Ramana Radhakrishnan , Alex Williamson , Yishai List-Id: amd-gfx.lists.freedesktop.org T24gVHVlLCBNYXkgMjEsIDIwMTkgYXQgMDc6Mjk6MzNQTSArMDEwMCwgQ2F0YWxpbiBNYXJpbmFz IHdyb3RlOgo+IE9uIE1vbiwgTWF5IDIwLCAyMDE5IGF0IDA0OjUzOjA3UE0gLTA3MDAsIEV2Z2Vu aWkgU3RlcGFub3Ygd3JvdGU6Cj4gPiBPbiBGcmksIE1heSAxNywgMjAxOSBhdCA3OjQ5IEFNIENh dGFsaW4gTWFyaW5hcyA8Y2F0YWxpbi5tYXJpbmFzQGFybS5jb20+IHdyb3RlOgo+ID4gPiBJTU8g KFJGQyBmb3Igbm93KSwgSSBzZWUgdHdvIHdheXMgZm9yd2FyZDoKPiA+ID4gWy4uLl0KPiA+ID4g Mi4gU2ltaWxhciBzaGltIHRvIHRoZSBhYm92ZSBsaWJjIHdyYXBwZXIgYnV0IGluc2lkZSB0aGUg a2VybmVsCj4gPiA+ICAgIChhcmNoL2FybTY0IG9ubHk7IG1vc3QgcG9pbnRlciBhcmd1bWVudHMg Y291bGQgYmUgY292ZXJlZCB3aXRoIGFuCj4gPiA+ICAgIF9fU0NfQ0FTVCBzaW1pbGFyIHRvIHRo ZSBzMzkwIG9uZSkuIFRoZXJlIGFyZSB0d28gZGlmZmVyZW5jZXMgZnJvbQo+ID4gPiAgICB3aGF0 IHdlJ3ZlIGRpc2N1c3NlZCBpbiB0aGUgcGFzdDoKPiA+ID4KPiA+ID4gICAgYSkgdGhpcyBpcyBh biBvcHQtaW4gYnkgdGhlIHVzZXIgd2hpY2ggd291bGQgaGF2ZSB0byBleHBsaWNpdGx5IGNhbGwK PiA+ID4gICAgICAgcHJjdGwoKS4gSWYgaXQgcmV0dXJucyAtRU5PVFNVUFAgZXRjLiwgdGhlIHVz ZXIgd29uJ3QgYmUgYWxsb3dlZAo+ID4gPiAgICAgICB0byBwYXNzIHRhZ2dlZCBwb2ludGVycyB0 byB0aGUga2VybmVsLiBUaGlzIHdvdWxkIHByb2JhYmx5IGJlIHRoZQo+ID4gPiAgICAgICByZXNw b25zaWJpbGl0eSBvZiB0aGUgQyBsaWIgdG8gbWFrZSBzdXJlIGl0IGRvZXNuJ3QgdGFnIGhlYXAK PiA+ID4gICAgICAgYWxsb2NhdGlvbnMuIElmIHRoZSB1c2VyIGRpZCBub3Qgb3B0LWluLCB0aGUg c3lzY2FsbHMgYXJlIHJvdXRlZAo+ID4gPiAgICAgICB0aHJvdWdoIHRoZSBub3JtYWwgcGF0aCAo bm8gdW50YWdnaW5nIGFkZHJlc3Mgc2hpbSkuCj4gPiA+Cj4gPiA+ICAgIGIpIGlvY3RsKCkgYW5k IG90aGVyIGJsYWNrbGlzdGVkIHN5c2NhbGxzIChwcmN0bCkgd2lsbCBub3QgYWNjZXB0Cj4gPiA+ ICAgICAgIHRhZ2dlZCBwb2ludGVycyAodG8gYmUgZG9jdW1lbnRlZCBpbiBWaWNlbnpvJ3MgQUJJ IHBhdGNoZXMpLgo+ID4KPiA+IFRoZSB3YXkgSSBzZWUgaXQsIGEgcGF0Y2ggdGhhdCBicmVha3Mg aGFuZGxpbmcgb2YgdGFnZ2VkIHBvaW50ZXJzIGlzCj4gPiBub3QgdGhhdCBkaWZmZXJlbnQgZnJv bSwgc2F5LCBhIHBhdGNoIHRoYXQgYWRkcyBhIHdpbGQgcG9pbnRlcgo+ID4gZGVyZWZlcmVuY2Uu IEJvdGggYXJlIGJ1Z3M7IHRoZSBkaWZmZXJlbmNlIGlzIHRoYXQgKGEpIHRoZSBmb3JtZXIKPiA+ IGJyZWFrcyBhIHJlbGF0aXZlbHkgdW5jb21tb24gdGFyZ2V0IGFuZCAoYikgaXQncyBhcmd1YWJs eSBhbiBlYXNpZXIKPiA+IG1pc3Rha2UgdG8gbWFrZS4gSWYgTVRFIGFkb3B0aW9uIGdvZXMgd2Vs bCwgKGEpIHdpbGwgbm90IGJlIHRoZSBjYXNlCj4gPiBmb3IgbG9uZy4KPiAKPiBJdCdzIGFsc28g dGhlIGZhY3Qgc3VjaCBwYXRjaCB3b3VsZCBnbyB1bm5vdGljZWQgZm9yIGEgbG9uZyB0aW1lIHVu dGlsCj4gc29tZW9uZSBleGVyY2lzZXMgdGhhdCBjb2RlIHBhdGguIEFuZCB3aGVuIHRoZXkgZG8s IHRoZSB1c2VyIHdvdWxkIGJlCj4gcHJldHR5IG11Y2ggaW4gdGhlIGRhcmsgdHJ5aW5nIHRvIGZp Z3VyZSB3aGF0IHdoYXQgd2VudCB3cm9uZywgd2h5IGEKPiBTSUdTRUdWIG9yIC1FRkFVTFQgaGFw cGVuZWQuIFdoYXQncyB3b3JzZSwgd2UgY2FuJ3QgZXZlbiBzYXkgd2UgZml4ZWQKPiBhbGwgdGhl IHBsYWNlcyB3aGVyZSBpdCBtYXR0ZXJzIGluIHRoZSBjdXJyZW50IGtlcm5lbCBjb2RlYmFzZSAo aWdub3JpbmcKPiBmdXR1cmUgcGF0Y2hlcykuCgpTbywgbG9va2luZyBmb3J3YXJkIGEgYml0LCB0 aGlzIGlzbid0IGdvaW5nIHRvIGJlIGFuIEFSTS1zcGVjaWZpYyBpc3N1ZQpmb3IgbG9uZy4gSW4g ZmFjdCwgSSB0aGluayB3ZSBzaG91bGRuJ3QgaGF2ZSBhcm0tc3BlY2lmaWMgc3lzY2FsbCB3cmFw cGVycwppbiB0aGlzIHNlcmllczogSSB0aGluayB1bnRhZ2dlZF9hZGRyKCkgc2hvdWxkIGxpa2Vs eSBiZSBhZGRlZCBhdCB0aGUKdG9wLWxldmVsIGFuZCBoYXZlIGl0IGJlIGEgbm8tb3AgZm9yIG90 aGVyIGFyY2hpdGVjdHVyZXMuIFNvIGdpdmVuIHRoaXMKYmVjb21pbmcgYSBrZXJuZWwtd2lkZSBt dWx0aS1hcmNoaXRlY3R1cmUgaXNzdWUgKHVuZGVyIHRoZSBhc3N1bXB0aW9uCnRoYXQgeDg2LCBS SVNDLVYsIGFuZCBvdGhlcnMgd2lsbCBnYWluIHNpbWlsYXIgVEJJIG9yIE1URSB0aGluZ3MpLAp3 ZSBzaG91bGQgc29sdmUgaXQgaW4gYSB3YXkgdGhhdCB3ZSBjYW4gcmUtdXNlLgoKV2UgbmVlZCBz b21ldGhpbmcgdGhhdCBpcyBnb2luZyB0byB3b3JrIGV2ZXJ5d2hlcmUuIEFuZCBpdCBuZWVkcyB0 byBiZQpzdXBwb3J0ZWQgYnkgdGhlIGtlcm5lbCBmb3IgdGhlIHNpbXBsZSByZWFzb24gdGhhdCB0 aGUga2VybmVsIG5lZWRzIHRvCmRvIE1URSBjaGVja3MgZHVyaW5nIGNvcHlfZnJvbV91c2VyKCk6 IGhhdmluZyB0aGF0IGluZm9ybWF0aW9uIHN0cmlwcGVkCm1lYW5zIHdlIGxvc2UgYW55IHVzZXJz cGFjZS1hc3NpZ25lZCBNVEUgcHJvdGVjdGlvbnMgaWYgdGhleSBnZXQgaGFuZGxlZApieSB0aGUg a2VybmVsLCB3aGljaCBpcyBhIHRvdGFsIG5vbi1zdGFydGVyLCBJTU8uCgpBcyBhbiBhc2lkZTog SSB0aGluayBTcGFyYyBBREkgc3VwcG9ydCBpbiBMaW51eCBhY3R1YWxseSBzaWRlLXN0ZXBwZWQK dGhpc1sxXSAoaS5lLiBjaG9zZSAic29sdXRpb24gMSIpOiAiQWxsIGFkZHJlc3NlcyBwYXNzZWQg dG8ga2VybmVsIG11c3QKYmUgbm9uLUFESSB0YWdnZWQgYWRkcmVzc2VzLiIgKEFuZCBzYWRseSwg Iktlcm5lbCBkb2VzIG5vdCBlbmFibGUgQURJCmZvciBrZXJuZWwgY29kZS4iKSBJIHRoaW5rIHRo aXMgd2FzIGEgbWlzdGFrZSB3ZSBzaG91bGQgbm90IHJlcGVhdCBmb3IKYXJtNjQgKHdlIGRvIHNl ZW0gdG8gYmUgYXQgbGVhc3QgaW4gYWdyZWVtZW50IGFib3V0IHRoaXMsIEkgdGhpbmspLgoKWzFd IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3BhdGNod29yay9wYXRjaC82NTQ0ODEvCgo+ID4gVGhp cyBpcyBhIGJpdCBvZiBhIGNoaWNrZW4tYW5kLWVnZyBwcm9ibGVtLiBJbiBhIHdvcmxkIHdoZXJl IG1lbW9yeQo+ID4gYWxsb2NhdG9ycyBvbiBvbmUgb3Igc2V2ZXJhbCBwb3B1bGFyIHBsYXRmb3Jt cyBnZW5lcmF0ZSBwb2ludGVycyB3aXRoCj4gPiBub24temVybyB0YWdzLCBhbnkgc3VjaCBicmVh a2FnZSB3aWxsIGJlIGNhdWdodCBpbiB0ZXN0aW5nLgo+ID4gVW5mb3J0dW5hdGVseSB0byByZWFj aCB0aGF0IHN0YXRlIHdlIG5lZWQgdGhlIGtlcm5lbCB0byBzdGFydAo+ID4gYWNjZXB0aW5nIHRh Z2dlZCBwb2ludGVycyBmaXJzdCwgYW5kIHRoZW4gaG9sZCBvbiBmb3IgYSBjb3VwbGUgb2YKPiA+ IHllYXJzIHVudGlsIHVzZXJzcGFjZSBjYXRjaGVzIHVwLgo+IAo+IFdvdWxkIHRoZSBrZXJuZWwg YWxzbyBjYXRjaCB1cCB3aXRoIHByb3ZpZGluZyBhIHN0YWJsZSBBQkk/IEJlY2F1c2Ugd2UKPiBo YXZlIHR3byBtb3ZpbmcgdGFyZ2V0cy4KPiAKPiBPbiBvbmUgaGFuZCwgeW91IGhhdmUgQW5kcm9p ZCBvciBzb21lIExpbnV4IGRpc3RybyB0aGF0IHN0aWNrIHRvIGEKPiBzdGFibGUga2VybmVsIHZl cnNpb24gZm9yIHNvbWUgdGltZSwgc28gdGhleSBoYXZlIGJldHRlciBjaGFuY2Ugb2YKPiBjbGVh cmluZyBtb3N0IG9mIHRoZSBwcm9ibGVtcy4gT24gdGhlIG90aGVyIGhhbmQsIHdlIGhhdmUgbWFp bmxpbmUKPiBrZXJuZWwgdGhhdCBnZXRzIG92ZXIgNTAwSyBsaW5lcyBldmVyeSByZWxlYXNlLiBB cyBtYWludGFpbmVyLCBJIGNhbid0Cj4gcmVseSBvbiBteSB0ZXN0aW5nIGFsb25lIGFzIHRoaXMg aXMgb24gYSBsaW1pdGVkIG51bWJlciBvZiBwbGF0Zm9ybXMuIFNvCj4gbXkgY29uY2VybiBpcyB0 aGF0IGV2ZXJ5IGtlcm5lbCByZWxlYXNlIGhhcyBhIHNpZ25pZmljYW50IGNoYW5jZSBvZgo+IGJy ZWFraW5nIHRoZSBBQkksIHVubGVzcyB3ZSBoYXZlIGEgYmV0dGVyIHdheSBvZiBpZGVudGlmeWlu ZyBwb3RlbnRpYWwKPiBpc3N1ZXMuCgpJIGp1c3Qgd2FudCB0byBtYWtlIHN1cmUgSSBmdWxseSB1 bmRlcnN0YW5kIHlvdXIgY29uY2VybiBhYm91dCB0aGlzCmJlaW5nIGFuIEFCSSBicmVhaywgYW5k IEkgd29yayBiZXN0IHdpdGggZXhhbXBsZXMuIFRoZSBjbG9zZXN0IHNpdHVhdGlvbgpJIGNhbiBz ZWUgd291bGQgYmU6CgotIHNvbWUgcHJvZ3JhbSBoYXMgbm8gaWRlYSBhYm91dCBNVEUKLSBtYWxs b2MoKSBzdGFydHMgcmV0dXJuaW5nIE1URS10YWdnZWQgYWRkcmVzc2VzCi0gcHJvZ3JhbSBkb2Vz bid0IGJyZWFrIGZyb20gdGhhdCBjaGFuZ2UKLSBwcm9ncmFtIHVzZXMgc29tZSBzeXNjYWxsIHRo YXQgaXMgbWlzc2luZyB1bnRhZ2dlZF9hZGRyKCkgYW5kIGZhaWxzCi0ga2VybmVsIGhhcyBub3cg YnJva2VuIHVzZXJzcGFjZSB0aGF0IHVzZWQgdG8gd29yawoKVGhlIHRyb3VibGUgSSBzZWUgd2l0 aCB0aGlzIGlzIHRoYXQgaXQgaXMgbGFyZ2VseSB0aGVvcmV0aWNhbCBhbmQKcmVxdWlyZXMgcGFy dCBvZiB1c2Vyc3BhY2UgdG8gY29sbHVkZSB0byBzdGFydCB1c2luZyBhIG5ldyBDUFUgZmVhdHVy ZQp0aGF0IHRpY2tsZXMgYSBidWcgaW4gdGhlIGtlcm5lbC4gQXMgSSB1bmRlcnN0YW5kIHRoZSBn b2xkZW4gcnVsZSwKdGhpcyBpcyBhIGJ1ZyBpbiB0aGUga2VybmVsIChhIG1pc3NlZCBpb2N0bCgp IG9yIHN1Y2gpIHRvIGJlIGZpeGVkLApub3QgYSBnbG9iYWwgYnJlYWtpbmcgb2Ygc29tZSB1c2Vy c3BhY2UgYmVoYXZpb3IuCgpJIGZlZWwgbGlrZSBJJ20gbWlzc2luZyBzb21ldGhpbmcgYWJvdXQg dGhpcyBiZWluZyBzZWVuIGFzIGFuIEFCSQpicmVhay4gVGhlIGtlcm5lbCBhbHJlYWR5IGZhaWxz IG9uIHVzZXJzcGFjZSBhZGRyZXNzZXMgdGhhdCBoYXZlIGhpZ2gKYml0cyBzZXQgLS0gYXJlIHRo ZXJlIHRoaW5ncyB0aGF0IF9kZXBlbmRfIG9uIHRoaXMgZmFpbHVyZSB0byBvcGVyYXRlPwoKLS0g CktlZXMgQ29vawpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcK aHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWw= From mboxrd@z Thu Jan 1 00:00:00 1970 From: keescook at chromium.org (Kees Cook) Date: Tue, 21 May 2019 17:04:39 -0700 Subject: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel In-Reply-To: <20190521182932.sm4vxweuwo5ermyd@mbp> References: <20190517144931.GA56186@arrakis.emea.arm.com> <20190521182932.sm4vxweuwo5ermyd@mbp> Message-ID: <201905211633.6C0BF0C2@keescook> On Tue, May 21, 2019 at 07:29:33PM +0100, Catalin Marinas wrote: > On Mon, May 20, 2019 at 04:53:07PM -0700, Evgenii Stepanov wrote: > > On Fri, May 17, 2019 at 7:49 AM Catalin Marinas wrote: > > > IMO (RFC for now), I see two ways forward: > > > [...] > > > 2. Similar shim to the above libc wrapper but inside the kernel > > > (arch/arm64 only; most pointer arguments could be covered with an > > > __SC_CAST similar to the s390 one). There are two differences from > > > what we've discussed in the past: > > > > > > a) this is an opt-in by the user which would have to explicitly call > > > prctl(). If it returns -ENOTSUPP etc., the user won't be allowed > > > to pass tagged pointers to the kernel. This would probably be the > > > responsibility of the C lib to make sure it doesn't tag heap > > > allocations. If the user did not opt-in, the syscalls are routed > > > through the normal path (no untagging address shim). > > > > > > b) ioctl() and other blacklisted syscalls (prctl) will not accept > > > tagged pointers (to be documented in Vicenzo's ABI patches). > > > > The way I see it, a patch that breaks handling of tagged pointers is > > not that different from, say, a patch that adds a wild pointer > > dereference. Both are bugs; the difference is that (a) the former > > breaks a relatively uncommon target and (b) it's arguably an easier > > mistake to make. If MTE adoption goes well, (a) will not be the case > > for long. > > It's also the fact such patch would go unnoticed for a long time until > someone exercises that code path. And when they do, the user would be > pretty much in the dark trying to figure what what went wrong, why a > SIGSEGV or -EFAULT happened. What's worse, we can't even say we fixed > all the places where it matters in the current kernel codebase (ignoring > future patches). So, looking forward a bit, this isn't going to be an ARM-specific issue for long. In fact, I think we shouldn't have arm-specific syscall wrappers in this series: I think untagged_addr() should likely be added at the top-level and have it be a no-op for other architectures. So given this becoming a kernel-wide multi-architecture issue (under the assumption that x86, RISC-V, and others will gain similar TBI or MTE things), we should solve it in a way that we can re-use. We need something that is going to work everywhere. And it needs to be supported by the kernel for the simple reason that the kernel needs to do MTE checks during copy_from_user(): having that information stripped means we lose any userspace-assigned MTE protections if they get handled by the kernel, which is a total non-starter, IMO. As an aside: I think Sparc ADI support in Linux actually side-stepped this[1] (i.e. chose "solution 1"): "All addresses passed to kernel must be non-ADI tagged addresses." (And sadly, "Kernel does not enable ADI for kernel code.") I think this was a mistake we should not repeat for arm64 (we do seem to be at least in agreement about this, I think). [1] https://lore.kernel.org/patchwork/patch/654481/ > > This is a bit of a chicken-and-egg problem. In a world where memory > > allocators on one or several popular platforms generate pointers with > > non-zero tags, any such breakage will be caught in testing. > > Unfortunately to reach that state we need the kernel to start > > accepting tagged pointers first, and then hold on for a couple of > > years until userspace catches up. > > Would the kernel also catch up with providing a stable ABI? Because we > have two moving targets. > > On one hand, you have Android or some Linux distro that stick to a > stable kernel version for some time, so they have better chance of > clearing most of the problems. On the other hand, we have mainline > kernel that gets over 500K lines every release. As maintainer, I can't > rely on my testing alone as this is on a limited number of platforms. So > my concern is that every kernel release has a significant chance of > breaking the ABI, unless we have a better way of identifying potential > issues. I just want to make sure I fully understand your concern about this being an ABI break, and I work best with examples. The closest situation I can see would be: - some program has no idea about MTE - malloc() starts returning MTE-tagged addresses - program doesn't break from that change - program uses some syscall that is missing untagged_addr() and fails - kernel has now broken userspace that used to work The trouble I see with this is that it is largely theoretical and requires part of userspace to collude to start using a new CPU feature that tickles a bug in the kernel. As I understand the golden rule, this is a bug in the kernel (a missed ioctl() or such) to be fixed, not a global breaking of some userspace behavior. I feel like I'm missing something about this being seen as an ABI break. The kernel already fails on userspace addresses that have high bits set -- are there things that _depend_ on this failure to operate? -- Kees Cook From mboxrd@z Thu Jan 1 00:00:00 1970 From: keescook@chromium.org (Kees Cook) Date: Tue, 21 May 2019 17:04:39 -0700 Subject: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel In-Reply-To: <20190521182932.sm4vxweuwo5ermyd@mbp> References: <20190517144931.GA56186@arrakis.emea.arm.com> <20190521182932.sm4vxweuwo5ermyd@mbp> Message-ID: <201905211633.6C0BF0C2@keescook> Content-Type: text/plain; charset="UTF-8" Message-ID: <20190522000439.8cjttfxrkMM8ckY2vu4x0mc-MVzFHNh9ikbNqWHJ0BU@z> On Tue, May 21, 2019@07:29:33PM +0100, Catalin Marinas wrote: > On Mon, May 20, 2019@04:53:07PM -0700, Evgenii Stepanov wrote: > > On Fri, May 17, 2019@7:49 AM Catalin Marinas wrote: > > > IMO (RFC for now), I see two ways forward: > > > [...] > > > 2. Similar shim to the above libc wrapper but inside the kernel > > > (arch/arm64 only; most pointer arguments could be covered with an > > > __SC_CAST similar to the s390 one). There are two differences from > > > what we've discussed in the past: > > > > > > a) this is an opt-in by the user which would have to explicitly call > > > prctl(). If it returns -ENOTSUPP etc., the user won't be allowed > > > to pass tagged pointers to the kernel. This would probably be the > > > responsibility of the C lib to make sure it doesn't tag heap > > > allocations. If the user did not opt-in, the syscalls are routed > > > through the normal path (no untagging address shim). > > > > > > b) ioctl() and other blacklisted syscalls (prctl) will not accept > > > tagged pointers (to be documented in Vicenzo's ABI patches). > > > > The way I see it, a patch that breaks handling of tagged pointers is > > not that different from, say, a patch that adds a wild pointer > > dereference. Both are bugs; the difference is that (a) the former > > breaks a relatively uncommon target and (b) it's arguably an easier > > mistake to make. If MTE adoption goes well, (a) will not be the case > > for long. > > It's also the fact such patch would go unnoticed for a long time until > someone exercises that code path. And when they do, the user would be > pretty much in the dark trying to figure what what went wrong, why a > SIGSEGV or -EFAULT happened. What's worse, we can't even say we fixed > all the places where it matters in the current kernel codebase (ignoring > future patches). So, looking forward a bit, this isn't going to be an ARM-specific issue for long. In fact, I think we shouldn't have arm-specific syscall wrappers in this series: I think untagged_addr() should likely be added at the top-level and have it be a no-op for other architectures. So given this becoming a kernel-wide multi-architecture issue (under the assumption that x86, RISC-V, and others will gain similar TBI or MTE things), we should solve it in a way that we can re-use. We need something that is going to work everywhere. And it needs to be supported by the kernel for the simple reason that the kernel needs to do MTE checks during copy_from_user(): having that information stripped means we lose any userspace-assigned MTE protections if they get handled by the kernel, which is a total non-starter, IMO. As an aside: I think Sparc ADI support in Linux actually side-stepped this[1] (i.e. chose "solution 1"): "All addresses passed to kernel must be non-ADI tagged addresses." (And sadly, "Kernel does not enable ADI for kernel code.") I think this was a mistake we should not repeat for arm64 (we do seem to be at least in agreement about this, I think). [1] https://lore.kernel.org/patchwork/patch/654481/ > > This is a bit of a chicken-and-egg problem. In a world where memory > > allocators on one or several popular platforms generate pointers with > > non-zero tags, any such breakage will be caught in testing. > > Unfortunately to reach that state we need the kernel to start > > accepting tagged pointers first, and then hold on for a couple of > > years until userspace catches up. > > Would the kernel also catch up with providing a stable ABI? Because we > have two moving targets. > > On one hand, you have Android or some Linux distro that stick to a > stable kernel version for some time, so they have better chance of > clearing most of the problems. On the other hand, we have mainline > kernel that gets over 500K lines every release. As maintainer, I can't > rely on my testing alone as this is on a limited number of platforms. So > my concern is that every kernel release has a significant chance of > breaking the ABI, unless we have a better way of identifying potential > issues. I just want to make sure I fully understand your concern about this being an ABI break, and I work best with examples. The closest situation I can see would be: - some program has no idea about MTE - malloc() starts returning MTE-tagged addresses - program doesn't break from that change - program uses some syscall that is missing untagged_addr() and fails - kernel has now broken userspace that used to work The trouble I see with this is that it is largely theoretical and requires part of userspace to collude to start using a new CPU feature that tickles a bug in the kernel. As I understand the golden rule, this is a bug in the kernel (a missed ioctl() or such) to be fixed, not a global breaking of some userspace behavior. I feel like I'm missing something about this being seen as an ABI break. The kernel already fails on userspace addresses that have high bits set -- are there things that _depend_ on this failure to operate? -- Kees Cook From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43A27C16A69 for ; Wed, 22 May 2019 00:04:50 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 18842217D9 for ; Wed, 22 May 2019 00:04:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="l9+n3BZw"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Zf9QLE33" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 18842217D9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=U4hJZVcIG1VecJX8znFi51gyknBa1yTjthlwB440Idg=; b=l9+n3BZwPMD440 ahefbpygfcSRge5C+/Hg8PvLmniBcS9HeUiqAldYdnNgDHVbZbGEVvwLpTSAIwZ4hVP+S8HOMIEhN csMeAgpaC/Yz8MKx8TO1V+1pOHe7wKgWxF+rfuP08MxKS33xvslzgnrCEjPfwngh+uYPYDOwPSXz6 WYnuwLoLue+9Q5IF6rdfmo15OQySZ7x9jNcBquQQbMyw4DSnjtGKK6Y5Mne2/VZ92IHNwNj1792yk 846ibUcPbGKG8uL06OtzupW2szNYqATfP5IgVYD97ozMoyDgtUj8jIy1vFKKIfacJneOmPgqNg/MP 4vgWux/05VvZ6Ok1OuFA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hTEkR-00078s-1N; Wed, 22 May 2019 00:04:47 +0000 Received: from mail-pf1-x443.google.com ([2607:f8b0:4864:20::443]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hTEkN-00078Z-GI for linux-arm-kernel@lists.infradead.org; Wed, 22 May 2019 00:04:45 +0000 Received: by mail-pf1-x443.google.com with SMTP id s11so277246pfm.12 for ; Tue, 21 May 2019 17:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=h+HMpjJbOByDkcgcmqTFcjwM/Zjfkc20s8NGwt76Mr8=; b=Zf9QLE33qmPluiR2OGF4dL2quucaUAVgN4YPizfJiTzAzfLxxGI5FlE9xizVc831A4 PZROfhtKhT/R7pMFQlHGrknlILzZeG3LHD5gyBNKzIo1iuXRcoC6OuM/wsNOYEBlL6Lp KGXm5hniO64celTxThJARG41BLIiM0pmyycsI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=h+HMpjJbOByDkcgcmqTFcjwM/Zjfkc20s8NGwt76Mr8=; b=mce9ln1GIvP8T8nSoZAZcLjdELB8sn41GMCj5pufEzIxGKmNrKPN8+umS9IOz/jX5A RfIjpiRx9g6vDyG/BXI8pKjTlAsA9ClYugTRoqZAdo5XApAPsEgPr9Ph7XP8KtwAflMC IzuNrE+Tkmw+L45w9tv0aW7/IOtCDKLMv+Kl/8To3kAf22RzhUBhNXRPk9eIbth0hCbi rLJZHn32wSl/66sgQZVCTXoyEKtyWbk53zrcwb1zTogNHcPk91lbmEmaFgdRXHY0yykT xo+NcynwwE8tMxIrfEg/P5wpnr0PygyAdyQ08mSCUIXK8W2uTOA59qDnzj+kkmdqhfOk n7og== X-Gm-Message-State: APjAAAXx7oafwZTWyqdKRaq0Vt9iDEYe9rxOpK26cDfCL5NlRpATyWju cTYsyyYK/GAn8goSbGTjmH/9/g== X-Google-Smtp-Source: APXvYqyRHlp4k1ARvHRDx6pnXWJEks1ZEDsNIbDRibBeuJSxc6NZrbRUP3gWhA9hXypH8RUrMs25NQ== X-Received: by 2002:a63:8dc8:: with SMTP id z191mr87505404pgd.9.1558483482349; Tue, 21 May 2019 17:04:42 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id a11sm15675685pff.128.2019.05.21.17.04.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 21 May 2019 17:04:40 -0700 (PDT) Date: Tue, 21 May 2019 17:04:39 -0700 From: Kees Cook To: Catalin Marinas Subject: Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel Message-ID: <201905211633.6C0BF0C2@keescook> References: <20190517144931.GA56186@arrakis.emea.arm.com> <20190521182932.sm4vxweuwo5ermyd@mbp> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190521182932.sm4vxweuwo5ermyd@mbp> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190521_170443_572024_183D5747 X-CRM114-Status: GOOD ( 33.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , kvm@vger.kernel.org, Szabolcs Nagy , Will Deacon , dri-devel@lists.freedesktop.org, Linux Memory Management List , Khalid Aziz , "open list:KERNEL SELFTEST FRAMEWORK" , Vincenzo Frascino , Jacob Bramley , Leon Romanovsky , linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org, Dmitry Vyukov , Dave Martin , Evgenii Stepanov , linux-media@vger.kernel.org, Kevin Brodsky , Ruben Ayrapetyan , Andrey Konovalov , Ramana Radhakrishnan , Alex Williamson , Yishai Hadas , Mauro Carvalho Chehab , Linux ARM , Kostya Serebryany , Greg Kroah-Hartman , Felix Kuehling , LKML , Jens Wiklander , Lee Smith , Alexander Deucher , Andrew Morton , Elliott Hughes , Robin Murphy , Christian Koenig , Luc Van Oostenryck Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, May 21, 2019 at 07:29:33PM +0100, Catalin Marinas wrote: > On Mon, May 20, 2019 at 04:53:07PM -0700, Evgenii Stepanov wrote: > > On Fri, May 17, 2019 at 7:49 AM Catalin Marinas wrote: > > > IMO (RFC for now), I see two ways forward: > > > [...] > > > 2. Similar shim to the above libc wrapper but inside the kernel > > > (arch/arm64 only; most pointer arguments could be covered with an > > > __SC_CAST similar to the s390 one). There are two differences from > > > what we've discussed in the past: > > > > > > a) this is an opt-in by the user which would have to explicitly call > > > prctl(). If it returns -ENOTSUPP etc., the user won't be allowed > > > to pass tagged pointers to the kernel. This would probably be the > > > responsibility of the C lib to make sure it doesn't tag heap > > > allocations. If the user did not opt-in, the syscalls are routed > > > through the normal path (no untagging address shim). > > > > > > b) ioctl() and other blacklisted syscalls (prctl) will not accept > > > tagged pointers (to be documented in Vicenzo's ABI patches). > > > > The way I see it, a patch that breaks handling of tagged pointers is > > not that different from, say, a patch that adds a wild pointer > > dereference. Both are bugs; the difference is that (a) the former > > breaks a relatively uncommon target and (b) it's arguably an easier > > mistake to make. If MTE adoption goes well, (a) will not be the case > > for long. > > It's also the fact such patch would go unnoticed for a long time until > someone exercises that code path. And when they do, the user would be > pretty much in the dark trying to figure what what went wrong, why a > SIGSEGV or -EFAULT happened. What's worse, we can't even say we fixed > all the places where it matters in the current kernel codebase (ignoring > future patches). So, looking forward a bit, this isn't going to be an ARM-specific issue for long. In fact, I think we shouldn't have arm-specific syscall wrappers in this series: I think untagged_addr() should likely be added at the top-level and have it be a no-op for other architectures. So given this becoming a kernel-wide multi-architecture issue (under the assumption that x86, RISC-V, and others will gain similar TBI or MTE things), we should solve it in a way that we can re-use. We need something that is going to work everywhere. And it needs to be supported by the kernel for the simple reason that the kernel needs to do MTE checks during copy_from_user(): having that information stripped means we lose any userspace-assigned MTE protections if they get handled by the kernel, which is a total non-starter, IMO. As an aside: I think Sparc ADI support in Linux actually side-stepped this[1] (i.e. chose "solution 1"): "All addresses passed to kernel must be non-ADI tagged addresses." (And sadly, "Kernel does not enable ADI for kernel code.") I think this was a mistake we should not repeat for arm64 (we do seem to be at least in agreement about this, I think). [1] https://lore.kernel.org/patchwork/patch/654481/ > > This is a bit of a chicken-and-egg problem. In a world where memory > > allocators on one or several popular platforms generate pointers with > > non-zero tags, any such breakage will be caught in testing. > > Unfortunately to reach that state we need the kernel to start > > accepting tagged pointers first, and then hold on for a couple of > > years until userspace catches up. > > Would the kernel also catch up with providing a stable ABI? Because we > have two moving targets. > > On one hand, you have Android or some Linux distro that stick to a > stable kernel version for some time, so they have better chance of > clearing most of the problems. On the other hand, we have mainline > kernel that gets over 500K lines every release. As maintainer, I can't > rely on my testing alone as this is on a limited number of platforms. So > my concern is that every kernel release has a significant chance of > breaking the ABI, unless we have a better way of identifying potential > issues. I just want to make sure I fully understand your concern about this being an ABI break, and I work best with examples. The closest situation I can see would be: - some program has no idea about MTE - malloc() starts returning MTE-tagged addresses - program doesn't break from that change - program uses some syscall that is missing untagged_addr() and fails - kernel has now broken userspace that used to work The trouble I see with this is that it is largely theoretical and requires part of userspace to collude to start using a new CPU feature that tickles a bug in the kernel. As I understand the golden rule, this is a bug in the kernel (a missed ioctl() or such) to be fixed, not a global breaking of some userspace behavior. I feel like I'm missing something about this being seen as an ABI break. The kernel already fails on userspace addresses that have high bits set -- are there things that _depend_ on this failure to operate? -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1117FC16A69 for ; Wed, 22 May 2019 00:04:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CD54A217D9 for ; Wed, 22 May 2019 00:04:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Zf9QLE33" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727733AbfEVAEn (ORCPT ); Tue, 21 May 2019 20:04:43 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:36738 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726434AbfEVAEn (ORCPT ); Tue, 21 May 2019 20:04:43 -0400 Received: by mail-pf1-f194.google.com with SMTP id v80so301006pfa.3 for ; Tue, 21 May 2019 17:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=h+HMpjJbOByDkcgcmqTFcjwM/Zjfkc20s8NGwt76Mr8=; b=Zf9QLE33qmPluiR2OGF4dL2quucaUAVgN4YPizfJiTzAzfLxxGI5FlE9xizVc831A4 PZROfhtKhT/R7pMFQlHGrknlILzZeG3LHD5gyBNKzIo1iuXRcoC6OuM/wsNOYEBlL6Lp KGXm5hniO64celTxThJARG41BLIiM0pmyycsI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=h+HMpjJbOByDkcgcmqTFcjwM/Zjfkc20s8NGwt76Mr8=; b=iXmbs+p5S8/PSoEHnfFVGXT6s0QzrPGUL5QjnknTSwHWXJIcRnQ6ar9nGTYneYmbj/ P/nN9s4tMSj5pJHcBIJCF/PsKDF1qAQbUy9enXJb6ZNuydnYqIS/c4YImRmc1QpESDNl QlMXR0hdTrUexC+rdW+4+HurOpR2AQM6GTEk3CwrkxZ69xIQTu8VLgZWvLGMsa8FH5ZJ uxJvbPW2vARpHVn/FdkWSywbBvAOgp44DWzXEy4R9ICBMinyGc7KlTorUHvnBYoIBUex Dqrig/KMlGKmgILdY8hCr6LDPSZsrZWtLvh3IiXvoChmhCcgRmHv7xxxxPz0rNGDf+O0 RQ3Q== X-Gm-Message-State: APjAAAXMrkWT2re9WMp/P4Q2rjOx1ROFnSmZc4N5ZM5Kg7ZNNT6Vn7V5 9f+leKpQveHex5m4Fzy4QjMfPg== X-Google-Smtp-Source: APXvYqyRHlp4k1ARvHRDx6pnXWJEks1ZEDsNIbDRibBeuJSxc6NZrbRUP3gWhA9hXypH8RUrMs25NQ== X-Received: by 2002:a63:8dc8:: with SMTP id z191mr87505404pgd.9.1558483482349; Tue, 21 May 2019 17:04:42 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id a11sm15675685pff.128.2019.05.21.17.04.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 21 May 2019 17:04:40 -0700 (PDT) Date: Tue, 21 May 2019 17:04:39 -0700 From: Kees Cook To: Catalin Marinas Cc: Evgenii Stepanov , Andrey Konovalov , Khalid Aziz , Linux ARM , Linux Memory Management List , LKML , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-rdma@vger.kernel.org, linux-media@vger.kernel.org, kvm@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , Vincenzo Frascino , Will Deacon , Mark Rutland , Andrew Morton , Greg Kroah-Hartman , Yishai Hadas , Felix Kuehling , Alexander Deucher , Christian Koenig , Mauro Carvalho Chehab , Jens Wiklander , Alex Williamson , Leon Romanovsky , Dmitry Vyukov , Kostya Serebryany , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Robin Murphy , Luc Van Oostenryck , Dave Martin , Kevin Brodsky , Szabolcs Nagy , Elliott Hughes Subject: Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel Message-ID: <201905211633.6C0BF0C2@keescook> References: <20190517144931.GA56186@arrakis.emea.arm.com> <20190521182932.sm4vxweuwo5ermyd@mbp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190521182932.sm4vxweuwo5ermyd@mbp> Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, May 21, 2019 at 07:29:33PM +0100, Catalin Marinas wrote: > On Mon, May 20, 2019 at 04:53:07PM -0700, Evgenii Stepanov wrote: > > On Fri, May 17, 2019 at 7:49 AM Catalin Marinas wrote: > > > IMO (RFC for now), I see two ways forward: > > > [...] > > > 2. Similar shim to the above libc wrapper but inside the kernel > > > (arch/arm64 only; most pointer arguments could be covered with an > > > __SC_CAST similar to the s390 one). There are two differences from > > > what we've discussed in the past: > > > > > > a) this is an opt-in by the user which would have to explicitly call > > > prctl(). If it returns -ENOTSUPP etc., the user won't be allowed > > > to pass tagged pointers to the kernel. This would probably be the > > > responsibility of the C lib to make sure it doesn't tag heap > > > allocations. If the user did not opt-in, the syscalls are routed > > > through the normal path (no untagging address shim). > > > > > > b) ioctl() and other blacklisted syscalls (prctl) will not accept > > > tagged pointers (to be documented in Vicenzo's ABI patches). > > > > The way I see it, a patch that breaks handling of tagged pointers is > > not that different from, say, a patch that adds a wild pointer > > dereference. Both are bugs; the difference is that (a) the former > > breaks a relatively uncommon target and (b) it's arguably an easier > > mistake to make. If MTE adoption goes well, (a) will not be the case > > for long. > > It's also the fact such patch would go unnoticed for a long time until > someone exercises that code path. And when they do, the user would be > pretty much in the dark trying to figure what what went wrong, why a > SIGSEGV or -EFAULT happened. What's worse, we can't even say we fixed > all the places where it matters in the current kernel codebase (ignoring > future patches). So, looking forward a bit, this isn't going to be an ARM-specific issue for long. In fact, I think we shouldn't have arm-specific syscall wrappers in this series: I think untagged_addr() should likely be added at the top-level and have it be a no-op for other architectures. So given this becoming a kernel-wide multi-architecture issue (under the assumption that x86, RISC-V, and others will gain similar TBI or MTE things), we should solve it in a way that we can re-use. We need something that is going to work everywhere. And it needs to be supported by the kernel for the simple reason that the kernel needs to do MTE checks during copy_from_user(): having that information stripped means we lose any userspace-assigned MTE protections if they get handled by the kernel, which is a total non-starter, IMO. As an aside: I think Sparc ADI support in Linux actually side-stepped this[1] (i.e. chose "solution 1"): "All addresses passed to kernel must be non-ADI tagged addresses." (And sadly, "Kernel does not enable ADI for kernel code.") I think this was a mistake we should not repeat for arm64 (we do seem to be at least in agreement about this, I think). [1] https://lore.kernel.org/patchwork/patch/654481/ > > This is a bit of a chicken-and-egg problem. In a world where memory > > allocators on one or several popular platforms generate pointers with > > non-zero tags, any such breakage will be caught in testing. > > Unfortunately to reach that state we need the kernel to start > > accepting tagged pointers first, and then hold on for a couple of > > years until userspace catches up. > > Would the kernel also catch up with providing a stable ABI? Because we > have two moving targets. > > On one hand, you have Android or some Linux distro that stick to a > stable kernel version for some time, so they have better chance of > clearing most of the problems. On the other hand, we have mainline > kernel that gets over 500K lines every release. As maintainer, I can't > rely on my testing alone as this is on a limited number of platforms. So > my concern is that every kernel release has a significant chance of > breaking the ABI, unless we have a better way of identifying potential > issues. I just want to make sure I fully understand your concern about this being an ABI break, and I work best with examples. The closest situation I can see would be: - some program has no idea about MTE - malloc() starts returning MTE-tagged addresses - program doesn't break from that change - program uses some syscall that is missing untagged_addr() and fails - kernel has now broken userspace that used to work The trouble I see with this is that it is largely theoretical and requires part of userspace to collude to start using a new CPU feature that tickles a bug in the kernel. As I understand the golden rule, this is a bug in the kernel (a missed ioctl() or such) to be fixed, not a global breaking of some userspace behavior. I feel like I'm missing something about this being seen as an ABI break. The kernel already fails on userspace addresses that have high bits set -- are there things that _depend_ on this failure to operate? -- Kees Cook