[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 13 Mar 2019 12:38:11 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 00/22] Updates for linux v4.19, v4.20 and v5.0
On Fri, Mar 08, 2019 at 11:53:15PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2019-03-08 15:32:45 -0500]:
> > On Fri, Mar 08, 2019 at 12:12:51AM +0100, Szabolcs Nagy wrote:
> > > From d8b15a06288dee0895bd6b51cbb81f3c696ba504 Mon Sep 17 00:00:00 2001
> > > From: Szabolcs Nagy <nsz@...t70.net>
> > > Date: Wed, 23 Jan 2019 20:06:12 +0000
> > > Subject: [PATCH 10/22] netinet/in.h update following linux v4.20
> > >
> > > IN_BADCLASS and IN_EXPERIMENTAL are changed and new macros are added
> > > for class-e addresses.
> > >
> > > linux commit 65cab850f0eeaa9180bd2e10a231964f33743edf
> > > ---
> > > include/netinet/in.h | 8 ++++++--
> > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/netinet/in.h b/include/netinet/in.h
> > > index 192679a6..2f87e33f 100644
> > > --- a/include/netinet/in.h
> > > +++ b/include/netinet/in.h
> > > @@ -168,8 +168,12 @@ uint16_t ntohs(uint16_t);
> > > #define IN_CLASSC_HOST (0xffffffff & ~IN_CLASSC_NET)
> > > #define IN_CLASSD(a) ((((in_addr_t)(a)) & 0xf0000000) == 0xe0000000)
> > > #define IN_MULTICAST(a) IN_CLASSD(a)
> > > -#define IN_EXPERIMENTAL(a) ((((in_addr_t)(a)) & 0xe0000000) == 0xe0000000)
> > > -#define IN_BADCLASS(a) ((((in_addr_t)(a)) & 0xf0000000) == 0xf0000000)
> > > +#define IN_MULTICAST_NET 0xe0000000
> > > +#define IN_BADCLASS(a) ((((in_addr_t)(a)) == 0xffffffff)
> > > +#define IN_EXPERIMENTAL(a) IN_BADCLASS((a))
> > > +#define IN_CLASSE(a) ((((in_addr_t)(a)) & 0xf0000000) == 0xf0000000)
> > > +#define IN_CLASSE_NET 0xffffffff
> > > +#define IN_CLASSE_NSHIFT 0
> >
> > You've described these as Linux 4.20 additions, but they aren't
> > specific to any Linux API or defined by Linux as far as I can tell.
> > Rather, aren't they aligned with some change by IANA or something? The
> > motivation for having them would not be that Linux made corresponding
> > changes in kernel headers, but rather that they're the proper
> > definitions for changes to a relevant network-related standard.
>
> my idea was to enable users to use netinet/in.h instead
> of linux/in.h, so new definitions added there are blindly
> copied (i didn't fully understand the linux commit
> message explaining why this change was useful, so yes this
> may need some investigation)
After reading it, I don't fully understand what's going on either, and
whether there's any reason the userspace macros need to change. So I'm
going to hold off on this patch for now until there's a good
explanation for it. The rest are fine and I'm merging them...
> > > From f06c03ef3ce4c21d15416e071d3a7e2bab40928a Mon Sep 17 00:00:00 2001
> > > From: Szabolcs Nagy <nsz@...t70.net>
> > > Date: Thu, 7 Mar 2019 21:53:48 +0000
> > > Subject: [PATCH 21/22] sys/prctl.h: add PR_PAC_RESET_KEYS from linux v5.0
> > >
> > > aarch64 pointer authentication code related prctl that allows
> > > reinitializing the key for the thread, added in linux commit
> > > ba830885656414101b2f8ca88786524d4bb5e8c1
> > > ---
> > > include/sys/prctl.h | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/include/sys/prctl.h b/include/sys/prctl.h
> > > index 07a3490b..4b6c8918 100644
> > > --- a/include/sys/prctl.h
> > > +++ b/include/sys/prctl.h
> > > @@ -146,6 +146,13 @@ struct prctl_mm_map {
> > > #define PR_SPEC_DISABLE (1UL << 2)
> > > #define PR_SPEC_FORCE_DISABLE (1UL << 3)
> > >
> > > +#define PR_PAC_RESET_KEYS 54
> > > +# define PR_PAC_APIAKEY (1UL << 0)
> > > +# define PR_PAC_APIBKEY (1UL << 1)
> > > +# define PR_PAC_APDAKEY (1UL << 2)
> > > +# define PR_PAC_APDBKEY (1UL << 3)
> > > +# define PR_PAC_APGAKEY (1UL << 4)
> > > +
> > > int prctl (int, ...);
> >
> > Is there a reason for this formatting? It's unlike anything we use
> > elsewhere in the file or elsewhere in musl.
>
> i just copied this format from the kernel, the prctl
> option PR_PAC_RESET_KEYS takes a flags argument, so
> i guess the indentation of the flag macros imply that
> they belong to the option above, but indeed other
> macros are not formatted this way, i can drop the space.
..with these changes. Will push soon.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
