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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F98AC433EF for ; Thu, 30 Jun 2022 07:53:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C2C28E0002; Thu, 30 Jun 2022 03:53:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 371908E0001; Thu, 30 Jun 2022 03:53:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2393A8E0002; Thu, 30 Jun 2022 03:53:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 114508E0001 for ; Thu, 30 Jun 2022 03:53:16 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D38E11294 for ; Thu, 30 Jun 2022 07:53:15 +0000 (UTC) X-FDA: 79634136750.03.E85479F Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by imf10.hostedemail.com (Postfix) with ESMTP id 73185C0037 for ; Thu, 30 Jun 2022 07:53:15 +0000 (UTC) Received: by mail-wr1-f49.google.com with SMTP id i25so20455836wrc.13 for ; Thu, 30 Jun 2022 00:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k2a71x297ZADJzEPxttWEizkIknOexDX93mkmWqB2RE=; b=iL+4gYKEmRYRhP/EAIFUUv0eHXf37WrALCqJ8rYPPqnVghuCOw0+od/pXFe4pmUpwq MkY3fKo+PMK5V+hRsccI98WwWUG45LY4xpH+yFAsTZ1hrmoHEmPaVVQpdIwVqARZSWOb B13tZZV671MAQNhWX8kyS3di3TT6/Z0AtKctuXaZgHY7ELGSNCwOV5Sk693HMz+BQaxE ABOpxlI4mxlB8RdTwO3qsbFhzN//ncvti7vlJGTbYseEb7x7zlfd2nOkR6H13rNxo0tJ x0CkMeene+CNVm42kqY53oMPo6mqrgljcCRe+L4HD/7HsjBqhY0+BDIa+b1n9/A/KCHO 5JMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k2a71x297ZADJzEPxttWEizkIknOexDX93mkmWqB2RE=; b=1dXoxkvX5J9K7sOwHSFvKC5E/ufkPf9dCxucKd8oyac3WrVjlK5US2wiTNaOTrXBlF gbVs2Rm6K68iA9Begb6Yf8QU8BBzCyDM5pJI2t1lJlb6F7SglM12B8G6RQRc3X6TXAcz 2pYvm7+2vUvtlkvH1b1EXXRZeoBZbT0j7jvTY9O1G13L8bhUhAPewUIWtTf5tbXDZ3HG sH4ULMMbYiLp8onb+gMN3Zr+1rhwxoukrR7DOShkdar4P+gk55orS+sWVyaQrwmNYDLD 2IzLxZgcBuiq3beS0VppKx8jxD+g0BcAy+XMXZCUyyA+A1hZuEG6+cSek/xsFEHTNXQX Z8Yw== X-Gm-Message-State: AJIora/EfNlxItWy5u+4NX3SqjD/o34GmT8FBZN2YoddgOz/HdAaM6o5 I2PrmPw3k14GpCh2Xi79moZZVajOJFW6r2BBZdXDuA== X-Google-Smtp-Source: AGRyM1u/EZ4JKaKS7hWiFLohAuDyr6Q1NZPrj9AIsTAlWbGBF+jSB2lmwsSysJ5PG3ER+YrMZ4nXykQzqKP7d2sbdFs= X-Received: by 2002:a05:6000:1ac8:b0:21b:9239:8f28 with SMTP id i8-20020a0560001ac800b0021b92398f28mr7092801wry.517.1656575593964; Thu, 30 Jun 2022 00:53:13 -0700 (PDT) MIME-Version: 1.0 References: <20220527185600.1236769-1-davidgow@google.com> <20220527185600.1236769-2-davidgow@google.com> In-Reply-To: From: David Gow Date: Thu, 30 Jun 2022 15:53:02 +0800 Message-ID: Subject: Re: [PATCH v2 2/2] UML: add support for KASAN under x86_64 To: Johannes Berg Cc: Vincent Whitchurch , Patricia Alfonso , Jeff Dike , Richard Weinberger , Anton Ivanov , Dmitry Vyukov , Brendan Higgins , Andrew Morton , Andrey Konovalov , Andrey Ryabinin , kasan-dev , linux-um , LKML , Daniel Latypov , Linux Memory Management List Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=iL+4gYKE; spf=pass (imf10.hostedemail.com: domain of davidgow@google.com designates 209.85.221.49 as permitted sender) smtp.mailfrom=davidgow@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656575595; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=k2a71x297ZADJzEPxttWEizkIknOexDX93mkmWqB2RE=; b=gCw4VyFd2c4RvdxwltGYoL6vayAK8W1c92UohvsGy/fa7LfBJsRZVcoC+aSFRJnl9AR8dS Wv0nXVGi54nFFmXUTHUxuI1iuzPmXrgHjgwliAaQZOcHNfzl+ssWE5lj3AQ/LNWi0UFXT1 nGWTQRJZy+4DQtMI/LQEKDorlX30pPc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656575595; a=rsa-sha256; cv=none; b=OUws7lhlGNC7PNwZ7pA+ZW/+HLxWgkasaF1fb+JqRz6Nw+uRnIcQYf6fJfdK3Za+XQS7K3 v//PvlcrO0FpmgY470WzmvWbCxSXBe3+0I0g263L/KL8yierCG2m8Y1GGhBTXhjQF4Paqp mDdq3WO416jtUQYwrg92aLRjyb4PKAQ= X-Stat-Signature: wxiwqaphu7hyw7xz39odogc81r19pk3i X-Rspamd-Queue-Id: 73185C0037 Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=iL+4gYKE; spf=pass (imf10.hostedemail.com: domain of davidgow@google.com designates 209.85.221.49 as permitted sender) smtp.mailfrom=davidgow@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam12 X-Rspam-User: X-HE-Tag: 1656575595-381894 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, May 28, 2022 at 4:14 AM Johannes Berg wrote: > > On Fri, 2022-05-27 at 11:56 -0700, David Gow wrote: > > > > This is v2 of the KASAN/UML port. It should be ready to go. > > Nice, thanks a lot! :) > Thanks for looking at this: I've finally had the time to go through this in detail again, and have sent out v3: https://lore.kernel.org/lkml/20220630074757.2739000-2-davidgow@google.com/ > > It does benefit significantly from the following patches: > > - Bugfix for memory corruption, needed for KASAN_STACK support: > > https://lore.kernel.org/lkml/20220523140403.2361040-1-vincent.whitchurch@axis.com/ > > Btw, oddly enough, I don't seem to actually see this (tried gcc 10.3 and > 11.3 so far) - is there anything you know about compiler versions > related to this perhaps? Or clang only? > > The kasan_stack_oob test passes though, and generally 45 tests pass and > 10 are skipped. > Given this patch has already been accepted, I dropped this comment from v3. As you note, the issue didn't reproduce totally consistently. > > +# Kernel config options are not included in USER_CFLAGS, but the > > option for KASAN > > +# should be included if the KASAN config option was set. > > +ifdef CONFIG_KASAN > > + USER_CFLAGS+=-DCONFIG_KASAN=y > > +endif > > > > I'm not sure that's (still?) necessary - you don't #ifdef on it anywhere > in the user code; perhaps the original intent had been to #ifdef > kasan_map_memory()? > I've got rid of this for v3, thanks. > > +++ b/arch/um/os-Linux/user_syms.c > > @@ -27,10 +27,10 @@ EXPORT_SYMBOL(strstr); > > #ifndef __x86_64__ > > extern void *memcpy(void *, const void *, size_t); > > EXPORT_SYMBOL(memcpy); > > -#endif > > - > > EXPORT_SYMBOL(memmove); > > EXPORT_SYMBOL(memset); > > +#endif > > + > > EXPORT_SYMBOL(printf); > > > > /* Here, instead, I can provide a fake prototype. Yes, someone cares: genksyms. > > diff --git a/arch/x86/um/Makefile b/arch/x86/um/Makefile > > index ba5789c35809..f778e37494ba 100644 > > --- a/arch/x86/um/Makefile > > +++ b/arch/x86/um/Makefile > > @@ -28,7 +28,8 @@ else > > > > obj-y += syscalls_64.o vdso/ > > > > -subarch-y = ../lib/csum-partial_64.o ../lib/memcpy_64.o ../entry/thunk_64.o > > +subarch-y = ../lib/csum-partial_64.o ../lib/memcpy_64.o ../entry/thunk_64.o \ > > + ../lib/memmove_64.o ../lib/memset_64.o > > I wonder if we should make these two changes contingent on KASAN too, I > seem to remember that we had some patches from Anton flying around at > some point to use glibc string routines, since they can be even more > optimised (we're in user space, after all). > > But I suppose for now this doesn't really matter, and even if we did use > them, they'd come from libasan anyway? I had a quick look into this, and think it's probably best left as-is. I think it's better to have the same implementation of these functions, regardless of whether KASAN is enabled. And given that we need the explicit, separate instrumented and uninstrumented versions, we'd need some way of having one copy which came from libasan and one which was totally uninstrumented. But if the performance difference is really significant, we could always revisit it. > > Anyway, looks good to me, not sure the little not above about the user > cflags matters. > > Reviewed-by: Johannes Berg > Cheers, -- David