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 X-Spam-Level: X-Spam-Status: No, score=-11.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B7D5C388F7 for ; Tue, 10 Nov 2020 18:35:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CE3B7207D3 for ; Tue, 10 Nov 2020 18:35:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Bb7eV6Ff" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730174AbgKJSfO (ORCPT ); Tue, 10 Nov 2020 13:35:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725862AbgKJSfO (ORCPT ); Tue, 10 Nov 2020 13:35:14 -0500 Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59953C0613D3 for ; Tue, 10 Nov 2020 10:35:14 -0800 (PST) Received: by mail-il1-x141.google.com with SMTP id k1so13126055ilc.10 for ; Tue, 10 Nov 2020 10:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EcW7DGdRYPQre9d0rCuZTVN2xdKVZeP/11KAhpcdeGQ=; b=Bb7eV6Ffk30/lADN/CtBQNkUYKmIlGDuP5HgNdb7lko796qK+rPQAotrkNWYHqh5li 76lujpo108QS9f8ZA53B/idZGNhYqH00HMORfhYexedWrdx5jeraYbXN85UdToL1n61m IXglx2VBB8XZji5DYomCSjDtBhqN1MWHhxeV45Vcu9otTPkCVMr1FltZPW9xNky0VTxe eidiazNZla3CPfk22mus83C/TSQMvzGRSvriokLQ2ZvS7v32J3z3Ya8r+ie53hSa28FI 8fZZe6y7gGahOslzrH1tnScTCa70j4VkRQXPfrdq0iSAJpfxAKuXo/t9AkMgD2bWLkOH 15Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EcW7DGdRYPQre9d0rCuZTVN2xdKVZeP/11KAhpcdeGQ=; b=Umm0dGOQbq87mzL+Df/P4jV/IJHS+PfpOI62ABpEz73d2WqSPV3we1dolEm0Gt97ed xxnlkY8gPURqaR2FWPDCMBtiDigLwA1s1rRD3FMMi6ckfEdYsrclI8QxL+GYtP+T4zld cbrYoBeZ3tS7S/OnmF+N+fxZaalOGrkiIRxN2Ne89ZhWim5q9Tt8nr0WLTRhGvCdItUD 9Ry/rNuCiKnpeLhq0GEJK7d1tbevaLkjVUBgfHPXXs13N64EBvNxSi38MsvOOJOsxJv0 bTeon8QuCPfgmLeaXt6O5iIi2mzMENW+x1Cq1in8yXIlQrxmBDjrHw0bKqbTyfyP+3+y BNcA== X-Gm-Message-State: AOAM533R3cdZTf+BB337P1LgZSfVgvRulHSHsZt/cUCQtMuL3QWbjqFo Lv5JH6/duMyPkCK1D9LpmSLMpAB74NFEVu0KRG+9/Q== X-Google-Smtp-Source: ABdhPJwW0NyVtuugVDLRW5lkeqwxCPGA/28xMTg1/Ar0AmTrISyPlZ7xPsV/9rqOwGigTwHHYFH+KXQJDnsmstuQC0o= X-Received: by 2002:a92:6504:: with SMTP id z4mr14758818ilb.282.1605033313560; Tue, 10 Nov 2020 10:35:13 -0800 (PST) MIME-Version: 1.0 References: <20201029183526.2131776-1-aleksandrnogikh@gmail.com> <20201029183526.2131776-2-aleksandrnogikh@gmail.com> <04d8c32a-06cd-d71a-43d9-47b1de6c7684@i-love.sakura.ne.jp> In-Reply-To: <04d8c32a-06cd-d71a-43d9-47b1de6c7684@i-love.sakura.ne.jp> From: Aleksandr Nogikh Date: Tue, 10 Nov 2020 21:35:02 +0300 Message-ID: Subject: Re: [PATCH v3 1/2] security: add fault injection capability To: Tetsuo Handa Cc: Aleksandr Nogikh , jmorris@namei.org, serge@hallyn.com, Akinobu Mita , Andrey Konovalov , Dmitry Vyukov , Marco Elver , Alexander Potapenko , Kees Cook , Casey Schaufler , LKML , linux-security-module@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 10, 2020 at 7:43 AM Tetsuo Handa wrote: > [...] > > By the way, fail_lsm_hooks.retval is "signed int" but debugfs_create_u32() handles "unsigned int". > Do we want to allow lsm_hooks_inject_fail() to inject arbitrary !IS_ERR_VALUE() values? Thanks for pointing it out. Technically, now it's possible to set a negative value - internally, the kernel will process negative integers anyway, and after casting the unsigned value to a signed one, retval will contain exactly what the user provided. However, if the user retrieves the attribute value, they won't get the exact value that was set (if it was negative). I'll change debugfs_create_u32 to something else in v4, so that it'll be more explicit and so that it'll be possible to read negative values normally.