Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Fri, 24 Nov 2023 08:45:38 +0800
From:   Feng Tang <feng.tang@intel.com>
To:     Andrey Konovalov <andreyknvl@gmail.com>
CC:     "andrey.konovalov@linux.dev" <andrey.konovalov@linux.dev>,
        Andrew Morton <akpm@linux-foundation.org>,
        Marco Elver <elver@google.com>,
        "Alexander Potapenko" <glider@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        "Vlastimil Babka" <vbabka@suse.cz>,
        "kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
        Evgenii Stepanov <eugenis@google.com>,
        "Oscar Salvador" <osalvador@suse.de>,
        Hyeonggon Yoo <42.hyeyoo@gmail.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Andrey Konovalov <andreyknvl@google.com>
Subject: Re: [PATCH mm] slub, kasan: improve interaction of KASAN and
 slub_debug poisoning
Message-ID: <ZV/yMuH6jbfD6ZPi@feng-clx>
References: <20231122231202.121277-1-andrey.konovalov@linux.dev>
 <ZV7whSufeIqslzzN@feng-clx>
 <CA+fCnZcAnZh7H901SZFsaU=-XrpUeeJwUeThMpduDd1-Wt0gsA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+fCnZcAnZh7H901SZFsaU=-XrpUeeJwUeThMpduDd1-Wt0gsA@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N2RZalZKYmhSbDFKcHZ6czR2TGRVTWdhQ3hnUStnVEp3eVhwK1pKOFp1U3pj?=
 =?utf-8?B?Q0pLT1h6RmJkLzIrVjE5ZFEyeVdXbkpRaHZzbXdhSGErWnBiT0ltRnczUG5r?=
 =?utf-8?B?eHNCS1JwTGNJN2ZUWTBCU0xyQ2t0WDNUVWhyVmozMXdpNXpWMkJlb3hSMDlm?=
 =?utf-8?B?NUw2akhYVDc4eFJLbS94d3lRRnJJRy9nSHdFeHpZTDVoeW93dnBxblNUZVAz?=
 =?utf-8?B?MmxkdmgvSFNuam55NHlITjM5MmxZZVF2M0ZVMHA1MklUOUErbDhmQ24rVkpT?=
 =?utf-8?B?WVJLYWNMSVFJeXhPekVnKzJnTW5NM2I0Z2JMWS9IbzdPQ0M0SytWVWtoMHc2?=
 =?utf-8?B?QTZsMjUrWUtDK3cyVmdVMVgzZEVGN3FUUXpwM0gwNHhYNTErM3dGNUt3N1Jy?=
 =?utf-8?B?UEJaSGNMeXI1dHZneVZqM0pmR1FqYlpRNEdSc0g5K2xSSDN0KzNCSDRTdXlV?=
 =?utf-8?B?SmNvMmwvQzdidnh1ay8xTUNIdFZNOVZzaXNOV2hhMk5YNmVITWsrNEdiVWxS?=
 =?utf-8?B?OXlhWDlpUVM1OGlWY0RCN3ArV0lHaFBSdmhuZEc5OVlLK0lEWEQ4akhJSDlF?=
 =?utf-8?B?aXZXQldtVDZWUXo5RnFvSjN2YmRSYmIzUU5tRDNSNE1ySGFTMWpjaWNMV09B?=
 =?utf-8?B?WXFGTVBiTkg5MWJlNmlWYlVUOXRmMTRoQkQ0UTRQY2NPUUkvU0JkWHlTczND?=
 =?utf-8?B?N0k2M3JPVTc1NTNNSnBxeXhhZ2FJM3VUOStLS0Y5SVNLVG83WFNCWFJUQlJp?=
 =?utf-8?B?cHMvbi9EaVlrZ082ZDduWlpIeGZOZklSWGw0M3RsWEZhczYzNjFWVUFjbUpt?=
 =?utf-8?B?b1hhVXZDc0F4SC9La1p5QnVvMHZRbDNNd21IYUZRYm15enBPZFhReGs2UTZW?=
 =?utf-8?B?TnMyU3ZKbGkrVk82SVNvVklNcEUyK0xHVlFFTEludS9jdDJvaFE3QVBqTnBT?=
 =?utf-8?B?dnlHM0VGVGtqSmd6azBMTnpDNFBvS2JzU3JlYVNlcENibDlwS0JhdjRjb3Vl?=
 =?utf-8?B?RFFGMGc1RVZwelNvNEFuV1VvckdCaXdzUmFkNExHQ0xlZWpRUlFDMXorTU1y?=
 =?utf-8?B?OEM1RkJHdGRMUGkyaHJ6N1c1STFlaVZzYTI1RWtyNFZzNzB2REdrb2VwRkNZ?=
 =?utf-8?B?TUpuTWFNbGtySFZkdlU3YnBxZzQ4NjhMSDEyL0toVkR1Yi9SSjVhZXZkVjVh?=
 =?utf-8?B?dWh0TUFTMWlpSHNiUHcxZk9sYnVMaFRRRkVyY2pYb3JVSVBtaHZzakdVRnFM?=
 =?utf-8?B?b3VIcFg2R3N6SmF1cUpkblJZMXhyMDN5UDg2MkRnSGFQd0pkNnVUQWFUY05P?=
 =?utf-8?B?bnJWRDQyM0FJSEhyOEppdDlaRVY0UW1rZGErQjV4bEk0MlBwVC9uQkxpNWF6?=
 =?utf-8?B?WFQxejdJcHIramhPL2FaNHFCazI0eTJhd21IR3dsMDJ2ZGJFWGEvdjVZRmls?=
 =?utf-8?B?dnlNclJBZ242TVU5MmM3Qld5ZVFaZDRYWHdrT1hNWHE0NEZtT29vamZqOGth?=
 =?utf-8?B?S2w5UGk3NURXeVJ3bCs2eFk0RUVhQlliTlBndU12cUI2RlZwVFhUeTFtVzFX?=
 =?utf-8?B?UlJEKzRJSjBVYWR0bXQrY245V1JvU3RGR09LUCtYUk43UFFST25BcFJUUjJ0?=
 =?utf-8?B?WVZjS1ppbUxDZ0hrK1dUaFNyQUpmOHRpNEhuWWVBbHJtakIyb3Zvb1RWYVk3?=
 =?utf-8?B?UlVDVngwaHEvNzdpNEd0YlEzdlBNajFWVk05ZVJtekU4ODRsL3A5WWhlTHlH?=
 =?utf-8?B?WVZpN1ppb3ZXSkZOWFFxbllhMStLbWMzNGxqankrNHhUMVN4amkrdWNLZnB2?=
 =?utf-8?B?czhSVTNDL3E1SUY1WnhKUTRMUjBuWHJ3MFRaakNZN25kNWVpOXBQVm9tNHNS?=
 =?utf-8?B?cnFSVzNMbzRNWUszSlpDUTh5YlVqbUx2Q2ZpY0FjM3JGWU5ETytIWlYxUS9O?=
 =?utf-8?B?ajlteVRRY3N3RXpNTnl2VlJkbDdQa1NOTWduWm1MRXppcmRNc2JPSmtleUtk?=
 =?utf-8?B?S2U2cHFvd3FTMzd2REdSLzdGSUJuTGZCY2w0bk9KNUZkTUtYcTBkS0xwTEM5?=
 =?utf-8?B?UitYU3dMQVE1QkxKZ1IvdUlYandQSkd2NUw0RUE4M3U4a0FScGh1cVE2QUx6?=
 =?utf-8?Q?0uxhnJEQ4e5Z8dyA/nfKgsyLl?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ab128ee-7f5e-46a2-d561-08dbec87f16b
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2023 00:54:42.3443
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /nUxwmSeTmPbetsbrgFeBHPGSd2YXarcp+35n9B3OG+g5/znCo9IcZwNkIt69oQmfHzZu/Y8Oi/tlyOIH5T49g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5477
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Thu, 23 Nov 2023 16:55:00 -0800 (PST)

Hi Andrey,

On Thu, Nov 23, 2023 at 05:12:08PM +0100, Andrey Konovalov wrote:
> On Thu, Nov 23, 2023 at 7:35 AM Feng Tang <feng.tang@intel.com> wrote:
> >
> 
> Hi Feng,
> 
> > > --- a/mm/slub.c
> > > +++ b/mm/slub.c
> > > @@ -870,20 +870,20 @@ static inline void set_orig_size(struct kmem_cache *s,
> > >                               void *object, unsigned int orig_size)
> > >  {
> > >       void *p = kasan_reset_tag(object);
> > > +     unsigned int kasan_meta_size;
> > >
> > >       if (!slub_debug_orig_size(s))
> > >               return;
> > >
> > > -#ifdef CONFIG_KASAN_GENERIC
> > >       /*
> > > -      * KASAN could save its free meta data in object's data area at
> > > -      * offset 0, if the size is larger than 'orig_size', it will
> > > -      * overlap the data redzone in [orig_size+1, object_size], and
> > > -      * the check should be skipped.
> > > +      * KASAN can save its free meta data inside of the object at offset 0.
> > > +      * If this meta data size is larger than 'orig_size', it will overlap
> > > +      * the data redzone in [orig_size+1, object_size]. Thus, we adjust
> > > +      * 'orig_size' to be as at least as big as KASAN's meta data.
> > >        */
> > > -     if (kasan_metadata_size(s, true) > orig_size)
> > > -             orig_size = s->object_size;
> > > -#endif
> > > +     kasan_meta_size = kasan_metadata_size(s, true);
> > > +     if (kasan_meta_size > orig_size)
> > > +             orig_size = kasan_meta_size;
> >
> > 'orig_size' is to save the orignal request size for kmalloc object,
> > and its main purpose is to detect the memory wastage of kmalloc
> > objects, see commit 6edf2576a6cc "mm/slub: enable debugging memory
> > wasting of kmalloc"
> >
> > Setting "orig_size = s->object_size" was to skip the wastage check
> > and the redzone sanity check for this 'wasted space'.
> 
> Yes, I get that.
> 
> The point of my change was to allow slub_debug detecting overwrites in
> the [kasan_meta_size, object_size) range when KASAN stores its free
> meta in the [0, kasan_meta_size) range. If orig_size is set to
> object_size, writes to that area will not be detected. I also thought
> that using kasan_meta_size instead of object_size for orig_size might
> give the reader better understanding of the memory layout.
> 
> > So it's better not to set 'kasan_meta_size' to orig_size.
> 
> I don't have a strong preference here: slub_debug and KASAN are not
> really meant to be used together anyway. So if you prefer, I can
> revert this change and keep using object_size as before.

Thanks for the explanation! I got your point now. I'm fine with either
way, as this change can help to enforce the redzone check for all
kmalloc objects, while can make some debug wastage info less accurate. 

Thanks,
Feng

> 
> > And from the below code, IIUC, the orig_size is not used in fixing
> > the boot problem found by Hyeonggon?
> 
> No, this is a just a partially-related clean up. It just seemed
> natural to include it into the fix, as it also touches the code around
> a kasan_metadata_size call.
> 
> Thanks!