From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id CCFD0463F4
for <public@inbox.dpdk.org>; Wed, 12 Mar 2025 17:29:26 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id BA91A402D3;
Wed, 12 Mar 2025 17:29:26 +0100 (CET)
Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com
[209.85.214.174])
by mails.dpdk.org (Postfix) with ESMTP id 64994402D3
for <stable@dpdk.org>; Wed, 12 Mar 2025 17:29:25 +0100 (CET)
Received: by mail-pl1-f174.google.com with SMTP id
d9443c01a7336-22349bb8605so1461625ad.0
for <stable@dpdk.org>; Wed, 12 Mar 2025 09:29:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1741796964;
x=1742401764; darn=dpdk.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:from:to:cc:subject:date
:message-id:reply-to;
bh=KKbPOADSbzsfzB56O+zIWSE0cu2PoI+a1p69ZhemJyM=;
b=zmm3PftMqj0WeaztQ6FVK5KUjjy3bpij3t4kYVH1rWIsQk8TjJ1bm4dHl2AuiVJCWv
8jhcrBdVJwuHJPSB5CqZIZpsim1SGwkpUERjeDZfnxvPJLBi9Foo4pMBUFzccFcuUkYs
lvEXE4FhVflGBu/Gq4Vz2ussWkHoxy8Sl8+jhYWk7u0PhsChHrYhm5TozHfTtgszhloA
VoDkEfpFwySUhWy5FNxHMkcxTEl444YyG7hFXCmy4OLKX2t8aofwqr99tfe+2BXni9HW
a//d+VGQl25ewhZgGNFUvWDvJBEDq/YgJdtwWEjWKyQxDoqQRxJ0g0ZAo3FqwPqUekGo
AbGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1741796964; x=1742401764;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=KKbPOADSbzsfzB56O+zIWSE0cu2PoI+a1p69ZhemJyM=;
b=Nv/RDpMF6BJDQnylPYALgHfqN8iR0PMi03sKqAtBjR70T29Wo0V8YWaPuWf0JkfsnM
R84C7UkdbTlYcECfPY0vE3j6BhszCdwgmoIibBOxV86CaL2EhRGIW4buaMjnmd+3rRju
nFnvZE9v1VIdOnMQ0biPtK72xO/aXEDqo23HqU4wZunMPnENDpt/88Bqkf4LJA520QhN
f74BIhIhMTwTaV1B8D3C6A/CChHTm8ntz5sYdqdgVM7EDeuA83wORyTV9n336cqELKej
TBRPZntXp/zAqD2rlUSxFyVz8vRvGPOhx4u1gxSBR0nglVscIP7b3x3SwQVbvPNi/fBR
fU6w==
X-Forwarded-Encrypted: i=1;
AJvYcCVk77HHjUTgyMQ2NFjKVfKMP5+5SDMdFcGGQJHVPMACPYCuwqXDFLilhYEeh7rj/DdTtba5v3U=@dpdk.org
X-Gm-Message-State: AOJu0YyAIz9bTgVleAzmJoHKDHI6G5vQEDvLVT16vHLGkG0rXKQ6cymW
+gMyRruIZDMvJQr7E7OlknFbgZtCJ3nQOg7pg8SBcR9eKqylwX+cWgQ2L5UZnbk=
X-Gm-Gg: ASbGncuqG40bS9pj35giyNyel0SoAdpduSnE1KPvflcTpCJtaG+l95D7L07p7sKUCm4
fMC7Rx28e5XYRNrepupGP+i4BFGnHIFEHsRKOGRxOlGDOp3k51VLr2raI8+4EVGgHFTVhyBWgX3
NnsRmm/XH6oVgB5jE7NaXFyEvxpbE2YhENA6abBItVOjGp9depI9xJZYTotLZ6iq/8t6OwCmPsE
cwaR9gAYW51Hld+aJRgnG9DjX1KBKaTDDbUGI18UPxJo+KoyNrzcU3AdKU2pc64f5LFrUsVHlNY
LObtchGKH7D4e+X/b8BIlxRTgn5svpzLj5ciq0oxJ7eVpgVlAfVjEW862lVaPEkM0q8dK9zCpVm
UkXObOj9U5C3Pdm9f9roqWQ==
X-Google-Smtp-Source: AGHT+IFcia/JktOaIOJ2NQfkD46HYVJHGQFQ9RAm1q3InwSd59DINJSCKzYWr4BhsUHEBPFxpasWfA==
X-Received: by 2002:a05:6a00:21d1:b0:736:34a2:8a20 with SMTP id
d2e1a72fcca58-736aaae4d01mr35737180b3a.21.1741796964239;
Wed, 12 Mar 2025 09:29:24 -0700 (PDT)
Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226])
by smtp.gmail.com with ESMTPSA id
d2e1a72fcca58-736cc5b2c77sm7357074b3a.163.2025.03.12.09.29.23
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 12 Mar 2025 09:29:24 -0700 (PDT)
Date: Wed, 12 Mar 2025 09:29:22 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Yang Ming <ming.1.yang@nokia-sbell.com>
Cc: Anatoly Burakov <anatoly.burakov@intel.com>, dev@dpdk.org, stable@dpdk.org
Subject: Re: [PATCH] eal/linux: enhance ASLR verification
Message-ID: <20250312092922.32412cd7@hermes.local>
In-Reply-To: <82920758-20eb-442c-a62b-a3babb65bfa7@nokia-sbell.com>
References: <20250228094405.1437-1-ming.1.yang@nokia-sbell.com>
<20250310144310.70ba71e6@hermes.local>
<82920758-20eb-442c-a62b-a3babb65bfa7@nokia-sbell.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
On Wed, 12 Mar 2025 11:13:27 +0800
Yang Ming <ming.1.yang@nokia-sbell.com> wrote:
> On 2025/3/11 05:43, Stephen Hemminger wrote:
> > Caution: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/nsb for additional information.
> >
> > On Fri, 28 Feb 2025 17:44:04 +0800
> > Yang Ming <ming.1.yang@nokia-sbell.com> wrote:
> >
> >> This change ensures that the current process is checked for
> >> being run with 'setarch' before verifying the value of
> >> '/proc/sys/kernel/randomize_va_space'. The '-R' or
> >> '--addr-no-randomize' parameter of the 'setarch' command is used
> >> to disable the randomization of the virtual address space.
> >>
> >> Fixes: af75078fece3 ("first public release")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
> > Looks good, I wonder if the personality() check can supersede the need
> > to reference sysfs here?
> >
> Hi Stephen,
>
> Thank you for your feedback. The personality() check is indeed a useful
> addition to determine if the current process is executed with the
> ADDR_NO_RANDOMIZE flag set, which can disable ASLR (Address Space Layout
> Randomization).
>
> However, relying solely on the personality() check may not be sufficient
> in all scenarios. The personality() function checks the attributes of
> the current process, but it does not provide information about the
> system-wide ASLR settings, which are typically controlled via sysfs
> (/proc/sys/kernel/randomize_va_space). The sysfs file
> RANDOMIZE_VA_SPACE_FILE indicates the global ASLR setting for the entire
> system, which can affect all processes.
>
> By including both checks, we ensure comprehensive coverage:
> 1. The personality() check verifies if the current process has ASLR
> disabled.
> 2. The sysfs reference checks the global ASLR setting, which affects all
> processes.
>
> Therefore, while the personality() check is valuable, it does not
> entirely supersede the need to reference sysfs. Both checks together
> provide a more robust determination of ASLR status.
>
>
> Brs,
> Yang Ming
I wonder if EAL should have --no-aslr flag and call personality itself?
Maybe not since it would have to happen early before other areas are mapped.