From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [RFC PATCH v4 6/9] x86/cet/ibt: Add arch_prctl functions for IBT Date: Thu, 4 Oct 2018 09:12:04 -0700 Message-ID: References: <20180921150553.21016-1-yu-cheng.yu@intel.com> <20180921150553.21016-7-yu-cheng.yu@intel.com> <20181004132811.GJ32759@asgard.redhat.com> <3350f7b42b32f3f7a1963a9c9c526210c24f7b05.camel@intel.com> <87murtn19o.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <87murtn19o.fsf@mid.deneb.enyo.de> Sender: linux-kernel-owner@vger.kernel.org To: Florian Weimer Cc: Yu-cheng Yu , Eugene Syromiatnikov , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , Linux API , Arnd Bergmann , Balbir Singh , Cyrill Gorcunov , Dave Hansen , Florian Weimer , "H. J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav List-Id: linux-arch.vger.kernel.org On Thu, Oct 4, 2018 at 9:08 AM Florian Weimer wrote: > > * Yu-cheng Yu: > > > On Thu, 2018-10-04 at 15:28 +0200, Eugene Syromiatnikov wrote: > >> On Fri, Sep 21, 2018 at 08:05:50AM -0700, Yu-cheng Yu wrote: > >> > Update ARCH_CET_STATUS and ARCH_CET_DISABLE to include Indirect > >> > Branch Tracking features. > >> > > >> > Introduce: > >> > > >> > arch_prctl(ARCH_CET_LEGACY_BITMAP, unsigned long *addr) > >> > Enable the Indirect Branch Tracking legacy code bitmap. > >> > > >> > The parameter 'addr' is a pointer to a user buffer. > >> > On returning to the caller, the kernel fills the following: > >> > > >> > *addr = IBT bitmap base address > >> > *(addr + 1) = IBT bitmap size > >> > >> Again, some structure with a size field would be better from > >> UAPI/extensibility standpoint. > >> > >> One additional point: "size" in the structure from kernel should have > >> structure size expected by kernel, and at least providing there "0" from > >> user space shouldn't lead to failure (in fact, it is possible to provide > >> structure size back to userspace even if buffer is too small, along > >> with error). > > > > This has been in GLIBC v2.28. We cannot change it anymore. > > In theory, you could, if you change the ARCH_CET_LEGACY_BITMAP > constant, so that glibc will not use the different arch_prctl > operation. We could backport the change into the glibc 2.28 dynamic > linker, so that existing binaries will start using CET again. Then > only statically linked binaries will be impacted. > > It's definitely not ideal, but it's doable if the interface is > terminally broken or otherwise unacceptable. But to me it looks like > this threshold isn't reached here. I tend to agree. But I do think there's a real problem that should be fixed and won't affect ABI: the *name* of the prctl is pretty bad. I read the test several times trying to decide if you meant ARCH_GET_CET_LEGACY_BITMAP? But you don't. Maybe name it ARCH_CET_CREATE_LEGACY_BITMAP? And explicitly document what it does if legacy bitmap already exists? --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f65.google.com ([209.85.128.65]:39343 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727505AbeJDXGO (ORCPT ); Thu, 4 Oct 2018 19:06:14 -0400 Received: by mail-wm1-f65.google.com with SMTP id q8-v6so9597487wmq.4 for ; Thu, 04 Oct 2018 09:12:16 -0700 (PDT) MIME-Version: 1.0 References: <20180921150553.21016-1-yu-cheng.yu@intel.com> <20180921150553.21016-7-yu-cheng.yu@intel.com> <20181004132811.GJ32759@asgard.redhat.com> <3350f7b42b32f3f7a1963a9c9c526210c24f7b05.camel@intel.com> <87murtn19o.fsf@mid.deneb.enyo.de> In-Reply-To: <87murtn19o.fsf@mid.deneb.enyo.de> From: Andy Lutomirski Date: Thu, 4 Oct 2018 09:12:04 -0700 Message-ID: Subject: Re: [RFC PATCH v4 6/9] x86/cet/ibt: Add arch_prctl functions for IBT Content-Type: text/plain; charset="UTF-8" Sender: linux-arch-owner@vger.kernel.org List-ID: To: Florian Weimer Cc: Yu-cheng Yu , Eugene Syromiatnikov , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , Linux API , Arnd Bergmann , Balbir Singh , Cyrill Gorcunov , Dave Hansen , Florian Weimer , "H. J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , "Shanbhogue, Vedvyas" , libc-alpha , Carlos O'Donell Message-ID: <20181004161204.o52YTL2GXlf3F80cqKch4e72MwSUPEzNWUDFyrAmIvE@z> On Thu, Oct 4, 2018 at 9:08 AM Florian Weimer wrote: > > * Yu-cheng Yu: > > > On Thu, 2018-10-04 at 15:28 +0200, Eugene Syromiatnikov wrote: > >> On Fri, Sep 21, 2018 at 08:05:50AM -0700, Yu-cheng Yu wrote: > >> > Update ARCH_CET_STATUS and ARCH_CET_DISABLE to include Indirect > >> > Branch Tracking features. > >> > > >> > Introduce: > >> > > >> > arch_prctl(ARCH_CET_LEGACY_BITMAP, unsigned long *addr) > >> > Enable the Indirect Branch Tracking legacy code bitmap. > >> > > >> > The parameter 'addr' is a pointer to a user buffer. > >> > On returning to the caller, the kernel fills the following: > >> > > >> > *addr = IBT bitmap base address > >> > *(addr + 1) = IBT bitmap size > >> > >> Again, some structure with a size field would be better from > >> UAPI/extensibility standpoint. > >> > >> One additional point: "size" in the structure from kernel should have > >> structure size expected by kernel, and at least providing there "0" from > >> user space shouldn't lead to failure (in fact, it is possible to provide > >> structure size back to userspace even if buffer is too small, along > >> with error). > > > > This has been in GLIBC v2.28. We cannot change it anymore. > > In theory, you could, if you change the ARCH_CET_LEGACY_BITMAP > constant, so that glibc will not use the different arch_prctl > operation. We could backport the change into the glibc 2.28 dynamic > linker, so that existing binaries will start using CET again. Then > only statically linked binaries will be impacted. > > It's definitely not ideal, but it's doable if the interface is > terminally broken or otherwise unacceptable. But to me it looks like > this threshold isn't reached here. I tend to agree. But I do think there's a real problem that should be fixed and won't affect ABI: the *name* of the prctl is pretty bad. I read the test several times trying to decide if you meant ARCH_GET_CET_LEGACY_BITMAP? But you don't. Maybe name it ARCH_CET_CREATE_LEGACY_BITMAP? And explicitly document what it does if legacy bitmap already exists? --Andy