From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226PoJcTBDAbnEDIjZ9pQj3sYIXSCyCpPQleqxDBqSFFjjBKDy+Q+R/MuIY+5PBUBWWLS8g0 ARC-Seal: i=1; a=rsa-sha256; t=1517320020; cv=none; d=google.com; s=arc-20160816; b=OB6V6ie5a8hhdJvB7JrXubloAt2F5YGw8bwmtW17A5jO6dUd3qx002PM/VR/WTGUXo VPxynJ/X3H9jtXmIS9QG/dgLlXe/iGUuoK1alkQQHWkZkul3zaZ1aHsrnFfmb/B64g22 YLYUbBcEulE/KQHhwcHRiy13ecRjtm5ISqZWEyPCJ97IYiJZngDE8ZUCjUgMhzI62d8U iutEEeMEL5dze/8yy8YMyUP2SmwpWxnTISXd2EuOsvDX7R0dmKTX09ePRnEaJM2z19Yc RzmPkvs1v26IIqCfn9cyxX/e4LwPk0lDE9FFqt58YdLUbxz9hlluoKwsJOCdNSn1gl4/ K6xQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :delivered-to:list-id:list-subscribe:list-unsubscribe:list-help :list-post:precedence:mailing-list:arc-authentication-results; bh=wG5T6RyN/ZHdF4y5Fj3Di7bvo5RIUt+uNRZVfRDxfIw=; b=MR3g35PXqWej3srVfoVNu2tAXfGn7eTXevDZcMZPCGkaG9o08C1N8K58CpmTTSaba+ fx2XNFtI/H6g1N3hAO0VcUCzR8DQP3kePbs9h0wScEPp7/jDQ1T0kZ1adFLQffbT0jsS J0j1PXL/B5NEY04r1lGSnPwsChdTKYegnVlWcILAvVl98dIQPlMmJsgPygV/Z1wQCPPM xpDlKaE4sW/JztFKuXbWzO1l58Zxg5CAP1O5SutruQBy+22Jav61KcLfXWZDprFoJM8o gSdBURh+WVJvaTsLJawlQwNcyRT6iA4JKxKI6UqtIBWaJohPXsY4eobQnJWAIneiqCqx 2bew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11527-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11527-gregkh=linuxfoundation.org@lists.openwall.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11527-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11527-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: Subject: Re: [kernel-hardening] [PATCH 4/6] Protectable Memory To: Boris Lukashev CC: Jerome Glisse , Jann Horn , "Kees Cook" , Michal Hocko , Laura Abbott , Christoph Hellwig , Matthew Wilcox , Christoph Lameter , linux-security-module , Linux-MM , kernel list , "Kernel Hardening" References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <6c6a3f47-fc5b-0365-4663-6908ad1fc4a7@huawei.com> <20180125153839.GA3542@redhat.com> <8eb12a75-4957-d5eb-9a14-387788728b8a@huawei.com> From: Igor Stoppa Message-ID: <5782e30f-76b3-cf6f-e865-666aa958685e@huawei.com> Date: Tue, 30 Jan 2018 15:46:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.122.225.51] X-CFilter-Loop: Reflected X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590497635371449856?= X-GMAIL-MSGID: =?utf-8?q?1591025358066853390?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 26/01/18 18:36, Boris Lukashev wrote: > I like the idea of making the verification call optional for consumers > allowing for fast/slow+hard paths depending on their needs. > Cant see any additional vectors for abuse (other than the original > ones effecting out-of-band modification) introduced by having > verify/normal callers, but i've not had enough coffee yet. Any access > races or things like that come to mind for anyone? Well, the devil is in the details. In this case, the question is how to perform the verification in a way that is sufficiently robust against races. After thinking about it for a while, I doubt it can be done reliably. It might work for some small data types, but the typical use case I have found myself dealing with, is protecting data structures. That also brings up a separate problem: what would be the size of data to hash? At one extreme there is a page, but it's probably too much, so what is the correct size? it cannot be smaller than a specific allocation, however that would imply looking for the hash related to the data being accessed, with extra overhead. And the data being accessed might be a field in a struct, for which we would not have any hash. There would be a hash only for the containing struct that was allocated ... Overall, it seems a good idea in theory, but when I think about its implementation, it seems like the overhead is so big that it would discourage its use for almost any practical purpose. If one really wants to be paranoid could, otoh have redundancy in a different pool. -- igor