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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E3A0C77B75 for ; Mon, 22 May 2023 16:23:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 68ED9900003; Mon, 22 May 2023 12:23:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 63C94900002; Mon, 22 May 2023 12:23:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4DDE7900003; Mon, 22 May 2023 12:23:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 3E45D900002 for ; Mon, 22 May 2023 12:23:00 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 084A0801A8 for ; Mon, 22 May 2023 16:22:59 +0000 (UTC) X-FDA: 80818410120.02.428FA37 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf23.hostedemail.com (Postfix) with ESMTP id 89FCF140024 for ; Mon, 22 May 2023 16:22:57 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=U6cmhQEa; spf=pass (imf23.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684772577; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5um2DUZCGOrnDKFk5C7dFmDvO0JwbcJTzc9WMdYWTFQ=; b=TVNqTx0osm/nQ//UZ8h6wDmrqwcHLpt3pQLJQT/2h3NWcsMd7zEfEdnjVFeXeyK4LEYvTE YKZYYbR/pv4ojm4Ug1L6rx97fzS13CgQDOoeuNAvhA+39H6t5kCdwaOg4EuDr0o5Y60B4d 0/Frg6PFjP+FvLK5IyqAxht7oIcqk8o= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684772577; a=rsa-sha256; cv=none; b=r1Hybbnn0K/FD6Vk/YXtfIYVUqe92HeAykvnLNTCpZI3ylDnCt8JHTOB0qN0UGepLiDAjR rDCBJtRPuW9DKPwSoJ/VdnmIWhXNdgNVu5odasLR496JcfAbDuMwqPo0K4CnfL4tu9UYfy lLMblPohd/uzTzT/0uru9US2TnolDXY= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=U6cmhQEa; spf=pass (imf23.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684772576; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5um2DUZCGOrnDKFk5C7dFmDvO0JwbcJTzc9WMdYWTFQ=; b=U6cmhQEaeX/ktiPz9tnNEECakn//OPU1F6gxncriJYhtsm/08ShvSroTBRxnzSYEbo8xP1 HO3Ce2y9fge+vwlsx0RmX8nTPsT9oBpDM5C/bLPJaPnoXNv0dA6glLZ2YarX68p7fw97Qr /V7tARIFrA3I3Pn73PQUYIsBL1dZmgc= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-346-1i40QQn3PZy8eF1oJOljGA-1; Mon, 22 May 2023 12:22:55 -0400 X-MC-Unique: 1i40QQn3PZy8eF1oJOljGA-1 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-30634323dfeso2652449f8f.3 for ; Mon, 22 May 2023 09:22:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684772574; x=1687364574; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5um2DUZCGOrnDKFk5C7dFmDvO0JwbcJTzc9WMdYWTFQ=; b=HBWzQce3fRqmMOxG2x+0xIuXnAFnBKJVnd9ETj2tzTe5uFfE5VKOfoEY59dP/fK2G7 gIbfwHVncg5RkzfPGZ0LuhVssSJdyQa7r9EDcvgNla7esc29n4AeYEKyixyQgEpacNNl ip2roPw4M7/clH5EISd0AOcjcfPIuM7uVJJGmRmbdBRR25gQRLrYIWW8SziHBA8qYymN Dff5TscvX+vnNujFxpJcj8hhnDscTb443Y9oaj1fzbW9JEB+r4uxkCGShYbdzvXl0QYL ARLXt2cwRkrNi1LPPvWP6jzjfhR7twxTgUGaEEt7HRVsXEHgLWhzCsbnTOMfSQCqNmMG 9lLw== X-Gm-Message-State: AC+VfDzwqAskCQ5pERzAGfRH4T4DvZNtY1FdrDDAJ862/4mz0Xz3LmLV xSUcTJpfSENXjaVBFsRRPxir0y+4W6LmBCbJTTSRDn9vP5b3hhy+zTf3JLDo92Mt3e9OrBVh4Cz zMfQoXYDDVXE= X-Received: by 2002:a5d:6b4c:0:b0:2f5:83a8:a9a9 with SMTP id x12-20020a5d6b4c000000b002f583a8a9a9mr8879062wrw.16.1684772574043; Mon, 22 May 2023 09:22:54 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5iC+0hWblwlzmu67PfNeSA6rcEpnFz0r3DcQrueBLHpgIycc51012PyvkJIr4xO+W7TQ/LMw== X-Received: by 2002:a5d:6b4c:0:b0:2f5:83a8:a9a9 with SMTP id x12-20020a5d6b4c000000b002f583a8a9a9mr8879036wrw.16.1684772573694; Mon, 22 May 2023 09:22:53 -0700 (PDT) Received: from ?IPV6:2003:cb:c748:4300:c403:519c:6f8f:19c9? (p200300cbc7484300c403519c6f8f19c9.dip0.t-ipconnect.de. [2003:cb:c748:4300:c403:519c:6f8f:19c9]) by smtp.gmail.com with ESMTPSA id a2-20020a056000100200b0030903d44dbcsm8189116wrx.33.2023.05.22.09.22.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 May 2023 09:22:52 -0700 (PDT) Message-ID: Date: Mon, 22 May 2023 18:22:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v2 3/5] mm: Make PR_MDWE_REFUSE_EXEC_GAIN an unsigned long To: Alexey Izbyshev Cc: Florent Revest , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, catalin.marinas@arm.com, anshuman.khandual@arm.com, joey.gouly@arm.com, mhocko@suse.com, keescook@chromium.org, peterx@redhat.com, broonie@kernel.org, szabolcs.nagy@arm.com, kpsingh@kernel.org, gthelen@google.com, toiwoton@gmail.com References: <20230517150321.2890206-1-revest@chromium.org> <20230517150321.2890206-4-revest@chromium.org> <884d131bbc28ebfa0b729176e6415269@ispras.ru> From: David Hildenbrand Organization: Red Hat In-Reply-To: <884d131bbc28ebfa0b729176e6415269@ispras.ru> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: az6wn9kj1ho6ow49j7ecxzfr5xrre8qa X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 89FCF140024 X-Rspam-User: X-HE-Tag: 1684772577-227403 X-HE-Meta: U2FsdGVkX18f9zUguxN4UNk0kk20N8lVqRpNY+8amdyPqPCK4BvBRk2ePdyxODjDuGrVeqboqLlbCgW1xQ/O4ISgYzp0FA/pZJwM0IBl8xH8socBx58gWRZEm/d2kGuA0PQu6a49DEK/HPf8wm5fDK4x+LVvH9PxJuHorXO3Qwfh4NwNOAAS/J+wfmwEFJ7tFGcti8Swm/i+6tR8e/hoEFUkqA1fbLfO1O6CqUKJRChW1UaMKtkYK2JN0Ls6gjF2GBvJTE2pvhZKa2iD/+iBQ98p2xRcMG++t2vP6SPfqInn7GU+lrEJQQNQYTq0SYXmXv92tIglwnV6O2sTantJHP0nN3DRM4TLt/SPiweE/m9Lo/n1c1ZGJndKkEsaRvKL8N+wOMHhoT0fzA8P//Z6u7VdcnXSVXYC7/eI/4zwACt/FlqIiHQvvrBOGKMm7MsRq73TMPbXAYTNkOMig/3IZynPhhlSfJf0JTCjn8r1yZDY4CqlM/xrHvGzlPs47TgMEcPAxL/7DCTxzx2tni58ndrBJF04zK5M7qRPLoc/upxI7s7JEJOOzZNc3UfWSeiG2vIQxaZ3aYU52dYgB4aM82PwrpOcsJwI6BcEoHvlTXuHnlmwNicErbGJqtV99olfLeXy/NpmBzZV25OKj9jPXgtsJx6hdINr1UjiFjh4CV36qFNV+K+D5JFAorNBKyfnBNbAMOIhlEvy/nfeR7kwVDc7hCDh8GtbncGOybLheUMiEIhLw8HJHxpSOW3TkC1mxchpuCQeofRNoCmPd2tOGakU26MPmS991vALi54v9zzXem3IfXiZc/DyDmiEXoJtL7sgJkNNau+pxcCjSGpKFHMehcPYdPzmXwfBhzNHOLGsZR7uH0hUp5EqCbpseVFKr7omSA9jTs9NObb5/pWrQh7u/Irs9YpeNgABqFQj3l91KLuH49R9Zr0jphygyg7AGjLFZ/ABrVUdu+G5wzA IT8y4Dbu gb+XOFycYSKgCGC5EccSn2QyB6fpokXAznscaWxgDEuIC8P80DjZlXZYsGOPx+bHD/8zoJl/zmXblEEOSRM4d7Uaw0JEZuVpEi7sNS/KVAxY0TqX3g5fg9H/ULIvWE7ibuQnmKwtH/YeFiLKoqrtwqqhDt+adiw+0EnaRIwVXdbuZWsf+PZ1cJkF7x+FXqMeY7DudVg+Kgt8j8qOAk4FZI+6l24FHkj2eh+QoVCkvVTOdU2PjPKLPmxlQa3pfFVscDL3La869fAAoCV73n6sTmPyRjYqcj+o8rkuBjryuYZKDqPVYrpX6unXnBa+fxAWCIyvv+MpShRIb1U8D+L09xVyr2PxMNjzg0rwCnHcEcRNYGAtHdbWxv/2LjMdGfcigEk4zQeluQfOqPXxyUVuWGeAvrP8lzXXwDDXtduhLGzGyF6QOL+aOwFBcuPBIuXozqqgCMbtR0XlvduVnEexzRtAIFk2krf1LmHOvhVQjNKR6CLbYH+oMA7gBuiCDfKCfrEoug5BeCZJEIeTSQAQGU2/NGOuspMSk0d7eavPnvz0m7Dk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 22.05.23 12:35, Alexey Izbyshev wrote: > On 2023-05-22 11:55, David Hildenbrand wrote: >> On 17.05.23 17:03, Florent Revest wrote: >>> Alexey pointed out that defining a prctl flag as an int is a footgun >>> because, under some circumstances, when used as a flag to prctl, it >>> can >>> be casted to long with garbage upper bits which would result in >>> unexpected behaviors. >>> >>> This patch changes the constant to a UL to eliminate these >>> possibilities. >>> >>> Signed-off-by: Florent Revest >>> Suggested-by: Alexey Izbyshev >>> --- >>> include/uapi/linux/prctl.h | 2 +- >>> tools/include/uapi/linux/prctl.h | 2 +- >>> 2 files changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h >>> index f23d9a16507f..6e9af6cbc950 100644 >>> --- a/include/uapi/linux/prctl.h >>> +++ b/include/uapi/linux/prctl.h >>> @@ -283,7 +283,7 @@ struct prctl_mm_map { >>> /* Memory deny write / execute */ >>> #define PR_SET_MDWE 65 >>> -# define PR_MDWE_REFUSE_EXEC_GAIN 1 >>> +# define PR_MDWE_REFUSE_EXEC_GAIN (1UL << 0) >>> #define PR_GET_MDWE 66 >>> diff --git a/tools/include/uapi/linux/prctl.h >>> b/tools/include/uapi/linux/prctl.h >>> index 759b3f53e53f..6e6563e97fef 100644 >>> --- a/tools/include/uapi/linux/prctl.h >>> +++ b/tools/include/uapi/linux/prctl.h >>> @@ -283,7 +283,7 @@ struct prctl_mm_map { >>> /* Memory deny write / execute */ >>> #define PR_SET_MDWE 65 >>> -# define PR_MDWE_REFUSE_EXEC_GAIN 1 >>> +# define PR_MDWE_REFUSE_EXEC_GAIN (1UL << 0) >>> #define PR_GET_MDWE 66 >>> >> >> Both are changing existing uapi, so you'll already have existing user >> space using the old values, that your kernel code has to deal with no? > > I'm the one who suggested this change, so I feel the need to clarify. > > For any existing 64-bit user space code using the kernel and the uapi > headers before this patch and doing the wrong prctl(PR_SET_MDWE, > PR_MDWE_REFUSE_EXEC_GAIN) call instead of the correct prctl(PR_SET_MDWE, > (unsigned long)PR_MDWE_REFUSE_EXEC_GAIN), there are two possibilities > when prctl() implementation extracts the second argument via va_arg(op, > unsigned long): > > * It gets lucky, and the upper 32 bits of the argument are zero. The > call does what is expected by the user. > > * The upper 32 bits are non-zero junk. The flags argument is rejected by > the kernel, and the call fails with EINVAL (unexpectedly for the user). > > This change is intended to affect only the second case, and only after > the program is recompiled with the new uapi headers. The currently > wrong, but naturally-looking prctl(PR_SET_MDWE, > PR_MDWE_REFUSE_EXEC_GAIN) call becomes correct. > > The kernel ABI is unaffected by this change, since it has been defined > in terms of unsigned long from the start. The thing I'm concerned about is the following: old user space (that would fail) on new kernel where we define some upper 32bit to actually have a meaning (where it would succeed with wrong semantics). IOW, can we ever really "use" these upper 32bit, or should we instead only consume the lower 32bit in the kernel and effectively ignore the upper 32bit? I guess the feature is not that old, so having many existing user space applications is unlikely. Which raises the question if we want to tag this here with a "Fixes" and eventually cc stable (hmm ...)? -- Thanks, David / dhildenb