From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x224GiUGGSm6WN3Zw3Qs7OYgbmbP2F0ET3b8J8pR5jpXbvLtHKMJ1RlOMdwNdhEqGbA/EmI8x ARC-Seal: i=1; a=rsa-sha256; t=1518636541; cv=none; d=google.com; s=arc-20160816; b=ikGvkgmWE/wDCyr2Y4HHwziZIh3oc36rGjSHD4hDSeu62fNbJOWwLL/8026E3NAXSK Eaf0MYKJTDGkACbnPwENoTNk2B591OveTxN/B52u6cWWTnSULca8a0d99/yw6fnkDItD 9Z/39hxsZorxXe9dlc9KdeNbPPzuksBz5o8/Bd4SgUv9gxhDuNvuDYJ1xG3kekyJLfST MUOOkY8BiEBavwqk0sbXlsWhcvKJ2mWoT3yR0fUSFDwUMcx9JiUl2q7ohtR9rkD6BcyN 5CuqWcphEsEEw4LkKE8QXrlGZvJk1r8qNer7dcsedEhu2W40U8ZNrdVENhSCCArxKv/A H6TA== 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=yviJa8b4N0SnVcEpPxQOZa/KYEW/lmKN+ebD9zVJOeg=; b=W6C1KXml9QVOly59izy/e9xobelCgysssl8H3uOXNyUoTKU4h/+QFuBfmE931s7Rxq xGF/Nacnej9IIBrBgW82Ldc8hvbloTi5zB0v6/FOZFWeXMfnY2dqbn1arQkAMKCSaq0a B+WCuXIzr4RZyEhQCOcdGeRIJkVcUZzaeQMmXHS/cuI73NItmCHAlvfFVu/viiDGsvp0 9kNWkmnVAPB8hODkGwnCE9Bv82HzOZ8Nvy/EyBCfKMrFX/7DDyI7PEG1WPxlRRvyWQ+S Fbu62hM2x3dtH0ZwIG8BQ4Oz2mwGsFzFv51WoQRphjsTfAQBuJftAI9syvQZKJym/Jac p3fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LfraZkfB; spf=pass (google.com: domain of kernel-hardening-return-11761-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11761-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LfraZkfB; spf=pass (google.com: domain of kernel-hardening-return-11761-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11761-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.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 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: Ard Biesheuvel Date: Wed, 14 Feb 2018 19:28:42 +0000 Message-ID: Subject: Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory) To: Laura Abbott Cc: Kees Cook , 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?1592405829795248015?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 14 February 2018 at 19:06, Laura Abbott wrote: > On 02/13/2018 01:43 PM, Kees Cook wrote: >> >> On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: >>> >>> No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger >>> page sizes which can't be broken down at runtime. CONFIG_PAGE_POISONING >>> does use 4K pages which could be adjusted at runtime. So yes, you are >>> right we would have physmap exposure on arm64 as well. >> >> >> Errr, so that means even modules and kernel code are writable via the >> arm64 physmap? That seems extraordinarily bad. :( >> >> -Kees >> > > (adding linux-arm-kernel and changing the subject) > > Kernel code should be fine, if it isn't that is a bug that should be > fixed. We take care to ensure that the linear alias of the core kernel's .text and .rodata segments are mapped read-only. When we first moved the kernel out of the linear region, we did not map it there at all anymore, but that broke hibernation so we had to put something back. > 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. > As long as the linear alias of the module is mapped down to pages, we should be able to tweak the permissions. I take it that PAGE_POISONING does more than just that? From mboxrd@z Thu Jan 1 00:00:00 1970 From: ard.biesheuvel@linaro.org (Ard Biesheuvel) Date: Wed, 14 Feb 2018 19:28:42 +0000 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 14 February 2018 at 19:06, Laura Abbott wrote: > On 02/13/2018 01:43 PM, Kees Cook wrote: >> >> On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: >>> >>> No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger >>> page sizes which can't be broken down at runtime. CONFIG_PAGE_POISONING >>> does use 4K pages which could be adjusted at runtime. So yes, you are >>> right we would have physmap exposure on arm64 as well. >> >> >> Errr, so that means even modules and kernel code are writable via the >> arm64 physmap? That seems extraordinarily bad. :( >> >> -Kees >> > > (adding linux-arm-kernel and changing the subject) > > Kernel code should be fine, if it isn't that is a bug that should be > fixed. We take care to ensure that the linear alias of the core kernel's .text and .rodata segments are mapped read-only. When we first moved the kernel out of the linear region, we did not map it there at all anymore, but that broke hibernation so we had to put something back. > 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. > As long as the linear alias of the module is mapped down to pages, we should be able to tweak the permissions. I take it that PAGE_POISONING does more than just that? -- 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-io0-f198.google.com (mail-io0-f198.google.com [209.85.223.198]) by kanga.kvack.org (Postfix) with ESMTP id E0F426B0008 for ; Wed, 14 Feb 2018 14:28:44 -0500 (EST) Received: by mail-io0-f198.google.com with SMTP id z6so21024771iob.3 for ; Wed, 14 Feb 2018 11:28:44 -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 l12sor8183199ioe.202.2018.02.14.11.28.43 for (Google Transport Security); Wed, 14 Feb 2018 11:28:43 -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: Ard Biesheuvel Date: Wed, 14 Feb 2018 19:28:42 +0000 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: Kees Cook , 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 14 February 2018 at 19:06, Laura Abbott wrote: > On 02/13/2018 01:43 PM, Kees Cook wrote: >> >> On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: >>> >>> No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger >>> page sizes which can't be broken down at runtime. CONFIG_PAGE_POISONING >>> does use 4K pages which could be adjusted at runtime. So yes, you are >>> right we would have physmap exposure on arm64 as well. >> >> >> Errr, so that means even modules and kernel code are writable via the >> arm64 physmap? That seems extraordinarily bad. :( >> >> -Kees >> > > (adding linux-arm-kernel and changing the subject) > > Kernel code should be fine, if it isn't that is a bug that should be > fixed. We take care to ensure that the linear alias of the core kernel's .text and .rodata segments are mapped read-only. When we first moved the kernel out of the linear region, we did not map it there at all anymore, but that broke hibernation so we had to put something back. > 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. > As long as the linear alias of the module is mapped down to pages, we should be able to tweak the permissions. I take it that PAGE_POISONING does more than just that? -- 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: ard.biesheuvel@linaro.org (Ard Biesheuvel) Date: Wed, 14 Feb 2018 19:28:42 +0000 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 14 February 2018 at 19:06, Laura Abbott wrote: > On 02/13/2018 01:43 PM, Kees Cook wrote: >> >> On Tue, Feb 13, 2018 at 8:09 AM, Laura Abbott wrote: >>> >>> No, arm64 doesn't fixup the aliases, mostly because arm64 uses larger >>> page sizes which can't be broken down at runtime. CONFIG_PAGE_POISONING >>> does use 4K pages which could be adjusted at runtime. So yes, you are >>> right we would have physmap exposure on arm64 as well. >> >> >> Errr, so that means even modules and kernel code are writable via the >> arm64 physmap? That seems extraordinarily bad. :( >> >> -Kees >> > > (adding linux-arm-kernel and changing the subject) > > Kernel code should be fine, if it isn't that is a bug that should be > fixed. We take care to ensure that the linear alias of the core kernel's .text and .rodata segments are mapped read-only. When we first moved the kernel out of the linear region, we did not map it there at all anymore, but that broke hibernation so we had to put something back. > 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. > As long as the linear alias of the module is mapped down to pages, we should be able to tweak the permissions. I take it that PAGE_POISONING does more than just that?