Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp6166237ybi; Wed, 29 May 2019 03:59:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqw7QdAOIfuYGsiv1c4xdL5r1g5BHJv7Ho86CxAfMkP6cDXhPxnUdQ7sZ4ypdpo6v8w43qxf X-Received: by 2002:a17:902:ca4:: with SMTP id 33mr102887654plt.107.1559127574713; Wed, 29 May 2019 03:59:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559127574; cv=none; d=google.com; s=arc-20160816; b=hp86UOWc1wXRfXS7PMmm5LXbjLyhhqXyb+ZSypzS3MH8dDlV9J5VlCGQXrs1KtLkjh 2V4RLiet3mEo9q8rhfkKMa3Mwv1OcI1i03CQusyRHV91hQNDfLNe/q4+buPeXvnkytoP yPnjUVxsLMUhxKVSc9SGafmDPmMMSS9HvCCTUfH86jctA0+8GG6IMGON2waqFActhApN 2A214Rx4iLPrkAklblceIZsJSQqwkktzRPMH+6zAtTqRG0n1mno4o97qESDDbkmD3EbC LrzycJWFTprBxUEy1yvzMdamBss7IKt/asR+i299Okn5ZnN6tDyWrFNdo2kwj+HzmXiZ HAkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=j0vRsAP/7oCPDaNFunzfNnWkHNHD3PczMiRqJpFCS8w=; b=0OUPhBm4cLezVFfqTBbzNQW2su87fIBIz9+zKKk5tuy+juz3rgT9kINVlGvMIF3qgj sR0urBMw8UzkVDXhAwETebAs+DUJN+PcJ+6hAsPESkdVnBOLuoQDxtX67ZQnHHVdl32N 1NxkJqPH4F0S8gLmMOapJbtMf+N7i+AmTdjwk1EtblWveisxAy4Bbwt/FQl7rYCRBe1e Zy0z/TUZFbRg7Hfwjv9J0HR4BzJV26kFWxgTMDO4vLEzwc2B1bqyCnUSHUyRjd2bZinF oo11EOPV+/Wvoc+SuZHdQ0jL3DsUyZF+S3ufUka6lqxLM3qYFmht+i4E8Kbxt0FxGt7H 1wfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=rtsUS66O; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q6si23157174pgp.483.2019.05.29.03.59.18; Wed, 29 May 2019 03:59:34 -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=@google.com header.s=20161025 header.b=rtsUS66O; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725948AbfE2K5d (ORCPT + 99 others); Wed, 29 May 2019 06:57:33 -0400 Received: from mail-it1-f195.google.com ([209.85.166.195]:35680 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726029AbfE2K5d (ORCPT ); Wed, 29 May 2019 06:57:33 -0400 Received: by mail-it1-f195.google.com with SMTP id u186so2809871ith.0 for ; Wed, 29 May 2019 03:57:32 -0700 (PDT) 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=j0vRsAP/7oCPDaNFunzfNnWkHNHD3PczMiRqJpFCS8w=; b=rtsUS66OXMb2mbLSKawrplR44Ksq1THB3HNVn1DNseo+u89Ythl4ZA2z6G+pEceOyh k/Ujhdfy++i5sHhkxmId2PeU6nf7C/H0JkrXQ4NKtvxy9jNs9QGtgLmqXvgaKG7Q6uE9 COzzdK3rqRrk1kF3xmfAZNC6OAxhCtx3+Ufs6FqeHIl/+5FLLO8wiupl+RIxRJ2xRRh/ JWgrneJjIv/Cjn/VMPYhERQzIS36u6n5j/PtHggx8SA8mSnnfS9Iq+gsQssSHINbnoYb x0TI0mOzhl6XeH2zgr/NbP7SdbKBLRHnV6kQLVCDD+ffvQrBM/J+z7yjbi9AVNCJlI1B wFpQ== 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=j0vRsAP/7oCPDaNFunzfNnWkHNHD3PczMiRqJpFCS8w=; b=CslLbRhGQ0M5zwlyPd+2vEslAv3pKgI+kmpQmgO/fHOjerBS6gZvm34qXqDO7VEFN9 0KfmXCsCtXBA6tYRNrE6OF1zIeHnKaUSk2zxrd4510fZcWhsivcR0goAbVbzvIPORvd5 SwThH8ozFsYNvNADjARdUj2g4lF+ZuVnrHvVnf2GTAdKX8lN8TkYMeiyHRhsPzPgpNfS DZobHjBw8pAbTzjCVgODbxW3H7IJ6lwZMSm6aQYW/cNuUfub7FRGIIBfUxlP1sCcO5/G LwPjvalEP2uyHQx92PdGoUQQn8wjWTJoIMVEQdhgHBAFYdlpwQfwsLm7mirXCfUleNIq k8oQ== X-Gm-Message-State: APjAAAUK0ymBcYIfa3rN2XkV7VCI/8rpYxuUY+9jZV5ZJi42Os6mCnIp r7IkG2krlRhFIbnkxM0dgO9iuDJQi0KTqSKC4xbfTQ== X-Received: by 2002:a24:c204:: with SMTP id i4mr6670043itg.83.1559127447315; Wed, 29 May 2019 03:57:27 -0700 (PDT) MIME-Version: 1.0 References: <20190528163258.260144-1-elver@google.com> <20190528163258.260144-3-elver@google.com> <20190528165036.GC28492@lakrids.cambridge.arm.com> <20190529100116.GM2623@hirez.programming.kicks-ass.net> <20190529103010.GP2623@hirez.programming.kicks-ass.net> In-Reply-To: <20190529103010.GP2623@hirez.programming.kicks-ass.net> From: Dmitry Vyukov Date: Wed, 29 May 2019 12:57:15 +0200 Message-ID: Subject: Re: [PATCH 3/3] asm-generic, x86: Add bitops instrumentation for KASAN To: Peter Zijlstra Cc: Marco Elver , Mark Rutland , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "the arch/x86 maintainers" , Arnd Bergmann , Josh Poimboeuf , "open list:DOCUMENTATION" , LKML , linux-arch , kasan-dev Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 29, 2019 at 12:30 PM Peter Zijlstra wrote: > > On Wed, May 29, 2019 at 12:16:31PM +0200, Marco Elver wrote: > > On Wed, 29 May 2019 at 12:01, Peter Zijlstra wrote: > > > > > > On Wed, May 29, 2019 at 11:20:17AM +0200, Marco Elver wrote: > > > > For the default, we decided to err on the conservative side for now, > > > > since it seems that e.g. x86 operates only on the byte the bit is on. > > > > > > This is not correct, see for instance set_bit(): > > > > > > static __always_inline void > > > set_bit(long nr, volatile unsigned long *addr) > > > { > > > if (IS_IMMEDIATE(nr)) { > > > asm volatile(LOCK_PREFIX "orb %1,%0" > > > : CONST_MASK_ADDR(nr, addr) > > > : "iq" ((u8)CONST_MASK(nr)) > > > : "memory"); > > > } else { > > > asm volatile(LOCK_PREFIX __ASM_SIZE(bts) " %1,%0" > > > : : RLONG_ADDR(addr), "Ir" (nr) : "memory"); > > > } > > > } > > > > > > That results in: > > > > > > LOCK BTSQ nr, (addr) > > > > > > when @nr is not an immediate. > > > > Thanks for the clarification. Given that arm64 already instruments > > bitops access to whole words, and x86 may also do so for some bitops, > > it seems fine to instrument word-sized accesses by default. Is that > > reasonable? > > Eminently -- the API is defined such; for bonus points KASAN should also > do alignment checks on atomic ops. Future hardware will #AC on unaligned > [*] LOCK prefix instructions. > > (*) not entirely accurate, it will only trap when crossing a line. > https://lkml.kernel.org/r/1556134382-58814-1-git-send-email-fenghua.yu@intel.com Interesting. Does an address passed to bitops also should be aligned, or alignment is supposed to be handled by bitops themselves? This probably should be done as a separate config as not related to KASAN per se. But obviously via the same {atomicops,bitops}-instrumented.h hooks which will make it significantly easier.