From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C3ECC83F2F for ; Thu, 31 Aug 2023 20:37:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233412AbjHaUhU (ORCPT ); Thu, 31 Aug 2023 16:37:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231266AbjHaUhT (ORCPT ); Thu, 31 Aug 2023 16:37:19 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C734AE65 for ; Thu, 31 Aug 2023 13:37:15 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d7b957fd276so1018872276.0 for ; Thu, 31 Aug 2023 13:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693514235; x=1694119035; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=Riep5pyahAnxXOHIAicjRGy5HGdPOIzlJBXzr6RzmUM=; b=d/tC/9gCiFcMnNxE3maBKwVuY5qvIt6zYsH3KEo7xLnXPE65YE0sNlyQLdm5zpja53 ci5w6djzFf7cPny4E3Jt7x85cP5duyK8doqAsAr3hxJ+gERTU7tTO1nBpxnmjfG5v6Gh IqO36G4YiCXcHnfLSA7KbuiVGkrWny3b6QNIud109AeL+ShJBP9+wktprm1V8UXg7Lfl OUesBf2RLh7dqJq8zAFIAHVFt2791297eamndqeiX3iGzevcXXehdBfadl4DADJLUMRB /+ABw/o933QtEpbByEgABP4hfm2J03cRUAp6GjQ37iwpmf3fUf3z12sjdjC8W4GUosa4 1kDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693514235; x=1694119035; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Riep5pyahAnxXOHIAicjRGy5HGdPOIzlJBXzr6RzmUM=; b=Sl6uys4A1krsFTr1+AZhzQVqRfuaJyCrHzVS0/RjxFdLU1xQ7qHTFLDQK7m2K2LRJI wsJBRe+U0ZvOMhqAQuwgSg+slrIDljMzMoBahmMrLiI4hBIkonJdxZJog7h8/3mCDDj+ fJl2XZihKC59k8/I1RG0LLcDgNnRSq/o/W0Vv/Uj7PU8xOnChSBbYAC/XACjuQfGg8TU JPK0Yv75LWzaUb4qPf3qsDEWgKboPeoyBzf/FqjN9KfDGw5TquQuagfOc3UQY07FkENY u8tszs7TOTlwEhEfndIQvSxkSX4dRJmlu34WLVrIRaQfaNtwWqUY61zK6XQNvA+pkwt6 1LQA== X-Gm-Message-State: AOJu0YxomYCMTcKg05TA/wzFKk3JEl4KNxsGfFtMRqWmDUqymLA8JfVZ gIFocPqha9BH/bez84J+NaSADPiIu8FkJ7lw X-Google-Smtp-Source: AGHT+IFcu8cOp7pIa9OilL6fag67y6JJgGLJBhTT1SQk4UIAxSrG1Tx5R8I4WGtPGGNkLdRhCeCUlRFRF/gQcWz4 X-Received: from mclapinski.waw.corp.google.com ([2a00:79e0:9b:0:36f8:f0a:6df2:a7d5]) (user=mclapinski job=sendgmr) by 2002:a25:9f89:0:b0:d4f:d7a5:ba3b with SMTP id u9-20020a259f89000000b00d4fd7a5ba3bmr21259ybq.8.1693514235020; Thu, 31 Aug 2023 13:37:15 -0700 (PDT) Date: Thu, 31 Aug 2023 22:36:45 +0200 Mime-Version: 1.0 X-Mailer: git-send-email 2.42.0.283.g2d96d420d3-goog Message-ID: <20230831203647.558079-1-mclapinski@google.com> Subject: [PATCH 0/2] fcntl: add fcntl(F_CHECK_ORIGINAL_MEMFD) From: Michal Clapinski To: Jeff Layton , Chuck Lever , Alexander Viro , Christian Brauner , Shuah Khan , Andrew Morton , Jeff Xu , Aleksa Sarai , Daniel Verkamp , Kees Cook , Marc Dionne , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Cc: Michal Clapinski Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This change introduces a new fcntl to check if an fd points to a memfd's original open fd (the one created by memfd_create). We encountered an issue with migrating memfds in CRIU (checkpoint restore in userspace - it migrates running processes between machines). Imagine a scenario: 1. Create a memfd. By default it's open with O_RDWR and yet one can exec() to it (unlike with regular files, where one would get ETXTBSY). 2. Reopen that memfd with O_RDWR via /proc/self/fd/. Now those 2 fds are indistinguishable from userspace. You can't exec() to either of them (since the reopen incremented inode->i_writecount) and their /proc/self/fdinfo/ are exactly the same. Unfortunately they are not the same. If you close the second one, the first one becomes exec()able again. If you close the first one, the other doesn't become exec()able. Therefore during migration it does matter which is recreated first and which is reopened but there is no way for CRIU to tell which was first. Michal Clapinski (2): fcntl: add fcntl(F_CHECK_ORIGINAL_MEMFD) selftests: test fcntl(F_CHECK_ORIGINAL_MEMFD) fs/fcntl.c | 3 ++ include/uapi/linux/fcntl.h | 9 ++++++ tools/testing/selftests/memfd/memfd_test.c | 32 ++++++++++++++++++++++ 3 files changed, 44 insertions(+) -- 2.42.0.283.g2d96d420d3-goog