From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH bpf-next v2 4/8] tls: convert to generic sk_msg interface Date: Wed, 17 Oct 2018 07:55:37 -0700 Message-ID: <4b403534-2273-5931-753b-c16a6e2624a0@gmail.com> References: <20181013004603.3747-1-daniel@iogearbox.net> <20181013004603.3747-5-daniel@iogearbox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: john.fastabend@gmail.com, davejwatson@fb.com, netdev@vger.kernel.org To: Daniel Borkmann , alexei.starovoitov@gmail.com Return-path: Received: from mail-pg1-f193.google.com ([209.85.215.193]:41974 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727000AbeJQWvo (ORCPT ); Wed, 17 Oct 2018 18:51:44 -0400 Received: by mail-pg1-f193.google.com with SMTP id 23-v6so12654473pgc.8 for ; Wed, 17 Oct 2018 07:55:39 -0700 (PDT) In-Reply-To: <20181013004603.3747-5-daniel@iogearbox.net> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 10/12/2018 05:45 PM, Daniel Borkmann wrote: > Convert kTLS over to make use of sk_msg interface for plaintext and > encrypted scattergather data, so it reuses all the sk_msg helpers > and data structure which later on in a second step enables to glue > this to BPF. > > This also allows to remove quite a bit of open coded helpers which > are covered by the sk_msg API. Recent changes in kTLs 80ece6a03aaf > ("tls: Remove redundant vars from tls record structure") and > 4e6d47206c32 ("tls: Add support for inplace records encryption") > changed the data path handling a bit; while we've kept the latter > optimization intact, we had to undo the former change to better > fit the sk_msg model, hence the sg_aead_in and sg_aead_out have > been brought back and are linked into the sk_msg sgs. Now the kTLS > record contains a msg_plaintext and msg_encrypted sk_msg each. > > In the original code, the zerocopy_from_iter() has been used out > of TX but also RX path. For the strparser skb-based RX path, > we've left the zerocopy_from_iter() in decrypt_internal() mostly > untouched, meaning it has been moved into tls_setup_from_iter() > with charging logic removed (as not used from RX). Given RX path > is not based on sk_msg objects, we haven't pursued setting up a > dummy sk_msg to call into sk_msg_zerocopy_from_iter(), but it > could be an option to prusue in a later step. > > Joint work with John. > > Something looks broken and needs this fix : (I have to run, I might submit this formally later if needed) diff --git a/net/core/sock_map.c b/net/core/sock_map.c index 3c0e44cb811a4bed2e02aa107854d74eb3ae7358..3e55dedc038b22132b5b6d042bfedda9e4f3157e 100644 --- a/net/core/sock_map.c +++ b/net/core/sock_map.c @@ -175,12 +175,12 @@ static int sock_map_link(struct bpf_map *map, struct sk_psock_progs *progs, } } + if (!sk_has_psock(sk)) { + ret = -EBUSY; + goto out_progs; + } psock = sk_psock_get(sk); if (psock) { - if (!sk_has_psock(sk)) { - ret = -EBUSY; - goto out_progs; - } if ((msg_parser && READ_ONCE(psock->progs.msg_parser)) || (skb_progs && READ_ONCE(psock->progs.skb_parser))) { sk_psock_put(sk, psock); BUG: KASAN: slab-out-of-bounds in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline] BUG: KASAN: slab-out-of-bounds in refcount_inc_not_zero_checked+0x97/0x2f0 lib/refcount.c:120 Read of size 4 at addr ffff88019548be58 by task syz-executor4/22387 CPU: 1 PID: 22387 Comm: syz-executor4 Not tainted 4.19.0-rc7+ #264 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113 print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267 kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272 atomic_read include/asm-generic/atomic-instrumented.h:21 [inline] refcount_inc_not_zero_checked+0x97/0x2f0 lib/refcount.c:120 sk_psock_get include/linux/skmsg.h:379 [inline] sock_map_link.isra.6+0x41f/0xe30 net/core/sock_map.c:178 sock_hash_update_common+0x19b/0x11e0 net/core/sock_map.c:669 sock_hash_update_elem+0x306/0x470 net/core/sock_map.c:738 map_update_elem+0x819/0xdf0 kernel/bpf/syscall.c:818 __do_sys_bpf kernel/bpf/syscall.c:2400 [inline] __se_sys_bpf kernel/bpf/syscall.c:2371 [inline] __x64_sys_bpf+0x32d/0x510 kernel/bpf/syscall.c:2371 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457569 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f71507e0c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457569 RDX: 0000000000000020 RSI: 0000000020000180 RDI: 0000000000000002 RBP: 000000000072bf00 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f71507e16d4 R13: 00000000004bd926 R14: 00000000004cc2b0 R15: 00000000ffffffff Allocated by task 22387: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x730 mm/slab.c:3554 kmem_cache_zalloc include/linux/slab.h:697 [inline] kcm_attach net/kcm/kcmsock.c:1405 [inline] kcm_attach_ioctl net/kcm/kcmsock.c:1490 [inline] kcm_ioctl+0xca7/0x18c0 net/kcm/kcmsock.c:1696 sock_do_ioctl+0xeb/0x420 net/socket.c:950 sock_ioctl+0x313/0x690 net/socket.c:1074 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:501 [inline] do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702 __do_sys_ioctl fs/ioctl.c:709 [inline] __se_sys_ioctl fs/ioctl.c:707 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 0: (stack is not available) The buggy address belongs to the object at ffff88019548bc00 which belongs to the cache kcm_psock_cache of size 544 The buggy address is located 56 bytes to the right of 544-byte region [ffff88019548bc00, ffff88019548be20) The buggy address belongs to the page: page:ffffea0006552280 count:1 mapcount:0 mapping:ffff8801cb789b40 index:0x0 compound_mapcount: 0 flags: 0x2fffc0000008100(slab|head) raw: 02fffc0000008100 ffff8801cb78c748 ffff8801cb78c748 ffff8801cb789b40 kobject: 'loop2' (0000000086df2c8c): kobject_uevent_env raw: 0000000000000000 ffff88019548a080 000000010000000b 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88019548bd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88019548bd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88019548be00: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88019548be80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88019548bf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ==================================================================