From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x227NHVCX6dn6mZ1va59vNwmyof7J2Tg9Tvhiv2GUiyqGP2MvR0ECWT5AF2pb8VhFkpgrMhxG ARC-Seal: i=1; a=rsa-sha256; t=1518637737; cv=none; d=google.com; s=arc-20160816; b=U8Sv72ThuD5GRqPpEjoBcaKkLR0t7FBNT7pwb+jjrFYXjkCHmxl15e1cqse3CtB/bJ KBanK9JO1jPp/0ov6VmTgMSTtbV1OzlRxceSHN6wnVVrTe1HxZCPvBGIm/3nHE1bEijF ZyN4zhUP1ZyBsSF8Z3m1E+DlXHBqWGMtyJNxmaNxw+1S30kz10N78gNt7OpLrxXAFJkE x2Gu+7kRN8ygoDBkamYzLHA4NCki9ntULCR60NQJh5zfr4xHhmxybdM6MemcJQOfkArq a7aFJxT7ccbEzoflMlkTtIIhRwq6YyEJc6zn3/4HZGv7DyZtbpIwubbUTRCv2ccp2UZr sOjQ== 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:sender :mime-version:dkim-signature:dkim-signature:delivered-to:list-id :list-subscribe:list-unsubscribe:list-help:list-post:precedence :mailing-list:arc-authentication-results; bh=WVPE/J2jb7MxXY7ZEnqYHeTLCYLreEeoTWxuTxEiDNc=; b=yeymetqCijXl41ZTcyWzYO1vX78JqFfoJss7a7YRO0sNkjqCX9AGI0oPX2I1bWa3wo zNjIWfwaSU+VYYxk0op35PbacJK7VFcHLUVxu4TpxTh/MQvm4jyO/6KPZf2U7bwDbqoh 4ubt+SlU9CUOIY5WTGu4hJNB3f1n7QF8b3M/e8R/HkQeVZ3XCZwXSUKTUe/oFB49e4IN 7otCufOdNLqLONM27Y66ziagbYNcBBd+a2kUQWGLGqW6zKyTKmzjPy0kDZ3n+rfqCN+h vwNRhsf9oYwL63HHv3SUY0Xq2mx70BiPqzLCsfL3yBOBZf+MaoSa0Kxx3sBf6kF97ulp pdVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=q8Y29vRH; dkim=pass header.i=@chromium.org header.s=google header.b=fMTjZSIw; spf=pass (google.com: domain of kernel-hardening-return-11768-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11768-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=q8Y29vRH; dkim=pass header.i=@chromium.org header.s=google header.b=fMTjZSIw; spf=pass (google.com: domain of kernel-hardening-return-11768-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11768-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: <2f23544a-bd24-1e71-967b-e8d1cf5a20a3@redhat.com> References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> <8818bfd4-dd9f-f279-0432-69b59531bd41@huawei.com> <17e5b515-84c8-dca2-1695-cdf819834ea2@huawei.com> <414027d3-dd73-cf11-dc2a-e8c124591646@redhat.com> <2f23544a-bd24-1e71-967b-e8d1cf5a20a3@redhat.com> From: Kees Cook Date: Wed, 14 Feb 2018 11:48:38 -0800 X-Google-Sender-Auth: jzL9J1Z2Ks43deFnpru4D76niLY Message-ID: Subject: Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory) To: Laura Abbott Cc: Jann Horn , Igor Stoppa , Boris Lukashev , Christopher Lameter , Matthew Wilcox , Jerome Glisse , Michal Hocko , Christoph Hellwig , linux-security-module , Linux-MM , kernel list , Kernel Hardening , linux-arm-kernel Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1592404410626838547?= X-GMAIL-MSGID: =?utf-8?q?1592407083683969225?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > fixed. Modules yes are not fully protected. The conclusion from past > experience has been that we cannot safely break down larger page sizes > at runtime like x86 does. We could theoretically > add support for fixing up the alias if PAGE_POISONING is enabled but > I don't know who would actually use that in production. Performance > is very poor at that point. XPFO forces 4K pages on the physmap[1] for similar reasons. I have no doubt about performance changes, but I'd be curious to see real numbers. Did anyone do benchmarks on just the huge/4K change? (Without also the XPFO overhead?) If this, XPFO, and PAGE_POISONING all need it, I think we have to start a closer investigation. :) -Kees [1] http://www.openwall.com/lists/kernel-hardening/2017/09/07/13 -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 From: keescook@chromium.org (Kees Cook) Date: Wed, 14 Feb 2018 11:48:38 -0800 Subject: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory) In-Reply-To: <2f23544a-bd24-1e71-967b-e8d1cf5a20a3@redhat.com> References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> <8818bfd4-dd9f-f279-0432-69b59531bd41@huawei.com> <17e5b515-84c8-dca2-1695-cdf819834ea2@huawei.com> <414027d3-dd73-cf11-dc2a-e8c124591646@redhat.com> <2f23544a-bd24-1e71-967b-e8d1cf5a20a3@redhat.com> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > fixed. Modules yes are not fully protected. The conclusion from past > experience has been that we cannot safely break down larger page sizes > at runtime like x86 does. We could theoretically > add support for fixing up the alias if PAGE_POISONING is enabled but > I don't know who would actually use that in production. Performance > is very poor at that point. XPFO forces 4K pages on the physmap[1] for similar reasons. I have no doubt about performance changes, but I'd be curious to see real numbers. Did anyone do benchmarks on just the huge/4K change? (Without also the XPFO overhead?) If this, XPFO, and PAGE_POISONING all need it, I think we have to start a closer investigation. :) -Kees [1] http://www.openwall.com/lists/kernel-hardening/2017/09/07/13 -- Kees Cook Pixel Security -- 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-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) by kanga.kvack.org (Postfix) with ESMTP id EA6796B0005 for ; Wed, 14 Feb 2018 14:48:40 -0500 (EST) Received: by mail-ua0-f198.google.com with SMTP id g9so15121791ual.8 for ; Wed, 14 Feb 2018 11:48:40 -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 j189sor4966972vka.94.2018.02.14.11.48.40 for (Google Transport Security); Wed, 14 Feb 2018 11:48:40 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <2f23544a-bd24-1e71-967b-e8d1cf5a20a3@redhat.com> References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> <8818bfd4-dd9f-f279-0432-69b59531bd41@huawei.com> <17e5b515-84c8-dca2-1695-cdf819834ea2@huawei.com> <414027d3-dd73-cf11-dc2a-e8c124591646@redhat.com> <2f23544a-bd24-1e71-967b-e8d1cf5a20a3@redhat.com> From: Kees Cook Date: Wed, 14 Feb 2018 11:48:38 -0800 Message-ID: Subject: Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory) Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott Cc: Jann Horn , Igor Stoppa , Boris Lukashev , Christopher Lameter , Matthew Wilcox , Jerome Glisse , Michal Hocko , Christoph Hellwig , linux-security-module , Linux-MM , kernel list , Kernel Hardening , linux-arm-kernel On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > fixed. Modules yes are not fully protected. The conclusion from past > experience has been that we cannot safely break down larger page sizes > at runtime like x86 does. We could theoretically > add support for fixing up the alias if PAGE_POISONING is enabled but > I don't know who would actually use that in production. Performance > is very poor at that point. XPFO forces 4K pages on the physmap[1] for similar reasons. I have no doubt about performance changes, but I'd be curious to see real numbers. Did anyone do benchmarks on just the huge/4K change? (Without also the XPFO overhead?) If this, XPFO, and PAGE_POISONING all need it, I think we have to start a closer investigation. :) -Kees [1] http://www.openwall.com/lists/kernel-hardening/2017/09/07/13 -- Kees Cook Pixel Security -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: keescook@chromium.org (Kees Cook) Date: Wed, 14 Feb 2018 11:48:38 -0800 Subject: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory) In-Reply-To: <2f23544a-bd24-1e71-967b-e8d1cf5a20a3@redhat.com> References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> <8818bfd4-dd9f-f279-0432-69b59531bd41@huawei.com> <17e5b515-84c8-dca2-1695-cdf819834ea2@huawei.com> <414027d3-dd73-cf11-dc2a-e8c124591646@redhat.com> <2f23544a-bd24-1e71-967b-e8d1cf5a20a3@redhat.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott wrote: > fixed. Modules yes are not fully protected. The conclusion from past > experience has been that we cannot safely break down larger page sizes > at runtime like x86 does. We could theoretically > add support for fixing up the alias if PAGE_POISONING is enabled but > I don't know who would actually use that in production. Performance > is very poor at that point. XPFO forces 4K pages on the physmap[1] for similar reasons. I have no doubt about performance changes, but I'd be curious to see real numbers. Did anyone do benchmarks on just the huge/4K change? (Without also the XPFO overhead?) If this, XPFO, and PAGE_POISONING all need it, I think we have to start a closer investigation. :) -Kees [1] http://www.openwall.com/lists/kernel-hardening/2017/09/07/13 -- Kees Cook Pixel Security