From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751690AbdISQWe (ORCPT ); Tue, 19 Sep 2017 12:22:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43554 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751283AbdISQWc (ORCPT ); Tue, 19 Sep 2017 12:22:32 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BE936883B8 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dhowells@redhat.com Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <20170918204808.119855-1-ebiggers3@gmail.com> References: <20170918204808.119855-1-ebiggers3@gmail.com> To: Eric Biggers Cc: dhowells@redhat.com, keyrings@vger.kernel.org, Michael Halcrow , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Eric Biggers , stable@vger.kernel.org Subject: Re: [PATCH] KEYS: fix race between updating and finding negative key MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31181.1505838148.1@warthog.procyon.org.uk> Date: Tue, 19 Sep 2017 17:22:28 +0100 Message-ID: <31182.1505838148@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 19 Sep 2017 16:22:31 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Eric Biggers wrote: > Fix the bug by moving ->reject_error out of the union with ->payload, > then using nonzero ->reject_error to mean that the key is negative. > > This eliminates the need for KEY_FLAG_NEGATIVE, which we remove as well > so that we don't have to handle memory ordering between > KEY_FLAG_NEGATIVE and ->reject_error. We *do* still need to handle > memory ordering between KEY_FLAG_INSTANTIATED and ->reject_error, but > that was needed before (and for KEY_FLAG_NEGATIVE as well --- though it > wasn't done correctly, which was another bug). Hmmm... My only objection is that it extends struct key still further, but you do have a point. If we're going to do this, can we eliminate KEY_FLAG_INSTANTIATED also and make ->reject_error into ->status? 0 -> uninstantiated 1 -> instantiated <0 -> negatively instantiated/rejected Also, can we make it a short int please? Also, can setting this field be done with a release barrier rather than a write barrier? David