Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1042400imm; Fri, 27 Jul 2018 10:11:02 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfOGFyvLvYaI3EqVCRJVymp1ANnBT/aQ4LYVeV1mz5ef4LjgqpDDBLzYcWElkPhn1OsGpBn X-Received: by 2002:a17:902:7488:: with SMTP id h8-v6mr6843897pll.41.1532711462617; Fri, 27 Jul 2018 10:11:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532711462; cv=none; d=google.com; s=arc-20160816; b=CLwx1AJC+Ez+yHzTcdJ6Tx1LyTyuFzRuf7UMvQ1DD+BkIh5TjyiaC/MsiAJ2XKoi25 re6GNLVKqR42nSlwAwjngnuzdTlMLluvf0wUojur8Aa8tloL9QNVRAUq2IHXJCMhpLgl GMrtfxNEayhAt53rMX3CtuaSao5YGT9dzf/NHRNz9iG9JUNM0h++DgtMWFbe+Ruu8TCX xJNCybHuCWg+CrMTZGBzscIEXvwg3/PMOdAdEbL+G7aW7NCgcJ3q1KsPf4mT20LgzqKM E1QUVYulx32obbnQm0UXTb8wFicEzTvQuSR2t1uadQDN7iO6XL9uGlcqnyqfxwZjtwVz gdaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature:arc-authentication-results; bh=cidM5KL9Jm8E8UXl4q+7OgY+aMHpq5Dbay+tap3AKu4=; b=TF5V68qI3+WR4FRYQe+egj4CSO3/u5XlU7HAiJJpywzRXntgnv8Re8HR5kWFv6lPX2 kSo0mnO2gfvgvn4c+Hrq75n+vwtw4w6Vh6BlTrP2ohuv9Bjg9ytW83snIjrjkp7RJaVd N4OSxSXBRhbHe6JLJ3yFzAeuxFe9tiFYFUoHbcyf8bAACl3tE/TLyeQRphPCh3u+5YeL dDkOZ7z6ABlhHp/BH50eb266i8s9tPnfGTxbO5nAa5wuYStKpVa5p/B2sSwMDmhbmgJY 47kPUQtyP+Z80dEnu87IWCHPVvrNZo749fGMfmqgYHm+81T0LqfXzDpUi/h3uCT/VJs/ LtMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=cyKCb4UZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w61-v6si3843919plb.502.2018.07.27.10.10.46; Fri, 27 Jul 2018 10:11:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=cyKCb4UZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388621AbeG0Scp (ORCPT + 99 others); Fri, 27 Jul 2018 14:32:45 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:33122 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730636AbeG0Sco (ORCPT ); Fri, 27 Jul 2018 14:32:44 -0400 Received: by mail-pg1-f193.google.com with SMTP id r5-v6so3596046pgv.0 for ; Fri, 27 Jul 2018 10:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cidM5KL9Jm8E8UXl4q+7OgY+aMHpq5Dbay+tap3AKu4=; b=cyKCb4UZRXGK75FImH5dYd867JNgv4GhYSwKCcp4wCEJzt/eYCEw+hQQZtkSoeZ2oa veyOVnJXyYdaXSKlIhmecIpiM76No0Q5pZ2HGBWOwyEvPFaLjvN6ylBziGhkpELSUFtl AycbPkDDuRZ2EXa+tm/c2VsEa4xY+HCLjxbfk1IT2hhZCF9JaIRoMWrEPYHm7wPSNBEW R+y8m2iQ3dktb7dYuybw6nOM5bpzqJtBcnOXiTKMuE8szqLDnqM7h5mE7dRC/A5LsLug qqMaIsXpUnFqn1JYFVdCt/Rs38E0jpmQzb8R7Dk1HYk7iSqQcuQi4RjaVm/yBc0TSQUY zXrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cidM5KL9Jm8E8UXl4q+7OgY+aMHpq5Dbay+tap3AKu4=; b=EMweKr0XtoxCI56Wl2jtuntO50r/MML7Xnr0upAX4bYQs2aSLO+9XJ4Ol6RTBrHt6c XLN+fGa6iA+2vRP5qzq8Iz6yUX5ksiEhHiZ0IENzRgjV9o7Z3PaqM09xP/37b4lbpnos YAwbep4RaCoRw8cFvh/t7wPHAxzHDo1pV/m2FUvNiMi+/fdGb/Jk8AAv8vLJucKQMXzn O+/lh9AAmx44unwHpyIbhV9gvIPdv7iwmN4NoOGbTup6DKw9UHYk4uirbA1umOMopNoV yUiQNMnazBLY1Laog+oKqLI1nGu1RN3hRZVA3PJVmb5rsSaEw8avKKseO/D+QRnQkc/M DoXA== X-Gm-Message-State: AOUpUlFSq0ceH9iss17OUYw8RQJB9DLLBLoUgUkWliGRz4NSZ+vAecyo G11p+TwlY3TOgEGBNCA6KcCa0g== X-Received: by 2002:a63:7a0a:: with SMTP id v10-v6mr6781963pgc.444.1532711396312; Fri, 27 Jul 2018 10:09:56 -0700 (PDT) Received: from ?IPv6:2600:1010:b06a:2e73:757d:193d:fa1:53d4? ([2600:1010:b06a:2e73:757d:193d:fa1:53d4]) by smtp.gmail.com with ESMTPSA id x2-v6sm11298309pfi.166.2018.07.27.10.09.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jul 2018 10:09:54 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-F0CF300A-221A-4558-94AF-78ADCD92F052 Mime-Version: 1.0 (1.0) Subject: Re: [PATCH 00/18] xfrm: Add compat layer From: Andy Lutomirski X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Fri, 27 Jul 2018 10:09:50 -0700 Cc: Dmitry Safonov , Florian Westphal , Steffen Klassert , linux-kernel@vger.kernel.org, "David S. Miller" , Herbert Xu , Dmitry Safonov <0x7f454c46@gmail.com>, netdev@vger.kernel.org, Andy Lutomirski , Ard Biesheuvel , "H. Peter Anvin" , Ingo Molnar , John Stultz , "Kirill A. Shutemov" , Oleg Nesterov , Stephen Boyd , Steven Rostedt , Thomas Gleixner , x86@kernel.org, linux-efi@vger.kernel.org, Andrew Morton , Greg Kroah-Hartman , Mauro Carvalho Chehab , Shuah Khan , linux-kselftest@vger.kernel.org, Eric Paris , Jozsef Kadlecsik , Pablo Neira Ayuso , Paul Moore , coreteam@netfilter.org, linux-audit@redhat.com, netfilter-devel@vger.kernel.org, Fan Du Content-Transfer-Encoding: 7bit Message-Id: <9907339A-4CBE-4F5C-88CB-A1C6DBCB4CED@amacapital.net> References: <20180726023144.31066-1-dima@arista.com> <20180726084959.pzjvflfjq6a76du6@breakpoint.cc> <20180727073747.h27dtojlnmc3k25v@gauss3.secunet.de> <1532700173.2679.18.camel@arista.com> <20180727141936.uze6ohordx7ue3no@breakpoint.cc> <1532703111.2679.20.camel@arista.com> To: Nathan Harold Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Apple-Mail-F0CF300A-221A-4558-94AF-78ADCD92F052 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jul 27, 2018, at 9:48 AM, Nathan Harold wrote: >=20 > We (Android) are very interested in removing the restriction for 32-bit us= erspace processes accessing xfrm netlink on 64-bit kernels. IPsec support is= required to pass Android conformance tests, and any manufacturer wishing to= ship 32-bit userspace with a recent kernel needs out-of-tree changes (remov= ing the compat_task check) to do so. >=20 > That said, it=E2=80=99s not difficult to work around alignment issues dire= ctly in userspace, so maybe we could just remove the check and make this the= caller's responsibility? Here=E2=80=99s an example of the workaround curren= tly in the Android tree: > https://android.googlesource.com/platform/system/netd/+/refs/heads/master/= server/XfrmController.h#257 >=20 > We could also employ a (relatively simple) solution such as the one above i= n the uapi XFRM header itself, though it would require a caller to declare t= he target kernel ABI at compile time. Maybe that=E2=80=99s not unthinkable f= or an uncommon case? >=20 Could there just be an XFRM2 that is entirely identical to XFRM for 64-bit u= serspace but makes the 32-bit structures match? If there are a grand total o= f two or so userspace implementations, that should cover most use cases. L > -Nathan >=20 >=20 >> On Fri, Jul 27, 2018 at 7:51 AM, Dmitry Safonov wrote: >> On Fri, 2018-07-27 at 16:19 +0200, Florian Westphal wrote: >> > Dmitry Safonov wrote: >> > > 1. It will double copy netlink messages, making it O(n) instead of >> > > O(1), where n - is number of bind()s.. Probably we don't care much. >> >=20 >> > About those bind() patches, I don't understand why they are needed. >> >=20 >> > Why can't you just add the compat skb to the native skb when doing >> > the multicast call? >> >=20 >> > skb_shinfo(skb)->frag_list =3D compat_skb; >> > xfrm_nlmsg_multicast(net, skb, 0, ... >>=20 >> Oh yeah, sorry, I think I misread the patch - will try to add compat >> skb in the multicast call. >>=20 >> --=20 >> Thanks, >> Dmitry >=20 --Apple-Mail-F0CF300A-221A-4558-94AF-78ADCD92F052 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Jul 27, 2018, at 9:48 AM, N= athan Harold <nharold@google.com> wrote:

We (Android) are very interested in removing the restriction for 32= -bit userspace processes accessing xfrm netlink on 64-bit kernels. IPsec sup= port is required to pass Android conformance tests, and any manufacturer wis= hing to ship 32-bit userspace with a recent kernel needs out-of-tree changes= (removing the compat_task check) to do so.


That said, it=E2=80=99s not diff= icult to work around alignment issues directly in userspace, so maybe we cou= ld just remove the check and make this the caller's responsibility? Here=E2=80= =99s an example of the workaround currently in the Android tree:

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">https://andro= id.googlesource.com/platform/system/netd/+/refs/heads/master/server/XfrmCont= roller.h#257


We could also employ a (relatively simple) solution such as= the one above in the uapi XFRM header itself, though it would require a cal= ler to declare the target kernel ABI at compile time. Maybe that=E2=80=99s n= ot unthinkable for an uncommon case?



Could there just be an XFRM2 that is entirely identi= cal to XFRM for 64-bit userspace but makes the 32-bit structures match? &nbs= p;If there are a grand total of two or so userspace implementations, that sh= ould cover most use cases. L

= --Apple-Mail-F0CF300A-221A-4558-94AF-78ADCD92F052--