From: "Jake Freeland" <jfree@freebsd.org>
To: "Stephen Hemminger" <stephen@networkplumber.org>
Cc: "Anatoly Burakov" <anatoly.burakov@intel.com>,
"Bruce Richardson" <bruce.richardson@intel.com>,
"dev" <dev@dpdk.org>
Subject: Re: [PATCH 3/3] eal/linux: Check hugepage access permissions
Date: Wed, 07 May 2025 11:09:33 -0500 [thread overview]
Message-ID: <D9Q252DFOH0V.1CHFLNZDP105D@freebsd.org> (raw)
In-Reply-To: <CAOaVG142x9ENgVF_p2GuhYA7wRuSXN83=__4D_+kXvxghZB-mg@mail.gmail.com>
On Wed May 7, 2025 at 3:52 AM CDT, Stephen Hemminger wrote:
> Please don't split message a across multiple lines.
> Open and access are not the same in all security checks, so not a great
> idea.
What do you mean by this? In this case, access() is just verifying that
we can read and write to the hugepage directory. What extra security
check does open() perform that would be needed here?
Keep in mind that open() will still be used to open the hugepages and
perform it’s own checks later on. The purpose of this access() call is
to avoid saving inaccessible hugepage paths up front.
> Some analyzer tools may flag as time of check, time of use issue.
If this access() check succeeds (i.e. we have r/w access) and the
permissions of the hugepage directory change to read-only before we call
open(), then open() will fail like it does without this patch. This
seems like reasonable behavior to me and is better than having no
initial r/w check at all.
Thanks,
Jake Freeland
>
> On Wed, May 7, 2025, 02:50 Jake Freeland <jfree@freebsd.org> wrote:
>
> > Currently, hugepage mountpoints will be used irrespective of permissions,
> > leading to potential EACCES errors during memory allocation. Fix this by
> > not using a mountpoint if we do not have read/write permissions on it.
> >
> > Signed-off-by: Jake Freeland <jfree@FreeBSD.org>
> > ---
> > lib/eal/linux/eal_hugepage_info.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/lib/eal/linux/eal_hugepage_info.c
> > b/lib/eal/linux/eal_hugepage_info.c
> > index d47a19c56a..dbfa38b05c 100644
> > --- a/lib/eal/linux/eal_hugepage_info.c
> > +++ b/lib/eal/linux/eal_hugepage_info.c
> > @@ -260,6 +260,12 @@ get_hugepage_dir(uint64_t hugepage_sz, char *hugedir,
> > int len)
> > continue;
> > }
> >
> > + if (access(splitstr[MOUNTPT], R_OK | W_OK) < 0) {
> > + EAL_LOG(NOTICE, "Missing r/w permissions on huge
> > dir: "
> > + "'%s'. Skipping it", splitstr[MOUNTPT]);
> > + continue;
> > + }
> > +
> > /*
> > * If no --huge-dir option has been given, we're done.
> > */
> > -
> >
>
> >
prev parent reply other threads:[~2025-05-07 16:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-06 17:50 [PATCH 0/3] EAL memory fixes Jake Freeland
2025-05-06 17:50 ` [PATCH 1/3] eal/freebsd: Do not use prev_ms_idx for hole detection Jake Freeland
2025-05-08 10:31 ` Burakov, Anatoly
2025-05-08 11:05 ` Burakov, Anatoly
2025-05-06 17:50 ` [PATCH 2/3] eal/freebsd: Do not index out of bounds in memseg list Jake Freeland
2025-05-08 11:20 ` Burakov, Anatoly
2025-05-06 17:50 ` [PATCH 3/3] eal/linux: Check hugepage access permissions Jake Freeland
2025-05-07 8:52 ` Stephen Hemminger
2025-05-07 16:09 ` Jake Freeland [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D9Q252DFOH0V.1CHFLNZDP105D@freebsd.org \
--to=jfree@freebsd.org \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).