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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 D6BBFC64EB8 for ; Thu, 4 Oct 2018 16:08:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 950C42082A for ; Thu, 4 Oct 2018 16:08:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 950C42082A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727663AbeJDXCC (ORCPT ); Thu, 4 Oct 2018 19:02:02 -0400 Received: from albireo.enyo.de ([5.158.152.32]:36710 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727407AbeJDXCC (ORCPT ); Thu, 4 Oct 2018 19:02:02 -0400 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1g86AF-0000Oz-7r; Thu, 04 Oct 2018 16:07:47 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.89) (envelope-from ) id 1g86AF-0004ms-0u; Thu, 04 Oct 2018 18:07:47 +0200 From: Florian Weimer To: Yu-cheng Yu Cc: Eugene Syromiatnikov , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , 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" , Vedvyas Shanbhogue , libc-alpha@sourceware.org, carlos@redhat.com Subject: Re: [RFC PATCH v4 6/9] x86/cet/ibt: Add arch_prctl functions for IBT 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> Date: Thu, 04 Oct 2018 18:07:47 +0200 In-Reply-To: <3350f7b42b32f3f7a1963a9c9c526210c24f7b05.camel@intel.com> (Yu-cheng Yu's message of "Thu, 04 Oct 2018 08:37:16 -0700") Message-ID: <87murtn19o.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * 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.