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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98F80ECAAA1 for ; Tue, 6 Sep 2022 00:38:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C995380239; Mon, 5 Sep 2022 20:38:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C48B480224; Mon, 5 Sep 2022 20:38:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B11CB80239; Mon, 5 Sep 2022 20:38:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A1AAD80224 for ; Mon, 5 Sep 2022 20:38:06 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7CC3F1C648F for ; Tue, 6 Sep 2022 00:38:06 +0000 (UTC) X-FDA: 79879798572.02.68EDDB3 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf26.hostedemail.com (Postfix) with ESMTP id 1F77F140083 for ; Tue, 6 Sep 2022 00:38:05 +0000 (UTC) Received: by mail-ej1-f49.google.com with SMTP id fc24so10863813ejc.3 for ; Mon, 05 Sep 2022 17:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=7un4HX2JCwCz50GAyQxv3uo3L7dunvyCkFMMoxC/GmE=; b=aP6iMqzgytKnLYUKeWOGgeQf7XrWU3yeeBV15MvVRL/qVSmBdE7EDnSFKZuJ0PPcQg VviWREQGiQx9scuQUS31+9p12E5NBCKfgBsBPn4vUyvDBf7cWiVyxVIu5JC9lnpnHmAb jX0Tke+GE0beO8MaJFc9omSrI33+5ZfAy9qF1L6g5BpsXWfO1wvNHdx24MdzpI8ZV9EC RTlTk+2AoUelBrKMKjAOOLKzUE0MLgkZc+XKmw43y/A6QpY7bdElZFMQ9hQ1Zxq260lh ptMNs5uA6SIKuB/PAdISDefPLlf/nfIOnmwR8S3iKzU1Ixtk8d8JvgJFJEei8ouGwPhu Qr0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=7un4HX2JCwCz50GAyQxv3uo3L7dunvyCkFMMoxC/GmE=; b=v2LcnFgFDrx6kbfMkR6AGGfeRp2YD270mCPiAkiaaRO/UZIdkYk/5ZMrIs9fN/DltX KR3dLiJkM1ExfVcRgh0MOG2SRNCl3nxSbgtuztAAnTnnAumZ1nk1ouvwJCDHO+gxUqK8 ciYkCRP1Z5JfCVKZIixUobpQfPCIrVemFX3Jr6ZaCAvnYqkCCjbzDHB2m32OSKt8oLDj 9OOg59okvL1awz+IvBjoGgdcAIS/89IOeDFd7N7V7v7qbKna3V+rACMi64Blj3ShvIdZ ig0GzRVu0cChRmvzawd5Tgbk4iR+4ubL+ARCJHry/WBd2j9oOrOfHpIl4Q81gAg6wVzA bB+A== X-Gm-Message-State: ACgBeo3KBEvqeBU8Fny9QNwOCMFKsaHUjpnmubXeqfY+FCiLD0i4aJOP M66UwqRPjHLWJ2YQh9ac2Xv2daHE84pYp3D2F8lSmA== X-Google-Smtp-Source: AA6agR5fOzdQufQ44wqDDK7YEEkgYae38ASeKpZbXXmTrNA6WkhrnwsIV1o34p4PJIU8pn/xD3voz0mXgvBqb/dQReE= X-Received: by 2002:a17:907:7252:b0:73f:c3e9:4197 with SMTP id ds18-20020a170907725200b0073fc3e94197mr34115682ejc.173.1662424684715; Mon, 05 Sep 2022 17:38:04 -0700 (PDT) MIME-Version: 1.0 References: <20220902232732.12358-1-rick.p.edgecombe@intel.com> <3d82deb6-357d-0b54-ffd1-dce157674aad@intel.com> In-Reply-To: <3d82deb6-357d-0b54-ffd1-dce157674aad@intel.com> From: Pasha Tatashin Date: Mon, 5 Sep 2022 20:37:27 -0400 Message-ID: Subject: Re: [PATCH] mm: Check writable zero page in page table check To: "Huang, Shaoqin" Cc: Rick Edgecombe , Andrew Morton , linux-mm , LKML Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662424686; a=rsa-sha256; cv=none; b=X5tLENxYDS7z3rsha4Gf0lGdgRNjPEry5+jMSIg6tkERVVED+MHcoBG3ZDY1NQkDA5WJsO sELGMIIUB7obqFkpaBgkAkzuNqZnrBzTeIsCM3oXHQKLbfaYAdRnSJcJEYvWg9xePHElAy FoOW6m1+hjKPU7WefiJbfWbWrmhp+1k= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=aP6iMqzg; spf=pass (imf26.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662424686; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7un4HX2JCwCz50GAyQxv3uo3L7dunvyCkFMMoxC/GmE=; b=R54EiAH0Wt52aMqrvSZtWAPKuAcbxcu0bB4wLjp+Uq3gtkNi13ew2jB+bDCO67yVQo/t4Q 1w7Pf/YmQxEmHREZHnGbvGZRcRGk+2nd5wx8uba0SFVBIkfXRyTTjqeTIrbMLh8zkEaxiu AsUbU4HZko8Wvv5KKS3QG1GE/yRc2Q0= Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=aP6iMqzg; spf=pass (imf26.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none X-Rspamd-Server: rspam01 X-Rspam-User: X-Stat-Signature: fepse6uowohem3r5m5zqa93gdgahjx91 X-Rspamd-Queue-Id: 1F77F140083 X-HE-Tag: 1662424685-240944 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Shaoqin, The idea behind page table check is to prevent some types of memory corruptions: i.e. prevent false page sharing, and memory leaking between address spaces. This is an optional security feature for setups where it is more dangerous to leak data than to crash the machine. Therefore, when page table check detects illegal page sharing it immediately crashes the kernel. I think we can have a page_table_check option that would change BUG_ON to WARN_ON() (or to WARN_ON_ONCE(), since once corruption is detected I believe it might show up many times again) Pasha On Fri, Sep 2, 2022 at 10:13 PM Huang, Shaoqin wrote: > > > > On 9/3/2022 7:27 AM, Rick Edgecombe wrote: > > The zero page should remain all zero, so that it can be mapped as > > read-only for read faults of memory that should be zeroed. If it is ever > > mapped writable to userspace, it could become non-zero and so other apps > > would unexpectedly get non-zero data. So the zero page should never be > > mapped writable to userspace. Check for this condition in > > page_table_check_set(). > > > > Signed-off-by: Rick Edgecombe > > > > --- > > > > Hi, > > > > CONFIG_PAGE_TABLE_CHECK is pretty explicit about what it checks (and > > doesn't mention the zero page), but this condition seems to fit with the > > general category of "pages mapped wrongly to userspace". I added it > > locally to help me debug something. Maybe it's more widely useful. > > > > mm/page_table_check.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/mm/page_table_check.c b/mm/page_table_check.c > > index e2062748791a..665ece0d55d4 100644 > > --- a/mm/page_table_check.c > > +++ b/mm/page_table_check.c > > @@ -102,6 +102,8 @@ static void page_table_check_set(struct mm_struct *mm, unsigned long addr, > > if (!pfn_valid(pfn)) > > return; > > > > + BUG_ON(is_zero_pfn(pfn) && rw); > > + > > Why we need use BUG_ON() here? Based on [1], we should avoid to use the > BUG_ON() due to it will panic the machine. > > [1]: https://lore.kernel.org/lkml/20220824163100.224449-1-david@redhat.com/ > > > page = pfn_to_page(pfn); > > page_ext = lookup_page_ext(page); > > anon = PageAnon(page); > > > > base-commit: b90cb1053190353cc30f0fef0ef1f378ccc063c5