On 2025/3/13 00:29, 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 Wed, 12 Mar 2025 11:13:27 +0800
Yang Ming <ming.1.y...@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.y...@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: sta...@dpdk.org
Signed-off-by: Yang Ming <ming.1.y...@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.
Hi Stephen,
Thank you for your feedback.
Regarding the suggestion to add an --no-aslr flag to EAL and call
personality() early in the process, I agree that this could be a useful
feature. However, implementing this would require ensuring that the flag
is processed very early in the initialization sequence, before any
memory mappings occur. This might involve significant changes to the EAL
initialization code to handle the flag appropriately.
For the current patch, the aslr_enabled() function aims to check the
ASLR status without modifying the process's personality settings. The
addition of the personality() check provides a way to detect if ASLR is
disabled for the current process, complementing the sysfs check. This
way also required to support the function of "setarch" command.
To improve the patch, we could add a comment explaining the rationale
behind using both checks.
Additionally, I will restore the blank line between the #endif and
#include <rte_errno.h> statements to maintain coding style and readability.
I will update this patch accordingly and send it for review shortly.
Brs,
Yang Ming
