Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1024994imm; Fri, 27 Jul 2018 09:57:00 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfW+PR2HLo/GECWW/NFm/UJWGszPodo2Nrqiw+H2CVvt39PEHtRU33scXI/aEtEKuPlICd6 X-Received: by 2002:a63:9311:: with SMTP id b17-v6mr6853400pge.261.1532710620320; Fri, 27 Jul 2018 09:57:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532710620; cv=none; d=google.com; s=arc-20160816; b=xQjH1j3gFZIff/GiXHxzTrEe3KXU9G/wHcKmMf/2ZZnrO1Gy36gUeDnM4ShfK34T0p PamdJSeVQ8c745L69LKfzDGH3nCVLPfsaRCumfYrNa84EpglfTRFibkEPF3lFWTx8SA7 T5Wyn2PFi/QV7bDYBS6GniWemh0F56lklHsInwbheI69c5dLwQmActBTEvkhXdN90XyL ZLeB4v7qMKC3QQMHHj8YhjR6+COGXHsoCfXrw228OFQWYdKoEFxcEYZkD4QjLCAnFllG n8EkJX7/ocunLvJBXC7EysvBZ3NtaNEIDmBgHnnV9x3cut53wqQUBAMmZ4cG0YmQnjd+ WYkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=BlC9SuUVCoHFs5ky2qCIFQNyaNV4WkCAWEtDIEEhNPM=; b=DOaUSnYRnjE0l0qgBlhdkdqE/KbffLdG61tMc3Drng5nY+dBxYKeal84zpdi+nUwmI 1o+Dc7nmv7+fJLQri5R6vCWlRgpyDhcbeiXoXLcV3Jo/5Esyz545qEXoIS/XROaAGhWs 69eL3LJiMXqbHmUdoMwesrv17Jyj6bRFSBJf1vS1t0P+Ro9nnblbFb82/nopEOuJKw8H hsUoh0g+MqneBsoP/vLHsjLnDZnyl+Eg2BeliHFtd33RHasqlkQsSY6Sx9ogbtCG5bgp QTi743uQoAWdzkuBY4OQ8f6fzLAhQQW1eplPSkxX5Q3Il6V8qPWTLLVj6CZtKZLGh3ZX Kd+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=A8PhKaEO; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j124-v6si4668228pfb.191.2018.07.27.09.56.45; Fri, 27 Jul 2018 09:57:00 -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=@google.com header.s=20161025 header.b=A8PhKaEO; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388902AbeG0SSV (ORCPT + 99 others); Fri, 27 Jul 2018 14:18:21 -0400 Received: from mail-ua0-f193.google.com ([209.85.217.193]:33388 "EHLO mail-ua0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388760AbeG0SSV (ORCPT ); Fri, 27 Jul 2018 14:18:21 -0400 Received: by mail-ua0-f193.google.com with SMTP id i4-v6so3779517uak.0 for ; Fri, 27 Jul 2018 09:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BlC9SuUVCoHFs5ky2qCIFQNyaNV4WkCAWEtDIEEhNPM=; b=A8PhKaEOLa/JxkeoTbF09/3ZMmSX5v3XU8XAOffL/EgTltoWtCh3ElXJbouxPqshvP PbCtggbDMAQDpTaHKHzhAfyxBZwdOaEkfVoDkJPgmxHgXfc1V9+xVyaFyrqZpw+8556d XbrNNA6+tgGLbXA35hXJmB1j31CniTzXcIxIf/s2feaaOs9UA82JZvB+6dLE2EwAUVeb Zlzkno8ORZtA5RdkBYCdvp+97LL0lChjdFBU/Sl0Kk3bPOGUcdYpp5GMlbH77l1X5eNp d0iJY/plxLBrNck2Y20SnJZ8UxcTJqSfDEeRQcVJ34yzObyGy2S0o9TTNiCSx2Y/Sw5a rg8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BlC9SuUVCoHFs5ky2qCIFQNyaNV4WkCAWEtDIEEhNPM=; b=ZKsA9PfsBaPQrRj33oHOPTi7JH1G4d9MMu46bAfP2yS6xt4Wxev6Zs6N0DEF9a1qnO H62mST5ivKu9AfBIHGkUh1jmEDF2/h4CroQ9C73qwTnLfQUsgzrNPI2QdWuq4sAjdqy2 5dTAj3ZlpbyB4ST/CTFrYQ174/ovGRZHa8fSByN5lJFvt/FiLMBdP8/NqvEExmQIlrqh BDFT0XyhPcBTRaG1eLogPMEpBlfYg8jmKDum3d2e9uwt2zCWB69I3wK8cbpOV0gMpu7H W+su2XkR3TAkU1Hpz3wipchQkrUqG8llSSXWhNF5CJw+b2/d9iJYKn/6y4/A9Mnm3K0C rM5Q== X-Gm-Message-State: AOUpUlEofrXEM3Q6mcrRzGxrmbzOIwDkkPfHV2StItQLSdommdvDT90q pUux6DB+NgWE/g62uAZe//vIY3gpMsiJRY9EFSqS6w== X-Received: by 2002:a9f:3f8c:: with SMTP id k12-v6mr5161689uaj.38.1532710107313; Fri, 27 Jul 2018 09:48:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:638f:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 09:48:06 -0700 (PDT) In-Reply-To: <1532703111.2679.20.camel@arista.com> 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> From: Nathan Harold Date: Fri, 27 Jul 2018 09:48:06 -0700 Message-ID: Subject: Re: [PATCH 00/18] xfrm: Add compat layer To: Dmitry Safonov Cc: 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-Type: multipart/alternative; boundary="0000000000007e0a350571fde1eb" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --0000000000007e0a350571fde1eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *We (Android) are very interested in removing the restriction for 32-bit userspace 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 (removing the compat_task check) to do so.That said, it=E2=80=99s not diffi= cult to work around alignment issues directly 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 currently in the Android tree:https://android.googlesource.com/platform/system/netd/+/refs/heads/mas= ter/server/XfrmController.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 caller to declare the target kernel ABI at compile time. Maybe that=E2=80=99s not unthinkable= for an uncommon case?-Nathan* 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. > > > > About those bind() patches, I don't understand why they are needed. > > > > Why can't you just add the compat skb to the native skb when doing > > the multicast call? > > > > skb_shinfo(skb)->frag_list =3D compat_skb; > > xfrm_nlmsg_multicast(net, skb, 0, ... > > Oh yeah, sorry, I think I misread the patch - will try to add compat > skb in the multicast call. > > -- > Thanks, > Dmitry > --0000000000007e0a350571fde1eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

We (Android) are very interested in removi= ng the restriction for 32-bit userspace processes accessing xfrm netlink on= 64-bit kernels. IPsec support is required to pass Android conformance test= s, and any manufacturer wishing to ship 32-bit userspace with a recent kern= el needs out-of-tree changes (removing the compat_task check) to do so.


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 th= e caller's responsibility? Here=E2=80=99s an example of the workaround = currently in the Android tree:

https://android.googlesource.com/platfor= m/system/netd/+/refs/heads/master/server/XfrmController.h#257

We co= uld also employ a (relatively simple) solution such as the one above in the= uapi XFRM header itself, though it would require a caller to declare the t= arget kernel ABI at compile time. Maybe that=E2=80=99s not unthinkable for = an uncommon case?


-Nathan



On Fri, Jul 27, 2018 at 7:51 AM, Dmitr= y Safonov <dima@arista.com> wrote:
On Fri, 2018-07-27 at 16:1= 9 +0200, Florian Westphal wrote:
> Dmitry Safonov <dima@arista.com<= /a>> wrote:
> > 1. It will double copy netlink messages, making it O(n) instead o= f
> > O(1), where n - is number of bind()s.. Probably we don't care= much.
>
> About those bind() patches, I don't understand why they are needed= .
>
> Why can't you just add the compat skb to the native skb when doing=
> the multicast call?
>
> skb_shinfo(skb)->frag_list =3D compat_skb;
> xfrm_nlmsg_multicast(net, skb, 0, ...

Oh yeah, sorry, I think I misread the patch - will try to add c= ompat
skb in the multicast call.

--
Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dmitry

--0000000000007e0a350571fde1eb--