[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190308225315.GE26605@port70.net>
Date: Fri, 8 Mar 2019 23:53:15 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 00/22] Updates for linux v4.19, v4.20 and v5.0
* 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)
> > 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.
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.
