From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x225unF/jyn5RJ2M0dLmisGb8wea+M0LK0hXi/Lfey8Y+PvaBW+cjVPLiKHYNU61wRthrV4W1 ARC-Seal: i=1; a=rsa-sha256; t=1517688760; cv=none; d=google.com; s=arc-20160816; b=u6uET6xJCYKwVCeTmJ8JfZAe00/H4KfeF2/BTS0B+KupBJivtPuVcUtKYvhRyveJVa 1Ggy1yPHl+t1wk1EnO3uY5WMqlaso5lqex5bhicRjIYqdR1LorbCzIEHepLe2qzLHFpg e4mSV9AsUSGiUeG5DBigi6uAgBH7AQj2PJdXSeofqyQttGF95S1+xDUizYAXaN1Cbl2V KnnMN03ujStKNoBKKW2BuWxKeb39oGay6LVSXb/w1X6aAyWiQ3gklwLVNKahBwxXxdjW BJzvECMjTPJA4YPHfUeVE8TeEUfAkPVBb+Lm47VXhyWtkFkf2qQdZ/ld5oIE6b1AzVKZ wm0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature:delivered-to:list-id:list-subscribe :list-unsubscribe:list-help:list-post:precedence:mailing-list :arc-authentication-results; bh=9mb3tdu9ZGh0R7T5nHZshl5Tv3ni5T+voO1FmPyxoSU=; b=hjRGsUh09Jzg+6uklwUGybToW4rkuivvH4q4YEt4XHlT2ELW765y58pKgAfj51Dqly x4sXdlTHbsVRlxae4chalT3MAT95anR5cUngHyl6QVItYcpo6yfz+Q6vpK7HeemAfYre wlD+FHt/uxjj/F7EjuDj3OU1loz5vPbqed5eU4hEooZT7Kr6VTltGGKhgOuiKSZTrLdG OTghAjAGFZq93DS7tSlydkbs2z7aQnGIggayxSSjPyufuDu2pD4x3RbEcn1zQCMTVekt FwiFplQZ/1W0tJ0MlRImnyWtfSm/Or6CPjtUBLu21/xYxpHYRWO2GJ/WoGJXyf39xvIZ lk3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sempervictus-com.20150623.gappssmtp.com header.s=20150623 header.b=GhGsQuKV; spf=pass (google.com: domain of kernel-hardening-return-11568-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11568-gregkh=linuxfoundation.org@lists.openwall.com Authentication-Results: mx.google.com; dkim=pass header.i=@sempervictus-com.20150623.gappssmtp.com header.s=20150623 header.b=GhGsQuKV; spf=pass (google.com: domain of kernel-hardening-return-11568-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11568-gregkh=linuxfoundation.org@lists.openwall.com Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: MIME-Version: 1.0 X-Originating-IP: [72.70.61.204] In-Reply-To: References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> From: Boris Lukashev Date: Sat, 3 Feb 2018 15:12:20 -0500 Message-ID: Subject: Re: [kernel-hardening] [PATCH 4/6] Protectable Memory To: Igor Stoppa Cc: Christopher Lameter , Matthew Wilcox , Jann Horn , Jerome Glisse , Kees Cook , Michal Hocko , Laura Abbott , Christoph Hellwig , linux-security-module , Linux-MM , kernel list , Kernel Hardening Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590497635371449856?= X-GMAIL-MSGID: =?utf-8?q?1591412009297729595?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Sat, Feb 3, 2018 at 2:57 PM, Igor Stoppa wrote: >>> On Thu, 25 Jan 2018, Matthew Wilcox wrote: > >>>> It's worth having a discussion about whether we want the pmalloc API >>>> or whether we want a slab-based API. > I'd love to have some feedback specifically about the API. > > I have also some idea about userspace and how to extend the pmalloc > concept to it: > > http://www.openwall.com/lists/kernel-hardening/2018/01/30/20 > > I'll be AFK intermittently for about 2 weeks, so i might not be able to > reply immediately, but from my perspective this would be just the > beginning of a broader hardening of both kernel and userspace that I'd > like to pursue. > > -- > igor Regarding the notion of validated protected memory, is there a method by which the resulting checksum could be used in a lookup table/function to resolve the location of the protected data? Effectively a hash table of protected allocations, with a benefit of dedup since any data matching the same key would be the same data (multiple identical cred structs being pushed around). Should leave the resolver address/csum in recent memory to check against, right? -- Boris Lukashev Systems Architect Semper Victus From mboxrd@z Thu Jan 1 00:00:00 1970 From: blukashev@sempervictus.com (Boris Lukashev) Date: Sat, 3 Feb 2018 15:12:20 -0500 Subject: [kernel-hardening] [PATCH 4/6] Protectable Memory In-Reply-To: References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Sat, Feb 3, 2018 at 2:57 PM, Igor Stoppa wrote: >>> On Thu, 25 Jan 2018, Matthew Wilcox wrote: > >>>> It's worth having a discussion about whether we want the pmalloc API >>>> or whether we want a slab-based API. > I'd love to have some feedback specifically about the API. > > I have also some idea about userspace and how to extend the pmalloc > concept to it: > > http://www.openwall.com/lists/kernel-hardening/2018/01/30/20 > > I'll be AFK intermittently for about 2 weeks, so i might not be able to > reply immediately, but from my perspective this would be just the > beginning of a broader hardening of both kernel and userspace that I'd > like to pursue. > > -- > igor Regarding the notion of validated protected memory, is there a method by which the resulting checksum could be used in a lookup table/function to resolve the location of the protected data? Effectively a hash table of protected allocations, with a benefit of dedup since any data matching the same key would be the same data (multiple identical cred structs being pushed around). Should leave the resolver address/csum in recent memory to check against, right? -- Boris Lukashev Systems Architect Semper Victus -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f69.google.com (mail-pg0-f69.google.com [74.125.83.69]) by kanga.kvack.org (Postfix) with ESMTP id 3F2DF6B0005 for ; Sat, 3 Feb 2018 15:12:22 -0500 (EST) Received: by mail-pg0-f69.google.com with SMTP id m10so5819433pgq.1 for ; Sat, 03 Feb 2018 12:12:22 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id m3-v6sor663216pld.18.2018.02.03.12.12.20 for (Google Transport Security); Sat, 03 Feb 2018 12:12:21 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> From: Boris Lukashev Date: Sat, 3 Feb 2018 15:12:20 -0500 Message-ID: Subject: Re: [kernel-hardening] [PATCH 4/6] Protectable Memory Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Igor Stoppa Cc: Christopher Lameter , Matthew Wilcox , Jann Horn , Jerome Glisse , Kees Cook , Michal Hocko , Laura Abbott , Christoph Hellwig , linux-security-module , Linux-MM , kernel list , Kernel Hardening On Sat, Feb 3, 2018 at 2:57 PM, Igor Stoppa wrote: >>> On Thu, 25 Jan 2018, Matthew Wilcox wrote: > >>>> It's worth having a discussion about whether we want the pmalloc API >>>> or whether we want a slab-based API. > I'd love to have some feedback specifically about the API. > > I have also some idea about userspace and how to extend the pmalloc > concept to it: > > http://www.openwall.com/lists/kernel-hardening/2018/01/30/20 > > I'll be AFK intermittently for about 2 weeks, so i might not be able to > reply immediately, but from my perspective this would be just the > beginning of a broader hardening of both kernel and userspace that I'd > like to pursue. > > -- > igor Regarding the notion of validated protected memory, is there a method by which the resulting checksum could be used in a lookup table/function to resolve the location of the protected data? Effectively a hash table of protected allocations, with a benefit of dedup since any data matching the same key would be the same data (multiple identical cred structs being pushed around). Should leave the resolver address/csum in recent memory to check against, right? -- Boris Lukashev Systems Architect Semper Victus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org