Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1992522yba; Thu, 25 Apr 2019 08:57:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqzTBDe2hoEZ3YU4fhxSbVflTbLgeh0xnGDCONHP6p6sP+mFoV+FKU/vbD2DNqX+2nTt0ciE X-Received: by 2002:a17:902:758b:: with SMTP id j11mr2740865pll.87.1556207825003; Thu, 25 Apr 2019 08:57:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556207824; cv=none; d=google.com; s=arc-20160816; b=QjB3Dej27eVzApkuMDjDpHLQ9wjgHGHa7gZ2bDiFNHerT5YyUOlBOeIK1kaiOk2GGl QOQMJ5mE1dNm7BQHbeXiy6/el0+msMcwwuhJ+rgF7mahnFVaBFgK4EriXWDT+XyZSWFX +1jI0SrheoCWcOrjq39SvZ/S+Upz0tJ+Fu0tG03slM7A+dDPney0rCuyiF6nv7+zWY9G YDteOTC8y9M6nzruykqAx4lm+bvtIugdu1HtTD9lOShBimE8zB/YikzrNtjItQZQm6ju 90yvWhxZsGI4pcvHLylEkj6jnsmH62e2PdzvKPrYqGmBvZXF9Fgo3vSswqdHwKOjkyj0 Wvfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:feedback-id:mime-version:user-agent :references:message-id:in-reply-to:subject:cc:to:from:date :dkim-signature; bh=pO2pP6FljQafTmg62m+I2qdYl7zhRSiQcJpHjYrZsOI=; b=UAgI4lDvwuzIxUjmY6qfR8LNv87BRQMpBl63WJMkdhT3Oj07Xfhv+89Yvt7WQ1OCD5 XCLG2kmN7OtBAxSy0z9eQsSw565AfnzSGdfYOoDdK6JbxpC2D/OHFB9Z9fkcGKms53MO y1U82crPNsFhzr5MZgRoT2VUeYndPtpns85PwsjOXCGAIa7h+18fqjPtelj31jYJDOqv TyUx/xVy1u9nCAjqloFjAEkNYG/BfHQhES0ZRIGBKsI0iQ0po9dgIiquXEPWb8d+8Iwp QS2vyu63nzkSiVRfBuJ8Vccjv2SPF7bprTx+1g4iXnsmeAef2gE/e/GMmvdXVmq0PIrY B0Og== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=Ksz6Xw2L; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 33si23082970plk.421.2019.04.25.08.56.49; Thu, 25 Apr 2019 08:57:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=Ksz6Xw2L; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727970AbfDYPco (ORCPT + 99 others); Thu, 25 Apr 2019 11:32:44 -0400 Received: from a9-37.smtp-out.amazonses.com ([54.240.9.37]:42332 "EHLO a9-37.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729689AbfDYPcn (ORCPT ); Thu, 25 Apr 2019 11:32:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556206362; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-Type:Feedback-ID; bh=pO2pP6FljQafTmg62m+I2qdYl7zhRSiQcJpHjYrZsOI=; b=Ksz6Xw2LBldNY0PeACCSCxyacWYJi2nwVBs9e+UrzD4PQHyFDVKetoqaWKWpQnf0 WM46Uqwjfx9t2aT4o6gE4SwbHRswpzYhPz0+X6YzhW2kWmvYu3dGcDZzhQLlo06NBK3 KiN0MpVrYl1Ekn3YvEVgztvzplukXEXDA+f/sMhI= Date: Thu, 25 Apr 2019 15:32:42 +0000 From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Matthew Garrett cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Matthew Garrett Subject: Re: [PATCH] mm: Allow userland to request that the kernel clear memory on release In-Reply-To: <20190424191440.170422-1-matthewgarrett@google.com> Message-ID: <0100016a55209db0-efc46978-fa1e-48be-b17a-fcb6b58ae882-000000@email.amazonses.com> References: <20190424191440.170422-1-matthewgarrett@google.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SES-Outgoing: 2019.04.25-54.240.9.37 Feedback-ID: 1.us-east-1.fQZZZ0Xtj2+TD7V5apTT/NrT6QKuPgzCT/IC7XYgDKI=:AmazonSES Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 24 Apr 2019, Matthew Garrett wrote: > Applications that hold secrets and wish to avoid them leaking can use > mlock() to prevent the page from being pushed out to swap and > MADV_DONTDUMP to prevent it from being included in core dumps. Applications > can also use atexit() handlers to overwrite secrets on application exit. > However, if an attacker can reboot the system into another OS, they can > dump the contents of RAM and extract secrets. We can avoid this by setting Well nothing in this patchset deals with that issue.... That hole still exists afterwards. So is it worth to have this functionality? > Unfortunately, if an application exits uncleanly, its secrets may still be > present in RAM. This can't be easily fixed in userland (eg, if the OOM > killer decides to kill a process holding secrets, we're not going to be able > to avoid that), so this patch adds a new flag to madvise() to allow userland > to request that the kernel clear the covered pages whenever the page > reference count hits zero. Since vm_flags is already full on 32-bit, it > will only work on 64-bit systems. But then the pages are cleared anyways when reallocated to another process. This just clears it sooner before reuse. So it will reduce the time that a page contains the secret sauce in case the program is aborted and cannot run its exit handling. Is that realy worth extending system calls and adding kernel handling for this? Maybe the answer is yes given our current concern about anything related to "security".