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;
From:   Song Liu <songliubraving@fb.com>
To:     "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
CC:     "rppt@kernel.org" <rppt@kernel.org>,
        "mcgrof@kernel.org" <mcgrof@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "bpf@vger.kernel.org" <bpf@vger.kernel.org>,
        "hch@infradead.org" <hch@infradead.org>,
        "ast@kernel.org" <ast@kernel.org>,
        "daniel@iogearbox.net" <daniel@iogearbox.net>,
        "Torvalds, Linus" <torvalds@linux-foundation.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "song@kernel.org" <song@kernel.org>,
        Kernel Team <Kernel-team@fb.com>,
        "pmladek@suse.com" <pmladek@suse.com>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "hpa@zytor.com" <hpa@zytor.com>,
        "dborkman@redhat.com" <dborkman@redhat.com>,
        "edumazet@google.com" <edumazet@google.com>,
        "bp@alien8.de" <bp@alien8.de>, "mbenes@suse.cz" <mbenes@suse.cz>,
        "imbrenda@linux.ibm.com" <imbrenda@linux.ibm.com>
Subject: Re: [PATCH v4 bpf 0/4] vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP
Thread-Topic: [PATCH v4 bpf 0/4] vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP
Thread-Index: AQHYUOjRr/eYt5HVI0ucQZg4JV/u/6zxVckAgACoe4CAAPedAIAACgKAgAAgN4CAAlYOAIAA9TuAgAAUC4CAAD2oAA==
Date:   Tue, 19 Apr 2022 05:36:45 +0000
Message-ID: <B20F8051-301C-4DE4-A646-8A714AF8450C@fb.com>
References: <20220415164413.2727220-1-song@kernel.org>
 <YlnCBqNWxSm3M3xB@bombadil.infradead.org> <YlpPW9SdCbZnLVog@infradead.org>
 <4AD023F9-FBCE-4C7C-A049-9292491408AA@fb.com>
 <CAHk-=wiMCndbBvGSmRVvsuHFWC6BArv-OEG2Lcasih=B=7bFNQ@mail.gmail.com>
 <B995F7EB-2019-4290-9C09-AE19C5BA3A70@fb.com> <Yl04LO/PfB3GocvU@kernel.org>
 <Yl4F4w5NY3v0icfx@bombadil.infradead.org>
 <88eafc9220d134d72db9eb381114432e71903022.camel@intel.com>
In-Reply-To: <88eafc9220d134d72db9eb381114432e71903022.camel@intel.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?CW6BkUZvkcB2IdC/dJ8LWffXG0aupWGJYf95KcFvPGt0unnmwFxaDoDhRd6x?=
 =?us-ascii?Q?72PoJYg+1zFM7P2yMRJvgWAI8IQiY8tMdEghu6P8t80ayjh3Ddngq74ROvO7?=
 =?us-ascii?Q?9O5QnFbeW7H4AIbZ8rS6TSBO/l89D1pmZoVfJyZWcYdHQntVSa4fCS87+eRH?=
 =?us-ascii?Q?DPRg/yUQLsdwBa2mqbU9IAJWdKa7rZjG0mdoM1rJqTyzgjqm+kMYvrm6Vxs/?=
 =?us-ascii?Q?JON9wsM+ZdbujI3Iqvcc5w35+f5wdjTFUMN3uUW0YLYe0q076fzncWzfF7En?=
 =?us-ascii?Q?FL9YXX7XyHkjD3KhOtYe9e3LYwy0/REpTN2r9Xo+wYMBMJLAwTX0z9FidnSw?=
 =?us-ascii?Q?Lv3/ks1Djiyd9GP7HhKYghPu+AvokvKfvXTkgSu/tMkPZfKwlelUUVAu2OWE?=
 =?us-ascii?Q?YFGQ+9DgsTF8ZAYM+0zDi4KSHwpNRQHRrKTE9b8o1YklmRt8Jrn7q1feVsVu?=
 =?us-ascii?Q?YHP3OG0ppSLUNccJd1XGO0KSTnbBQhUXJhmTKi2ckp2YG17t1WLmUauA74di?=
 =?us-ascii?Q?BDdS0VFTmjrxFAW2XQ8P9p7S9BLG4266XkA6PoEJFJnHNZNBrJnmQpWGI6QH?=
 =?us-ascii?Q?RTjWrODCOqALWIhokDmMZHqs+PFVspHkW30U4PWExYz6GK5nR/fXGHOPs5fC?=
 =?us-ascii?Q?Oagr5yP3FjZkWogz8kyZNXpJGRwZFdiv3qAeudnsbSzKQDl2FxB9vnKV9Q28?=
 =?us-ascii?Q?JWRwWQLeTEs6cl4rDCiv+b+0yVMIPPjqEHBGJLoS4/PH3gwUQx66aRpvLZ7I?=
 =?us-ascii?Q?9nWrjGfm0i/jU5T1rXD7ytU1IN/+KCAVAsq5zJOdXVarsWsxYY9wJl6SaZvw?=
 =?us-ascii?Q?IVawRb+ysP5ASuWL+U0w6+vggbpo3lQM7xpl0RsjfmBmLI1wWAjzz6NEyuTp?=
 =?us-ascii?Q?6hBtYmKHZiDMneCdCpGdEhuiCpbXc+kpAhM/eBokbC5ihhrTshHhQXmqa58e?=
 =?us-ascii?Q?puii1xL36Z60/1Lpwo24kWWFmUAlC5IHbqoabgE4ZfQ30TJ4EQd2rxAnOgEV?=
 =?us-ascii?Q?SOEchxtTiasB3tFKfoUm03y59omMmkhEn7QZZR+mCIN+38qKszDzvc//tHgr?=
 =?us-ascii?Q?SecnSvNO0ifd25Hl05pxSjdKJ+8XR+pKpm7a74YPbcqhKQrkie2xYYCDSRwT?=
 =?us-ascii?Q?DXSPBkCrG4c6l0bjzcM+DFam/5oX6JEhBNAZot1med7c36vYLqL1OWDXP5Ng?=
 =?us-ascii?Q?w5eLKvyTnEYHAMS0iOWcuYnWwYtNcH87nWfOd7FVai22kOIWRqaeaos0hYo/?=
 =?us-ascii?Q?PhJLNIdO7S4Bdo2Thk3/Rk4vfwEq/bcdWZMC3Wu+AaE1Y4aeSTDYewUn6oSE?=
 =?us-ascii?Q?QdLBxevgYbDy1DiYURPbeUNOUOxsIboUF0z3PpKSYl/GCaK9m8yvdpo94gbe?=
 =?us-ascii?Q?etjTJjp5NKVah27N1CF4aqWsoKMuXNN7y2ybUyMe7ztKOcwKQ88DheXGIb/u?=
 =?us-ascii?Q?jaxylghlbi2fRBWsBSwvj5MQD6M4CYAlFD7DwlZ5J1tV3PO2fS9OqmOgzpyZ?=
 =?us-ascii?Q?LZqScj4sBQEAs+KDmteIBNt7JqYjpghsNgwyx77B58jrgnMf4Whj8ZaJMLy/?=
 =?us-ascii?Q?es5zoZc9Cvw9N/afHlWiDpepveV5wFxyBvRnXnEsQIDMI0ZbmnFuL6tuFgSI?=
 =?us-ascii?Q?Cm5hGne7kLFR+YuieQAKHmpgBBoegTIiXc5hTMOfPZypdRjw3eYJlgov8osb?=
 =?us-ascii?Q?5TyNcJVjaHlGJ+C9ZX6/JFHpXXSB7e3E1TSMVF52gOamyvjgeYLAqxY2f5xz?=
 =?us-ascii?Q?0N1vUkGb5Ks7+JFuutOSdIWcTAf3BjCcCWfOLkenpyyCgG6AYsGm?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7098622265602F41BF74141C3A0B9E8A@namprd15.prod.outlook.com>
X-OriginatorOrg: fb.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR15MB5109.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b2d44f1-c617-41ce-a734-08da21c69762
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2022 05:36:45.2788
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ap/+VBDqVT5xe6QV/Jyj++nXxrrGhVd+v/JEyamDMq7QDhm8b77UfghYMTRCvdqJy7mDDBz2V59fnEwo7/Gs2w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2263
X-Proofpoint-GUID: zLOnlp5_7ql5yzsB5SZFIOxjXsPO7ceN
X-Proofpoint-ORIG-GUID: zLOnlp5_7ql5yzsB5SZFIOxjXsPO7ceN
X-Proofpoint-UnRewURL: 0 URL was un-rewritten
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514
 definitions=2022-04-19_01,2022-04-15_01,2022-02-23_01
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE 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

Hi Mike, Luis, and Rick,

Thanks for sharing your work and findings in the space. I didn't 
realize we were looking at the same set of problems. 

> On Apr 18, 2022, at 6:56 PM, Edgecombe, Rick P <rick.p.edgecombe@intel.com> wrote:
> 
> On Mon, 2022-04-18 at 17:44 -0700, Luis Chamberlain wrote:
>>> There are use-cases that require 4K pages with non-default
>>> permissions in
>>> the direct map and the pages not necessarily should be executable.
>>> There
>>> were several suggestions to implement caches of 4K pages backed by
>>> 2M
>>> pages.
>> 
>> Even if we just focus on the executable side of the story... there
>> may
>> be users who can share this too.
>> 
>> I've gone down memory lane now at least down to year 2005 in kprobes
>> to see why the heck module_alloc() was used. At first glance there
>> are
>> some old comments about being within the 2 GiB text kernel range...
>> But
>> some old tribal knowledge is still lost. The real hints come from
>> kprobe work
>> since commit 9ec4b1f356b3 ("[PATCH] kprobes: fix single-step out of
>> line
>> - take2"), so that the "For the %rip-relative displacement fixups to
>> be
>> doable"... but this got me wondering, would other users who *do* want
>> similar funcionality benefit from a cache. If the space is limited
>> then
>> using a cache makes sense. Specially if architectures tend to require
>> hacks for some of this to all work.
> 
> Yea, that was my understanding. X86 modules have to be linked within
> 2GB of the kernel text, also eBPF x86 JIT generates code that expects
> to be within 2GB of the kernel text.
> 
> 
> I think of two types of caches we could have: caches of unmapped pages
> on the direct map and caches of virtual memory mappings. Caches of
> pages on the direct map reduce breakage of the large pages (and is
> somewhat x86 specific problem). Caches of virtual memory mappings
> reduce shootdowns, and are also required to share huge pages. I'll plug
> my old RFC, where I tried to work towards enabling both:
> 
> https://lore.kernel.org/lkml/20201120202426.18009-1-rick.p.edgecombe@intel.com/
> 
> Since then Mike has taken a lot further the direct map cache piece.

These are really interesting work. With this landed, we won't need 
the bpf_prog_pack work at all (I think). OTOH, this looks like a 
long term project, as some of the work in bpf_prog_pack took quite 
some time to discuss/debate, and that was just a subset of the 
whole thing. 

I really like the two types of cache concept. But there are some 
details I cannot figure out about them:

1. Is "caches of unmapped pages on direct map" (cache #1) 
   sufficient to fix all direct map fragmentation? IIUC, pages in
   the cache may still be used by other allocation (with some 
   memory pressure). If the system runs for long enough, there 
   may be a lot of direct map fragmentation. Is this right?
2. If we have "cache of virtual memory mappings" (cache #2), do we
   still need cache #1? I know cache #2 alone may waste some 
   memory, but I still think 2MB within noise for modern systems. 
3. If we do need both caches, what would be the right APIs? 

Thanks,
Song


> Yea, probably a lot of JIT's are way smaller than a page, but there is
> also hopefully some performance benefit of reduced ITLB pressure and
> TLB shootdowns. I think kprobes/ftrace (or at least one of them) keeps
> its own cache of a page for putting very small trampolines.
> 
>> 
>> Then, since it seems since the vmalloc area was not initialized,
>> wouldn't that break the old JIT spray fixes, refer to commit
>> 314beb9bcabfd ("x86: bpf_jit_comp: secure bpf jit against spraying
>> attacks")?
> 
> Hmm, yea it might be a way to get around the ebpf jit rlimit. The
> allocator could just text_poke() invalid instructions on "free" of the
> jit.
> 
>> 
>> Is that sort of work not needed anymore? If in doubt I at least made
>> the
>> old proof of concept JIT spray stuff compile on recent kernels [0],
>> but
>> I haven't tried out your patches yet. If this is not needed anymore,
>> why not?
> 
> IIRC this got addressed in two ways, randomizing of the jit offset
> inside the vmalloc allocation, and "constant blinding", such that the
> specific attack of inserting unaligned instructions as immediate
> instruction data did not work. Neither of those mitigations seem
> unworkable with a large page caching allocator.
> 
>> 
>> The collection of tribal knowedge around these sorts of things would
>> be
>> good to not loose and if we can share, even better.
> 
> Totally agree here. I think the abstraction I was exploring in that RFC
> could remove some of the special permission memory tribal knowledge
> that is lurking in in the cross-arch module.c. I wonder if you have any
> thoughts on something like that? The normal modules proved the hardest.
>