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_HELO_NONE,SPF_PASS autolearn=no 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 03D1DC3F2CD for ; Mon, 2 Mar 2020 19:02:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CF3562072A for ; Mon, 2 Mar 2020 19:02:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727461AbgCBTB6 (ORCPT ); Mon, 2 Mar 2020 14:01:58 -0500 Received: from mga06.intel.com ([134.134.136.31]:21654 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726451AbgCBTB6 (ORCPT ); Mon, 2 Mar 2020 14:01:58 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2020 11:01:57 -0800 X-IronPort-AV: E=Sophos;i="5.70,507,1574150400"; d="scan'208";a="273846472" Received: from kcaccard-mobl.amr.corp.intel.com (HELO kcaccard-mobl1.jf.intel.com) ([10.24.8.183]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2020 11:01:56 -0800 Message-ID: <41d7049cb704007b3cd30a3f48198eebb8a31783.camel@linux.intel.com> Subject: Re: [RFC PATCH 09/11] kallsyms: hide layout and expose seed From: Kristen Carlson Accardi To: Jann Horn Cc: Kees Cook , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , Arjan van de Ven , Rick Edgecombe , the arch/x86 maintainers , kernel list , Kernel Hardening Date: Mon, 02 Mar 2020 11:01:56 -0800 In-Reply-To: References: <20200205223950.1212394-1-kristen@linux.intel.com> <20200205223950.1212394-10-kristen@linux.intel.com> <202002060428.08B14F1@keescook> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2020-02-06 at 20:27 +0100, Jann Horn wrote: > On Thu, Feb 6, 2020 at 6:51 PM Kristen Carlson Accardi > wrote: > > On Thu, 2020-02-06 at 04:32 -0800, Kees Cook wrote: > > > In the past, making kallsyms entirely unreadable seemed to break > > > weird > > > stuff in userspace. How about having an alternative view that > > > just > > > contains a alphanumeric sort of the symbol names (and they will > > > continue > > > to have zeroed addresses for unprivileged users)? > > > > > > Or perhaps we wait to hear about this causing a problem, and deal > > > with > > > it then? :) > > > > > > > Yeah - I don't know what people want here. Clearly, we can't leave > > kallsyms the way it is. Removing it entirely is a pretty fast way > > to > > figure out how people use it though :). > > FYI, a pretty decent way to see how people are using an API is > codesearch.debian.net, which searches through the source code of all > the packages debian ships: > > https://codesearch.debian.net/search?q=%2Fproc%2Fkallsyms&literal=1 I looked through some of these packages as Jann suggested, and it seems like there are several that are using /proc/kallsyms to look for specific symbol names to determine whether some feature has been compiled into the kernel. This practice seems dubious to me, knowing that many kernel symbol names can be changed at any time, but regardless seems to be fairly common.