Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 11 Nov 2022 16:29:43 +0800
From:   Feng Tang <feng.tang@intel.com>
To:     Vlastimil Babka <vbabka@suse.cz>
CC:     Andrew Morton <akpm@linux-foundation.org>,
        Christoph Lameter <cl@linux.com>,
        Pekka Enberg <penberg@kernel.org>,
        David Rientjes <rientjes@google.com>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Roman Gushchin <roman.gushchin@linux.dev>,
        Hyeonggon Yoo <42.hyeyoo@gmail.com>,
        "Dmitry Vyukov" <dvyukov@google.com>,
        Andrey Konovalov <andreyknvl@gmail.com>,
        "Kees Cook" <keescook@chromium.org>,
        "Hansen, Dave" <dave.hansen@intel.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>
Subject: Re: [PATCH v7 0/3] mm/slub: extend redzone check for kmalloc objects
Message-ID: <Y24H998aujvYXjkV@feng-clx>
References: <20221021032405.1825078-1-feng.tang@intel.com>
 <f9da0749-c109-1251-8489-de3cfb50ab24@suse.cz>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <f9da0749-c109-1251-8489-de3cfb50ab24@suse.cz>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?xp9NVgGXR9FlqHlaoHaIOoUaRgQQ0iHu/dUS9cXxptNqw8+Psn4iIglJkasT?=
 =?us-ascii?Q?YefeQSLDOcHNOgz0alTVMS1Ve3ta1IiAmYCqUvlwvto5KQlF4X7M+fll+nCh?=
 =?us-ascii?Q?T+cFoL82jDxCASFm3u1v1lQDtjcM82SmYj2yexkYC2RQf11yMq4VFLDXJ1KQ?=
 =?us-ascii?Q?MB4TK+alIUdaH83jXDDKdVpjuQP7DJD4spuDrsGlh8Ho7wICIAyvzbcCnvcP?=
 =?us-ascii?Q?bMz7j14PJMwcZ7rspsNaMWck2920unvWiKPR/DuuCLxPYmU1N7ng3DsQZG1B?=
 =?us-ascii?Q?/Et66srIo9oUOhN6MpQEKMjOC0z3DPQ0TdflYhSrZ4WwAPr2tUamQImoIFoz?=
 =?us-ascii?Q?Eubvuu+2GwTLIQrSFNnfPZemVd6zpxhKeL1CSs/CBmk51Lf7rs19++4bwQU1?=
 =?us-ascii?Q?jnAQJVz1ODFyP2u0uQW4FWC0zy+4D5A78QX1C4ox4We9NS/g2oQsZJ0WElza?=
 =?us-ascii?Q?sBeBzYJol8J7ZEnEzI8+CX6tdtUBsAvzmQHF2VRqUkEzUxVmLX4DQjRSU5xm?=
 =?us-ascii?Q?ZqJ9V/2obxAN+7QNap+jrwNesXNWe/QfKYGw8R1Bc6LInes882X8biLRvoaX?=
 =?us-ascii?Q?P16GCvdufmRgb+n+W3yylaV3kxJ9ewaiKAE99IBVmmbLuiEHwp+wDAX3qWvl?=
 =?us-ascii?Q?ItYby639Bxmditq5FMWt6CLDDJOI33BC2l4l+b5Yy7Q9bI2dwDSQlzRvCh6C?=
 =?us-ascii?Q?WE23FFO0CfKStulqU0mL937iuzVLEeLJPMr5vfRLMf5lpwowM0Az8jlE2m4Y?=
 =?us-ascii?Q?d8Z2kYBY8OWl7Lu5uCcrlaBs39sWFjXCiVhZW5B8FywiL2Ep9/9HC1I/sYOI?=
 =?us-ascii?Q?1CwFlujC1OcRL8u2CkI4IAWF/N9YW7VLXWg6OzejSo64PiXEXPzebpIVBtcT?=
 =?us-ascii?Q?Z5WOMr+zdWcunm5f63NF3oerMLKre5PImU+h7Sk+barQ4l1YXXsXcLP+mrKo?=
 =?us-ascii?Q?3VFQ3FwioaudAMfALf7geDvzmI7Lb4y14V6yc750YczheUS59XyQ8/Hw5aJG?=
 =?us-ascii?Q?hpmUlCBXr1FXSfg/Yr0GgpGNA/HYZo01X8C+phElTv/PrrKhPe4BL0OVxGQb?=
 =?us-ascii?Q?xtmnrJgcDIZCLiNNu5LFysJM9bOCSRT1clM+J2BTfq4pPlcHp4uL5nPPdV7E?=
 =?us-ascii?Q?a20Eb5Fiv2sGAA5M13C98naK+WElOpEwUG+HPjcgAf0geC0/VSiOF9ubb8UB?=
 =?us-ascii?Q?bRvEHC9ngQSpZcifqZ936HgGxBH9hmcMjX2P5uPqLn0fqNqBtpp76x0EMNpB?=
 =?us-ascii?Q?yb13iH7XFNorSxBFvSqYzAT0B+u1kus9nzSk1BhsJVkvsJd45MVWQxy7fm4E?=
 =?us-ascii?Q?dX8wgLXkSybqq8xV/KvgogRPiZKEZerDwhaT3tHF67LEGKB+yzEun/2HVawI?=
 =?us-ascii?Q?IdOw9RFod7wHe9J2eIwG+CUrhTuBJrFl/6eaCxxt6gh4rxq4E3ozJG2J7zeQ?=
 =?us-ascii?Q?pvphbVe8ZKq84H4k5JbNzVDmarEqpSKxkuRV5qOYOMUK13hfyM100hpmuN70?=
 =?us-ascii?Q?4gmsC5NiJU0llpoJ4kZ8TrXJY0RhlUlY+7o1Uf7GgcI+Zj1SJvuE1xL9aSJm?=
 =?us-ascii?Q?nkJHswfMlJ3b+5EcM1rYksJ2aMywpiTIZ15bBLZB?=
X-MS-Exchange-CrossTenant-Network-Message-Id: e4b3ab60-46ec-4f97-a333-08dac3bf5686
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2022 08:32:59.9972
 (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: 5ccFgd5oJm9uqkEauj9Ac4ZHocn1Vw46RsU1glAdT/vl7uSqGo4ZfQ52vMNy2e9YLSMr7XDKjuxVAebb+ixx5A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4599
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,
        SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Nov 11, 2022 at 04:16:32PM +0800, Vlastimil Babka wrote:
> On 10/21/22 05:24, Feng Tang wrote:
> > kmalloc's API family is critical for mm, and one of its nature is that
> > it will round up the request size to a fixed one (mostly power of 2).
> > When user requests memory for '2^n + 1' bytes, actually 2^(n+1) bytes
> > could be allocated, so there is an extra space than what is originally
> > requested.
> > 
> > This patchset tries to extend the redzone sanity check to the extra
> > kmalloced buffer than requested, to better detect un-legitimate access
> > to it. (dependson SLAB_STORE_USER & SLAB_RED_ZONE)
> > 
> > The redzone part has been tested with code below:
> > 
> > 	for (shift = 3; shift <= 12; shift++) {
> > 		size = 1 << shift;
> > 		buf = kmalloc(size + 4, GFP_KERNEL);
> > 		/* We have 96, 196 kmalloc size, which is not power of 2 */
> > 		if (size == 64 || size == 128)
> > 			oob_size = 16;
> > 		else
> > 			oob_size = size - 4;
> > 		memset(buf + size + 4, 0xee, oob_size);
> > 		kfree(buf);
> > 	}
> 
> Sounds like a new slub_kunit test would be useful? :) doesn't need to be
> that exhaustive wrt all sizes, we could just pick one and check that a write
> beyond requested kmalloc size is detected?

Just git-grepped out slub_kunit.c :), will try to add a case to it.
I'll also check if the case will also be caught by other sanitizer
tools like kasan/kfence etc.

Thanks,
Feng


> Thanks!
>