Received: by 10.223.185.116 with SMTP id b49csp868145wrg; Wed, 21 Feb 2018 08:12:15 -0800 (PST) X-Google-Smtp-Source: AH8x227y1e5/8jKqepvnYxBiW/Dw4fCbPbNkxlfw9r++z1haGxCq2xY+lwt8zxYU9oF3F0tfHrZ7 X-Received: by 2002:a17:902:22e:: with SMTP id 43-v6mr3636162plc.384.1519229534886; Wed, 21 Feb 2018 08:12:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519229534; cv=none; d=google.com; s=arc-20160816; b=bwofpiR6Ir0NDzMppzUyBvLVJrRygCclCNg33ypyDLwi39JvnvO0gDfzqK3zi7sioY d0AxdE1V7iwX6K2pQUbHnPAepH3gZXEsY9SIOe9gExZCFoSYP09bwDP8D8KWWyCDd/Mn 0tknYdpbkgJ8VJrYUbII7XghlaQ/60KzFvwRvag2k/77/s9+/+ttU6Usf4plf2l+sCZJ 5mYwzUl9/aX/HmxjmLePwm3RjFGgu6RgBc82v+MRwnAde7fS/id9BABWApmw/QYqNedd MB5iljBRsjuto1bGuUERX+fzdvGPmJ7pBP/Bgde5NLucy+C4B5RJ7JuDgIs7Pqefjq0i gm4Q== 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=yakjMHftaJ212JGnh28tBwNpoBQjuv1WK33zBfCC3Dg=; b=oBrZMdlt9oMEWD7L2OBePBAtAk+SJsEmK6Pl5YkwDCxBiKpBykfz2p38C4c+Hg5/Oo mtbFC/8RjigeQ+s12oOKc6hCJXYcTtJ+hqV7KzEgM20gREWTLubwnyscvRNp4NIDa2jg pkcGlkbTZmX3RTltfygwrxTZH9Vg4rvOcJrAvlx06q8IDsnnSVT7qr06/gWCZIf0ZyNV 69cAVWkVCZRaB8KB44zRMh/TQudlgNy1vT2ag6UNX0/z8zfJRKh1PSbF9zo93GEBbPWb XMXKQ1nhj+GzSON4yDshaRJfk7Cp/sGxtNj88C6vVkfgHQQHztpW3/PDNot0cpocXNPQ XCsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vaHK6dEh; 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 z5si1211182pgp.262.2018.02.21.08.11.47; Wed, 21 Feb 2018 08:12:14 -0800 (PST) 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=vaHK6dEh; 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 S933120AbeBUK2O (ORCPT + 99 others); Wed, 21 Feb 2018 05:28:14 -0500 Received: from mail-wr0-f195.google.com ([209.85.128.195]:42175 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933055AbeBUK1S (ORCPT ); Wed, 21 Feb 2018 05:27:18 -0500 Received: by mail-wr0-f195.google.com with SMTP id k9so2939903wre.9 for ; Wed, 21 Feb 2018 02:27:17 -0800 (PST) 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=yakjMHftaJ212JGnh28tBwNpoBQjuv1WK33zBfCC3Dg=; b=vaHK6dEheBhrDBLiuINp2RevUagtygPGGU/PsMBj0IXq4K8XgwV7KFc7PUPiossaH0 Rt0dGGxZAJfYyS3lfQc9rKAhbZn/72mefO67rFzPg9b1Kz82kOVANj90maEFYDvuZoaW /37zcXgDRWzq5iT7Tfx43kyK1piL5TwHB5EFz8ywwPn3jB56nlwXGaZDeXrnpedrdy3l bv21DS2AkFl3d25bFoQ0uTQDFoaH7KjKYTRoEESeDj/fw4be/wqypwlXdK0gmVVOUpXl IsOwGSxQbNvOfW20xgKjlxRLWV5Kpq9zKprkDM/3qeGKalX4dqLqu4I6OscZjIPg9/hl Ve/Q== 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=yakjMHftaJ212JGnh28tBwNpoBQjuv1WK33zBfCC3Dg=; b=KcewpaAAOCw3P9ComG0O3L7HdjAmY4DArAiH0/fYev+PMTl9vEzf7VtDq97Z6x4HUZ C48wVayl9Zr0jMdGkXOPXRPxoi6lmEyeYDpk01FBkmz//9uHm6XW4IFY0xTFAt0S8uX/ uHTOvi+eZ94UxYT5emYMo8F3VSTD6LGdimjKMi7PR3AU9ohMf6+CYQZfoK0XYaDydKPI Z2eqN2henHFvSMGKQtBnzD0poLyEk6UMBkaY9afw7733RIcfMiFrgH3j6sdAAaLhzH4x WdSXoqQBO23SuPCUNpRy0UaiftZmFZAoclFIfL+5rQa1onLJIilqFYg13pMpzFyle7jD hI0g== X-Gm-Message-State: APf1xPA0YeEkROQyc4r67wY1Q/a0I4bk0rOPJL5RiznsM9oQ1bTnNuFe 5DrQI/vTWlu/nxYl4QaogMKAgKZZXsl3AgbqGMADfg== X-Received: by 10.223.208.132 with SMTP id y4mr2362842wrh.185.1519208836507; Wed, 21 Feb 2018 02:27:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.122.9 with HTTP; Wed, 21 Feb 2018 02:26:55 -0800 (PST) In-Reply-To: <20180214085425.GA12779@kroah.com> References: <1518168340-9392-1-git-send-email-joro@8bytes.org> <20180209191112.55zyjf4njum75brd@suse.de> <20180210091543.ynypx4y3koz44g7y@angband.pl> <20180211105909.53bv5q363u7jgrsc@angband.pl> <6FB16384-7597-474E-91A1-1AF09201CEAC@gmail.com> <20180213085429.GB10278@kroah.com> <20180214085425.GA12779@kroah.com> From: Lorenzo Colitti Date: Wed, 21 Feb 2018 19:26:55 +0900 Message-ID: Subject: Re: [PATCH 00/31 v2] PTI support for x86_32 To: Greg KH Cc: Linus Torvalds , Mark D Rustad , Adam Borowski , Joerg Roedel , Andy Lutomirski , Joerg Roedel , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , X86 ML , LKML , Linux-MM , Dave Hansen , Josh Poimboeuf , Juergen Gross , Peter Zijlstra , Borislav Petkov , Jiri Kosina , Boris Ostrovsky , Brian Gerst , David Laight , Denys Vlasenko , Eduardo Valentin , Will Deacon , "Liguori, Anthony" , Daniel Gruss , Hugh Dickins , Kees Cook , Andrea Arcangeli , Waiman Long , Pavel Machek , Florian Westphal Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 14, 2018 at 5:54 PM, Greg KH wrote: > > > IPSEC doesn't work with a 64bit kernel and 32bit userspace right now. > > > > > > Back in 2015 someone started to work on that, and properly marked that > > > the kernel could not handle this with commit 74005991b78a ("xfrm: Do not > > > parse 32bits compiled xfrm netlink msg on 64bits host") > > > > > > This is starting to be hit by some Android systems that are moving > > > (yeah, slowly) to 4.4 :( > > > > Does anybody have test-programs/harnesses for this? > > Lorenzo (now on the To: line), is the one that I think is looking into > this, and should have some sort of test for it. Lorenzo? Sorry for the late reply here. The issue is that the xfrm uapi structs don't specify padding at the end, so they're a different size on 32-bit and 64-bit archs. This by itself would be fine, as the kernel could just ignore the (lack of) padding. But some of these structs contain others (e.g., xfrm_userspi_info contains xfrm_usersa_info), and in that case the whole layout after the contained struct is different. On another thread Florian pointed out that he once wrote a patch to fix this - https://patchwork.ozlabs.org/patch/45855/ . Florian, think you could revive that?