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:   Thu, 10 Nov 2022 15:54:37 +0800
From:   Feng Tang <feng.tang@intel.com>
To:     Vlastimil Babka <vbabka@suse.cz>
CC:     Theodore Ts'o <tytso@mit.edu>,
        Aaro Koskinen <aaro.koskinen@iki.fi>,
        "Torvalds, Linus" <torvalds@linux-foundation.org>,
        Paul Cercueil <paul@crapouillou.net>,
        "42.hyeyoo@gmail.com" <42.hyeyoo@gmail.com>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "catalin.marinas@arm.com" <catalin.marinas@arm.com>,
        "cl@linux.com" <cl@linux.com>,
        "iamjoonsoo.kim@lge.com" <iamjoonsoo.kim@lge.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "penberg@kernel.org" <penberg@kernel.org>,
        "rientjes@google.com" <rientjes@google.com>,
        "rkovhaev@gmail.com" <rkovhaev@gmail.com>,
        "roman.gushchin@linux.dev" <roman.gushchin@linux.dev>,
        "willy@infradead.org" <willy@infradead.org>
Subject: Re: Deprecating and removing SLOB
Message-ID: <Y2yuPUxruFuJN+qM@feng-clx>
References: <K5M3LR.3O50LSSSY5L3@crapouillou.net>
 <CAHk-=wjBqwJk9RgfoBuM00T49M7uQiLnOvLST7L6v5rhS7fkDA@mail.gmail.com>
 <20221109234832.GE307514@darkstar.musicnaut.iki.fi>
 <Y2yArTbOpKd6ASkd@mit.edu>
 <e610b6fa-aa71-d612-0eb2-03ba6c4a6b46@suse.cz>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <e610b6fa-aa71-d612-0eb2-03ba6c4a6b46@suse.cz>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?CgkQtbxNqE9tb3FSntt+/4ReAfyI8fArdHJBamG149TqDHNMKPGTmTK6CzAU?=
 =?us-ascii?Q?/ZRBjsS6En+l5KGjOr2JDkQbhQ9s7+Ij6avObZZKbwCOrIfFwUf7xdnZ8YRk?=
 =?us-ascii?Q?JvZbPAgy8IOXQ76Cdto4PYyWOr8+l5/6hG+jYxHAGYHgjqZUU+Yjxnr+3Sfz?=
 =?us-ascii?Q?6FAZCgkcEXu25yzccnuwpJn6OO1vSCvM2RMBX5g3ltAVYS+IRsHEfqWUHlns?=
 =?us-ascii?Q?dbsRtPb8QRiG+dH9TLusXmV0I8Qjyic5KnfYG+yvEaFENTx8KKXZgM+IgAwO?=
 =?us-ascii?Q?rApzkJVkt3kBmfH6mQWak8eoB5QDYuW+CtSLvSRvr8CB0NaX+zxuI0RGoBZV?=
 =?us-ascii?Q?YEexOt7164Zef5heqMJl55IeTsWTcCr5/2YoYaLAckLGVTog31k8B/r85n+r?=
 =?us-ascii?Q?PJoxwujomOMhvj3SJEUfKymq2FglrKjeUTeKIqoloKryyvPJ7yacRKbDcDe6?=
 =?us-ascii?Q?2RnBnd8k2htbSKJtWU026L7CHe8idGPzznWZXr/zUXn61+c61pFaI6ZuSgB6?=
 =?us-ascii?Q?NVfP6o5eiciWgdAtH+LNJTCvsb8r6CI1WE5zOGhzuusOL0J51LPTN2jcnUvH?=
 =?us-ascii?Q?53xK6zYNLv3uxBp1dgcVkrheqcEgM6mN5bBXB/FbQmy9NrvJVfXDUDO0Feer?=
 =?us-ascii?Q?mwv8iyLbTFsbvmrBsMl++8iVUTPpDRi2EGYTIkTcOYalBYt0Zf6XgBGFPFfB?=
 =?us-ascii?Q?KzacUa1IwGtI5K4/+5Vhv4qxen9qBjpG+SUPXAA7hTlaAJjUcTHK+vdW99DI?=
 =?us-ascii?Q?pFOU0V1hN3SEASkvs8rlaVZloPR+d7b5OVtC23U5deo0bTVqHuKO5PzGJ1Rg?=
 =?us-ascii?Q?QQIk3Y9BcG3k4VGK7PMYrTWB/jYpfB47VlAGjlKqHINQDesjojw7c8grTQi3?=
 =?us-ascii?Q?1ukDrATLlPfMlnxL0qsh8A0tVikwUSSZbjbaIgAweU8nHdCe4VV64XL3yGz/?=
 =?us-ascii?Q?6s7LeCecnM/sdJM0jnwymU3mcL0cLbKoIrJepUoSLva90ME815+XFrE578xv?=
 =?us-ascii?Q?bvvY+Ib3T3wELHoJSWhnm0XT1VX06DVWtRstV25OGk8VxHzL8R3yHr6kQQMi?=
 =?us-ascii?Q?QdlYfQSw3WRMjmTZ0ILbjYD/vvd0vwhAn7YMmT/ufeZaTLhqyk3I71sfBIeQ?=
 =?us-ascii?Q?vnR726v0j8djE43mMNhxg/DA+gzheQDIp/pnqaxIlGsPavZj1yR79A5gIBD3?=
 =?us-ascii?Q?kHKlULkzSbTqiaVfyWrtuNZVKrLNUqOptch2rlrVUpKInXd4Halp6HY0jFea?=
 =?us-ascii?Q?7ZzZDN+mhTkgWdR9Oz49d7mMniZri1B4EN1d3csIJGMnEQDCyadb/dhuWwTH?=
 =?us-ascii?Q?od3Nj9KWamCxo8DRCzFvxr0XZ5FWOqwvgw1SiD2y+cuCJ9pkGi8fA1N+XFlQ?=
 =?us-ascii?Q?FeNBF1mAzYwR2MQWy33ol1eIf6HQ4CNYyhcdv32dRQBokCYO4JTAL3NQ0RkM?=
 =?us-ascii?Q?kpAEu7N2R1FItPDZvioWEyJbx9EQU3Scoqp4tnehoJWTevhzBrhBsEuzpszY?=
 =?us-ascii?Q?P0nReYMGXYelxI2b1An2a/UOsH+2LMSftJm70eegm2VEakGCzlhW39jI9J8N?=
 =?us-ascii?Q?kCqmHNpXUofpqZtwWJaqABG4jjOVyTNAhmLr5YvG?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 09c39f3a-d199-407d-db56-08dac2f14555
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2022 07:57:53.4225
 (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: 6UpR45n3p/L7Se1LvWY8/xS0PAq3bR/N6veO1od5SzGLGPLRDGG/U32ogrWdSR+EB4e/i7lw1msL9EpFoB+3QQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR11MB5787
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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 Thu, Nov 10, 2022 at 03:31:31PM +0800, Vlastimil Babka wrote:
> On 11/10/22 05:40, Theodore Ts'o wrote:
> > On Thu, Nov 10, 2022 at 01:48:32AM +0200, Aaro Koskinen wrote:
> >> 
> >> Some of the reported SLOB issues have been actually real driver bugs,
> >> that go unnoticed when SLUB/SLAB are used (unless perhaps debug stuff
> >> is enabled). I'm not saying kernel should keep SLOB, but it's good at
> >> failing early when there is a bug. See e.g. commit 120ee599b5bf ("staging:
> >> octeon-usb: prevent memory corruption")
> > 
> > Out of curiosity, are these bugs that would have been found using
> > KASAN or some of the other kernel sanitizers and/or other debugging
> > tools we have at our disposal?
> 
> Hopefully slub_debug redzoning would be able to trigger the bug described in
> commit 120ee599b5bf above, which is:
> 
> >     octeon-hcd will crash the kernel when SLOB is used. This usually happens
> >     after the 18-byte control transfer when a device descriptor is read.
> >     The DMA engine is always transfering full 32-bit words and if the
> >     transfer is shorter, some random garbage appears after the buffer.
> >     The problem is not visible with SLUB since it rounds up the allocations
> >     to word boundary, and the extra bytes will go undetected.
> 
> Ah, actually it wouldn't *now* as SLUB would make the allocation fall into
> kmalloc-32 cache and only add redzone beyond 32 bytes. But with upcoming
> changes by Feng Tang, this should work.
 
I wrote a simple case trying simulating this:

	static noinline void dma_align_test(void)
	{
		char *buf;

		buf = kmalloc(18, GFP_KERNEL);
		buf[18] = 0;
		buf[19] = 0;
		kfree(buf);
	}

And with slub_debug on and the slub_redzone patchset[1], it did
catch the out-of-bound access, as in the dmesg:

"
 =============================================================================
 BUG kmalloc-32 (Not tainted): kmalloc Redzone overwritten
 -----------------------------------------------------------------------------

 0xffff888005ebb032-0xffff888005ebb033 @offset=50. First byte 0x0 instead of 0xcc
 Allocated in dma_align_test+0x1b/0x29 age=6554 cpu=1 pid=1
  __kmem_cache_alloc_node+0x2a7/0x320
  kmalloc_trace+0x27/0xa0
  dma_align_test+0x1b/0x29
  late_slub_debug+0xa/0x11
  do_one_initcall+0x87/0x2a0
  ...

 Slab 0xffffea000017aec0 objects=21 used=19 fp=0xffff888005ebbf20 flags=0xfffffc0000200(slab|node=0|zone=1|lastcpupid=0x1fffff)
 Object 0xffff888005ebb020 @offset=32 fp=0x0000000000000000

 Redzone  ffff888005ebb000: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
 Redzone  ffff888005ebb010: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
 Object   ffff888005ebb020: 50 92 28 00 81 88 ff ff 01 00 00 00 11 00 b6 07  P.(.............
 Object   ffff888005ebb030: 6b a5 00 00 cc cc cc cc cc cc cc cc cc cc cc cc  k...............
 Redzone  ffff888005ebb040: cc cc cc cc cc cc cc cc                          ........
 Padding  ffff888005ebb0a4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
 Padding  ffff888005ebb0b4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a              ZZZZZZZZZZZZ
"

[1]. https://lore.kernel.org/lkml/20221021032405.1825078-1-feng.tang@intel.com/ 

Thanks,
Feng

> slub_debug would also have a chance of catching buffer overflows by kernel
> code itself, not DMA, and tell you about it more sooner and gracefully than
> crashing. KASAN also, even with a higher chance and precision, if it's
> available for your arch and your device constraints can tolerate its larger
> overhead.
> 
> >        		      	    	      	    	 - Ted
> > 
> > 						 
> 
>