Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.