Re: regarding OpenSSL License change

[Theo de Raadt]

> > If we do not hear from you, we will assume that you have no objection.
> 
> So, they will claim that, by not responding, the recipient agreed.
> 
> Some jurisdictions I am aware of accept verbal contracts or this kind
> of written contracts, since civil proceedings will not be held up to a
> high standard of proof. Even then, there must have been evidence of a
> contractual agreement, ie. no response = no agreement.
> 
> I say the lawyers are now working to prove that no response means the
> potential recipient agreed.
> 
> If this email has been caught by enough spam filters, they will claim
> the majority agreed.
> 

Dude, you are being melodramatic

it is great that someone found a way to convert between licenses.

AGPL -> GPL -> ISC -> PD

thumbs up to the people who found a shortcut

Re: regarding OpenSSL License change

[Theo de Raadt]

> So did anyone who replied with "NO" get a followup to "reconsider"?

So far, everyone who says no is getting a mail from Rich Salz.

Re: regarding OpenSSL License change

[Claus Assmann]

So did anyone who replied with "NO" get a followup to "reconsider"?
I only "contributed" some doc fixes, so my "vote" doesn't really
mean much.

GCC licence change

[Theo de Raadt]

I am mailing tech@openbsd.org (and thereby, the greater community
who's email addresses may have changed) to inquire whether it is OK to
change the version of gcc 4.2.1 in our source tree to from GPL to the
ISC license.

This licence improvement will remove the last bits of ambiguity about
access to C compiler technology in a world where clang/llvm is
permissive licensed.  Everyone deserves access to C technology without
restriction, especially as rust makes inroads.

To push this change through we are going to follow the re-licensing
procedure recently proposed by OpenSSL, which has been signed off by
their lawyers at the SFLC.  This process has significant signoff from
Linux Foundation, Intel, and others.

Therefore, I am asking all authors to respond to this thread if they
object.

Should probably provide special attention to the original author as
the starting point for all future work as 'derivative' authors who
could be authors on their own.  He is the Eric Young of gcc, so we
respect his opinion. In case he doesn't read this let him know; if he
is concerned he will reply. Richard schooled SFLC when yacc got turned
into bison.

OpenSSL and SFLC are suggesting lack of consent towards an action,
indicates consent towards that action.  According to that:

If we do not hear from you, we will assume that you have no objection.

We are providing a full week notice to the community to consider this,
then we will continue with this innocuous procedure.

ps. If the bcc to reach you bounced, sorry.

Re: regarding OpenSSL License change

[bytevolcano]

...

> If we do not hear from you, we will assume that you have no objection.

So, they will claim that, by not responding, the recipient agreed.

Some jurisdictions I am aware of accept verbal contracts or this kind
of written contracts, since civil proceedings will not be held up to a
high standard of proof. Even then, there must have been evidence of a
contractual agreement, ie. no response = no agreement.

I say the lawyers are now working to prove that no response means the
potential recipient agreed.

If this email has been caught by enough spam filters, they will claim
the majority agreed.

Re: regarding OpenSSL License change

[Bob Beck]

On Thu, Mar 23, 2017 at 17:48 Bob Beck  wrote:

> Honestly, anyone who gets one of these should say no
>
> what would you all think if people quietly took derived works of software
> licensed under one license and took silence as assent to relicense
>
> Does this mean that with an unanswered email i can now release my re
> licensed as ISC version of gcc?  or the linux kernel?
>
> This sort of action just means that any software you write can be
> plagiarized against your will if you did not find out about it in time.
>
> thats really not cool
>
> If you write software this is not a world you want to live in.   Even if
> it does mean a anyone who can fork a github repo could get rid of the GPL
> after a period of non response from an author (dont go on vacation). As
> much as I might not agree with the GPL personally, I respect someones right
> to release thier work under a license and have it respected. without having
> to constantly answer emails and click web links telling people no
>
>
>
> On Thu, Mar 23, 2017 at 10:58 Theo de Raadt  wrote:
>
> > > The start suggests they want to privately collect sufficient consensus
> > > to pass their agenda.  They appear to be considering all actions in
> > > the tree (including mine) on equal grounds.
> >
> > I already sent them a clear "NO, i explicitly object to relicensing
> > any of my contributions."
> >
> > If any of you care about the possibility of merging future OpenSSL
> > improvements to LibreSSL and OpenBSD, i suggest you do the same.
> >
> > Similarly, if any of you dislike publishing their own code under Apache
> 2.
>
> There has been no discussion amongst the greater community of
> developers as to which license to take.  Apache 2 has come as an edict
> from Rich Salz.
>
> There has also been no statement from the original authorship that this
> is the way to go.
>
> I suspect there is a lack of approval from some, and manufacturing
> consent in volume is the approach being taken.
>
>
> Apparently lawyers are being paid to help them push this through.  Is
> that being paid for by donations people gave after Heartbleed?  Is
> this why people donated?
>
>

Re: regarding OpenSSL License change

[Bob Beck]

Honestly, anyone who gets one of these should say no

what would you all think if people quietly took derived works of software
licensed under one license and took silence as assent to relicense

Does this mean that with an unanswered email i can now release my re
licensed as ISC version of gcc?  or the linux kernel?

This sort of action just means that any software you write can be
plagiarized against your will if you did not find out about it in time.

thats really not cool

If you write software this is not a world you want to live in.   Even if it
does mean a anyone who can fork a github repo could get rid of the GPL
after a period of non response from an author (dont go on vacation). As
much as I might not agree with the GPL personally, I respect someones right
to release thier work under a license and have it respected. without having
to constantly answer emails and click web links telling people no



On Thu, Mar 23, 2017 at 10:58 Theo de Raadt  wrote:

> > > The start suggests they want to privately collect sufficient consensus
> > > to pass their agenda.  They appear to be considering all actions in
> > > the tree (including mine) on equal grounds.
> >
> > I already sent them a clear "NO, i explicitly object to relicensing
> > any of my contributions."
> >
> > If any of you care about the possibility of merging future OpenSSL
> > improvements to LibreSSL and OpenBSD, i suggest you do the same.
> >
> > Similarly, if any of you dislike publishing their own code under Apache
> 2.
>
> There has been no discussion amongst the greater community of
> developers as to which license to take.  Apache 2 has come as an edict
> from Rich Salz.
>
> There has also been no statement from the original authorship that this
> is the way to go.
>
> I suspect there is a lack of approval from some, and manufacturing
> consent in volume is the approach being taken.
>
>
> Apparently lawyers are being paid to help them push this through.  Is
> that being paid for by donations people gave after Heartbleed?  Is
> this why people donated?
>
>

arm64 pmap asid handling

[Mark Kettenis]

So the diff below is my take on improving the arm64 pmap.  It assumes
we'll only ever run on CPUs that implement the full 16-bit ASID size.
In that case we have 64k of ASIDs available, hich is way larger than
the number of processes, and therefore pmaps, that can exist on an
OpenBSD system.  Our amd64 GENERIC.MP kernel has a maximum of 1310!

So we can simply allocate an ASID when we create a pmap, and free it
when we destroy it.  Allocation can be done by simply picking one at
random and check wether it is free.  If it isn't just try again.  This
is basically what we do for process ID.

This diff integrates Dale's diff that allocates an empty page table
for the lower half of the address space of the kernel pmap.  It
implements the changes I suggested when reviewing his diff.  We
reserve ASID 0 for the kernel pmap.  This way there is no reason to
special-case the kernel pmap when switching contexts.

Any remaining cached TLB entries are flushed just before an ASID is
made available for reallocation.

The ASIDs that are in use are tracked in a large bitmap.  I think this
will help SMP a great deal.  We just have to use an atomic operation
to set/clear the relevant bits.

All in all the code becomes a lot simpler.  Some further optimizations
are possible.

Thoughts?


Index: arch/arm64/arm64/cpufunc_asm.S
===
RCS file: /cvs/src/sys/arch/arm64/arm64/cpufunc_asm.S,v
retrieving revision 1.2
diff -u -p -r1.2 cpufunc_asm.S
--- arch/arm64/arm64/cpufunc_asm.S  12 Mar 2017 21:05:25 -  1.2
+++ arch/arm64/arm64/cpufunc_asm.S  23 Mar 2017 18:47:55 -
@@ -110,6 +110,14 @@ ENTRY(cpu_tlb_flush_all_asid)
ret
 END(cpu_tlb_flush_all_asid)
 
+ENTRY(cpu_tlb_flush_asid_all)
+   dsb ishst
+   tlbiaside1is, x0
+   dsb ish
+   isb
+   ret
+END(cpu_tlb_flush_asid_all)
+
 /*
  * void cpu_dcache_wb_range(vaddr_t, vsize_t)
  */
Index: arch/arm64/arm64/cpuswitch.S
===
RCS file: /cvs/src/sys/arch/arm64/arm64/cpuswitch.S,v
retrieving revision 1.1
diff -u -p -r1.1 cpuswitch.S
--- arch/arm64/arm64/cpuswitch.S17 Dec 2016 23:38:33 -  1.1
+++ arch/arm64/arm64/cpuswitch.S23 Mar 2017 18:47:55 -
@@ -65,17 +65,13 @@ ENTRY(cpu_switchto)
strbw5, [x1, #(P_STAT) ]// Mark new on cpu
ldr x5, [x1, #(P_ADDR) ]// load new pcb
str x5, [x2, #(CI_CURPCB)]
-   ldr x20, [x5, #(PCB_PAGEDIR)]
str x1, [x2, #(CI_CURPROC)]
 
ldr x4, [x5, #(PCB_TCB)]
msr tpidr_el0, x4   // load user tls
 
ldr x19, [x5, #(PCB_SP) ]   // load new stack pointer
-//msr  ttbr0_el1, x20
mov x0, x1
-   mov x1, x20
-   mov x2, x5
bl  pmap_setttb
mov x3, x19
 
Index: arch/arm64/arm64/genassym.cf
===
RCS file: /cvs/src/sys/arch/arm64/arm64/genassym.cf,v
retrieving revision 1.2
diff -u -p -r1.2 genassym.cf
--- arch/arm64/arm64/genassym.cf19 Feb 2017 19:42:40 -  1.2
+++ arch/arm64/arm64/genassym.cf23 Mar 2017 18:47:55 -
@@ -63,7 +63,6 @@ struct pcb
 member PCB_ONFAULT pcb_onfault
 member PCB_FLAGS pcb_flags
 member PCB_SP pcb_sp
-member PCB_PAGEDIR pcb_pagedir
 member PCB_TCB pcb_tcb
 
 struct trapframe
Index: arch/arm64/arm64/pmap.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/pmap.c,v
retrieving revision 1.27
diff -u -p -r1.27 pmap.c
--- arch/arm64/arm64/pmap.c 22 Mar 2017 10:47:29 -  1.27
+++ arch/arm64/arm64/pmap.c 23 Mar 2017 18:47:55 -
@@ -43,7 +43,7 @@
 
 #endif
 
-void pmap_setttb(struct proc *p, paddr_t pcb_pagedir, struct pcb *);
+void pmap_setttb(struct proc *p);
 void arm64_tlbi_asid(vaddr_t va, int asid);
 void pmap_free_asid(pmap_t pm);
 
@@ -907,8 +907,7 @@ pmap_pinit(pmap_t pm)
 
}
 
-   //pmap_allocate_asid(pm); // by default global (allocate asid later!?!)
-   pm->pm_asid = -1;
+   pmap_allocate_asid(pm);
 
pmap_extract(pmap_kernel(), l0va, (paddr_t *)>pm_pt0pa);
 
@@ -921,7 +920,7 @@ int pmap_vp_poolcache = 0; // force vp p
  * Create and return a physical map.
  */
 pmap_t
-pmap_create()
+pmap_create(void)
 {
pmap_t pmap;
 
@@ -960,9 +959,8 @@ pmap_destroy(pmap_t pm)
if (refs > 0)
return;
 
-   if (pm->pm_asid != -1) {
-   pmap_free_asid(pm);
-   }
+   pmap_free_asid(pm);
+
/*
 * reference count is zero, free pmap resources and free pmap.
 */
@@ -1139,7 +1137,7 @@ pmap_bootstrap(long kvo, paddr_t lpt1,  
 long ram_start, long ram_end)
 {
void  *va;
-   paddr_t pa;
+   paddr_t pa, pt1pa;
struct pmapvp1 *vp1;
struct pmapvp2 *vp2;
struct pmapvp3 

Re: mkdir(2): document EACCESS when no write permission

[Martin Natano]

On Thu, Mar 23, 2017 at 10:07:43AM -0600, Todd C. Miller wrote:
> From FreeBSD, POSIX has identical wording.
> 
> Alternately, we could add an extra EACCESS entry similar to what
> exists in open(2).  I'm happy with either approach.

OK natano@. I think using one entry is fine in this case as both
conditions are related to path resolution.

> 
>  - todd
> 
> Index: lib/libc/sys/mkdir.2
> ===
> RCS file: /cvs/src/lib/libc/sys/mkdir.2,v
> retrieving revision 1.17
> diff -u -p -u -r1.17 mkdir.2
> --- lib/libc/sys/mkdir.2  10 Sep 2015 17:55:21 -  1.17
> +++ lib/libc/sys/mkdir.2  23 Mar 2017 16:05:00 -
> @@ -101,7 +101,9 @@ bytes.
>  .It Bq Er ENOENT
>  A component of the path prefix does not exist.
>  .It Bq Er EACCES
> -Search permission is denied for a component of the path prefix.
> +Search permission is denied for a component of the path prefix,
> +or write permission is denied
> +on the parent directory of the directory to be created.
>  .It Bq Er ELOOP
>  Too many symbolic links were encountered in translating the pathname.
>  .It Bq Er EROFS
> 

Re: makefs: fix msdos create size

[Martin Natano]

On Wed, Mar 22, 2017 at 01:32:09PM +0100, Patrick Wildt wrote:
> 
> apparently the "create_size" option does currently not work.  This is
> because the strsuftoll() function uses "long long" compares which limits
> the positive maximum to LLONG_MAX.  Unfortunately the maximum is always
> set to ULLONG_MAX, which is treated as -1 and cannot be a reasonable
> maximum value.  This diff basically changes the maximum to LLONG_MAX.
> 
> Opinions? ok?

The two affected options (create_size and offset) are off_t, so your
diff makes sense. Go ahead.

> 
> Patrick
> 
> diff --git a/usr.sbin/makefs/msdos.c b/usr.sbin/makefs/msdos.c
> index a60af9adaa5..863349c09e4 100644
> --- a/usr.sbin/makefs/msdos.c
> +++ b/usr.sbin/makefs/msdos.c
> @@ -63,7 +63,7 @@ msdos_prep_opts(fsinfo_t *fsopts)
>   .minimum = _min,\
>   .maximum = sizeof(_type) == 1 ? 0xff :  \
>   (sizeof(_type) == 2 ? 0x :  \
> - (sizeof(_type) == 4 ? 0x : 0xLL)),  \
> + (sizeof(_type) == 4 ? 0x : 0x7fffLL)),  \
>  },
>  ALLOPTS
>  #undef AOPT
> 

Re: regarding OpenSSL License change

[Theo de Raadt]

> > The start suggests they want to privately collect sufficient consensus
> > to pass their agenda.  They appear to be considering all actions in
> > the tree (including mine) on equal grounds.
> 
> I already sent them a clear "NO, i explicitly object to relicensing
> any of my contributions."
> 
> If any of you care about the possibility of merging future OpenSSL
> improvements to LibreSSL and OpenBSD, i suggest you do the same.
> 
> Similarly, if any of you dislike publishing their own code under Apache 2.

There has been no discussion amongst the greater community of
developers as to which license to take.  Apache 2 has come as an edict
from Rich Salz.

There has also been no statement from the original authorship that this
is the way to go.

I suspect there is a lack of approval from some, and manufacturing
consent in volume is the approach being taken.


Apparently lawyers are being paid to help them push this through.  Is
that being paid for by donations people gave after Heartbleed?  Is
this why people donated?

Atheros AR9280+AR7010 USB stick don't work in BSS mode but Host AP

[Denis]

Have Atheros AR9280+AR7010 USB stick athn(4).
Long ago I tested it with OpenBSD 5.6 in Host AP mode 5GHz band, it does
not work as AP but successful in BSS in both supported bands.

On OpenBSD 6.0 situation is different. It is relatively stable in AP
mode, but don't work BSS in 2.4GHz band. On OpenBSD 5.6 it works fine in
BSS mode.

I don't know what happened, but it will be great to have BSS in 5GHz and
2.4GHz working as before.

I can test all the code modification if necessary.

Denis

Re: regarding OpenSSL License change

[Theo de Raadt]

> > The last sentence suggests they don't care at all about the rights of
> > the authors.
> 
> I also sent them a separate mail stating that i strongly suspect
> that last sentence to be grossly illegal in almost any jurisdiction.

Of course: Lack of consent is not equal to consent.

Re: regarding OpenSSL License change

[Ingo Schwarze]

Hi Theo,

Theo de Raadt wrote on Thu, Mar 23, 2017 at 10:18:26AM -0600:

> Lots of people have been receiving emails like the one below.
> 
> They have never asked the community of authors what they want.
> 
> I think OpenSSL are using a github "garbage-in / garbage-out" style of
> process.  Feel free to dig into what they think I am author of, and
> why.
>
> We wrote some tools to look through every version of our files, and
> our scripts found your email address.  You can see what we found:
> 
> https://license.openssl.org/cgi-bin/lookup.py?uid=619

ROFL...  :-D

Maybe they should just revert

https://github.com/openssl/openssl/commit/58964a492275ca9a59a0cd9c8155cb2491b4b909

and be done with it.  :-D


> The start suggests they want to privately collect sufficient consensus
> to pass their agenda.  They appear to be considering all actions in
> the tree (including mine) on equal grounds.

I already sent them a clear "NO, i explicitly object to relicensing
any of my contributions."

If any of you care about the possibility of merging future OpenSSL
improvements to LibreSSL and OpenBSD, i suggest you do the same.

Similarly, if any of you dislike publishing their own code under Apache 2.


> The last sentence suggests they don't care at all about the rights of
> the authors.

I also sent them a separate mail stating that i strongly suspect
that last sentence to be grossly illegal in almost any jurisdiction.

Yours,
  Ingo

Ralink (MediaTek) MT7650 / MT7610 usb stick problem with run(4) driver

[Denis]

Having trouble with TP-LINK AC600 Archer T2UH based on Ralink's MT7650
chipset with run driver on OpenBSD 6.0-stable with all the latest source
tree patches installed.

Just after I've added MT7650 by patching files listed below and
recompiled the kernel the USB stick shows its identities as:

run0 at uhub0 port 2 configuration 1 interface 0 "MediaTek WiFi" rev
2.01/1.00 addr 2
run0: MAC/BBP RT7650 (rev 0x2000), RF RT3053 (MIMO 1T1R), address  "MAC"

During boot It configured to associate with AP in BSS mode and having IP
address from DHCP.

$ cat hostname.run0
dhcp media autoselect mode 11g nwid NAME wpa wpakey KEY chan 11

while issuing # sh /etc/netstart run0 command I have error message:

run0: timeout waiting for MCU to initialize
run0: could not load 8051 microcode

To test it out I've downloaded win7 driver and extract the firmware
files from it
mt7650.bin , mt7610.bin. Renamed them to run-mt7650 and run-mt7610
respectively and put into /etc/firmware
When I added firmware in the source (as shown below) and rebuild the
kernel afterwards.

While boot when DHCP requests are sent by network adapters I have the
same meessage "run0: could not load 8051 microcode"

--- /usr/src/sys/dev/usb/usbdevs.h.oldThu Mar 23 19:00:27 2017
+++ /usr/src/sys/dev/usb/usbdevs.hThu Mar 23 16:33:07 2017
@@ -3550,6 +3550,7 @@
 #defineUSB_PRODUCT_RALINK_RT35730x3573/* RT3573 */
 #defineUSB_PRODUCT_RALINK_RT55720x5572/* RT5572 */
 #defineUSB_PRODUCT_RALINK_MT76010x7601/* MT7601 */
+#defineUSB_PRODUCT_RALINK_MT76500x761A/* MT7650 */
 #defineUSB_PRODUCT_RALINK_RT80700x8070/* RT8070 */
 #defineUSB_PRODUCT_RALINK_RT2570_30x9020/* RT2570 */
 #defineUSB_PRODUCT_RALINK_RT2573_20x9021/* RT2573 */


--- /usr/src/sys/dev/usb/if_run.c.oldThu Mar 23 18:59:36 2017
+++ /usr/src/sys/dev/usb/if_run.cThu Mar 23 19:02:46 2017
@@ -257,6 +257,7 @@
 USB_ID(RALINK,RT3573),
 USB_ID(RALINK,RT5370),
 USB_ID(RALINK,RT5572),
+USB_ID(RALINK,MT7650),
 USB_ID(RALINK,RT8070),
 USB_ID(SAMSUNG,WIS09ABGN),
 USB_ID(SAMSUNG2,RT2870_1),
@@ -830,7 +831,7 @@
 if (sc->mac_ver != 0x2860 &&
 sc->mac_ver != 0x2872 &&
 sc->mac_ver != 0x3070)
-fwname = "run-rt3071";
+fwname = "run-mt7610";
 else
 fwname = "run-rt2870";
 
@@ -839,13 +840,13 @@
 sc->sc_dev.dv_xname, fwname, error);
 return error;
 }
-if (size != 4096) {
+/*if (size != 4096) {
 printf("%s: invalid firmware size (should be 4KB)\n",
 sc->sc_dev.dv_xname);
 free(ucode, M_DEVBUF, 0);
 return EINVAL;
 }
-
+*/
 run_read(sc, RT2860_ASIC_VER_ID, );
 /* write microcode image */
 run_write_region_1(sc, RT2870_FW_BASE, ucode, size);

--

regarding OpenSSL License change

[Theo de Raadt]

Lots of people have been receiving emails like the one below.

They have never asked the community of authors what they want.

I think OpenSSL are using a github "garbage-in / garbage-out" style of
process.  Feel free to dig into what they think I am author of, and
why.

The start suggests they want to privately collect sufficient consensus
to pass their agenda.  They appear to be considering all actions in
the tree (including mine) on equal grounds.

The last sentence suggests they don't care at all about the rights of
the authors.





Date: Wed, 22 Mar 2017 16:48:10 -0400
From: lice...@openssl.org
To: dera...@cvs.openbsd.org
Subject: OpenSSL License change
Message-ID: <20170322204810.ra49wtmwn%lice...@openssl.org>
User-Agent: s-nail v14.8.6
Status: O

Hello!

This mail is coming from the OpenSSL development team.

This is a pre-release email before we "go public."  In particular,
the most recent blog entry, listed below, is not yet available.  But we
thought, as an important downstream fork, that we'd give you the courtesy
of participating early.

We are working to change the license for OpenSSL. We want to move from
the current license (which is custom-written and has some uncommon
requirements on end-users), to the widely-accepted and common 
Apache License (version 2).  You can find some explanation in
our blog entries:

https://www.openssl.org/blog/blog/2017/03/20/license/
https://www.openssl.org/blog/blog/2015/08/01/cla/

We wrote some tools to look through every version of our files, and
our scripts found your email address.  You can see what we found:

https://license.openssl.org/cgi-bin/lookup.py?uid=619

We are asking for your permission to change the licence for your
contribution. Please visit this link to respond; you will have a chance
to accept or decline, and enter a brief comment (you can use the comment
to give the names of other people we should contact, for example):

https://license.openssl.org/cgi-bin/reply.py?uid=619=pCUKaKssFLWJztCE8FHe

If you have any questions or concerns, send email to lice...@openssl.org;
please be patient for a response. You can also post to the public mailing
list, openssl-...@openssl.org; details about that list can be found at this
site:

https://mta.openssl.org/mailman/listinfo/openssl-dev

If we do not hear from you, we will assume that you have no objection.

Thank you!

-The OpenSSL Development Team

mkdir(2): document EACCESS when no write permission

[Todd C. Miller]

>From FreeBSD, POSIX has identical wording.

Alternately, we could add an extra EACCESS entry similar to what
exists in open(2).  I'm happy with either approach.

 - todd

Index: lib/libc/sys/mkdir.2
===
RCS file: /cvs/src/lib/libc/sys/mkdir.2,v
retrieving revision 1.17
diff -u -p -u -r1.17 mkdir.2
--- lib/libc/sys/mkdir.210 Sep 2015 17:55:21 -  1.17
+++ lib/libc/sys/mkdir.223 Mar 2017 16:05:00 -
@@ -101,7 +101,9 @@ bytes.
 .It Bq Er ENOENT
 A component of the path prefix does not exist.
 .It Bq Er EACCES
-Search permission is denied for a component of the path prefix.
+Search permission is denied for a component of the path prefix,
+or write permission is denied
+on the parent directory of the directory to be created.
 .It Bq Er ELOOP
 Too many symbolic links were encountered in translating the pathname.
 .It Bq Er EROFS

[PATCH] pcidump - Enhanced Capabilities

[Simon Mages]

Hi,

on some machines i saw some unknown enhanced capabilities. After
looking into it i saw that
on some intel chipsets there actually is a capability with id 0x0.
This capability contains some
registers of the Advanced Error Reporting Capability but not all of
them. I guess intel choose
0x0 instead of 0x1 because there implementation contains not all of
the minimal Advanced
Error Reporting registers.

Anyway, i think it makes sense to print the enhanced capability id,
even if it is not in the list.
This way one does not have to look at the hexdump of pcidump -xxx to
figure out which
capability id the unknown capability has.

Index: usr.sbin/pcidump/pcidump.c
===
--- pcidump.c   16 Mar 2017 22:05:46 -  1.42
+++ pcidump.c   23 Mar 2017 15:12:07 -
@@ -392,6 +392,7 @@ void
 dump_pcie_enhanced_caplist(int bus, int dev, int func)
 {
u_int32_t reg;
+   u_int32_t capidx;
u_int16_t ptr;
u_int16_t ecap;

@@ -407,10 +408,12 @@ dump_pcie_enhanced_caplist(int bus, int

ecap = PCI_PCIE_ECAP_ID(reg);
if (ecap >= nitems(pci_enhanced_capnames))
-   ecap = 0;
+   capidx = 0;
+   else
+   capidx = ecap;

printf("\t0x%04x: Enhanced Capability 0x%02x: ", ptr, ecap);
-   printf("%s\n", pci_enhanced_capnames[ecap]);
+   printf("%s\n", pci_enhanced_capnames[capidx]);

ptr = PCI_PCIE_ECAP_NEXT(reg);


According to Rev. 3.0 of the PCIe spec, the last two bits are reserved
for future use. I do not
have access to the spec > Rev. 3.0.

Index: dev/pci/pcireg.h
===
--- dev/pci/pcireg.h22 Mar 2017 07:21:39 -  1.52
+++ dev/pci/pcireg.h23 Mar 2017 13:36:09 -
@@ -606,7 +606,7 @@ typedef u_int8_t pci_revision_t;
 #define PCI_PCIE_ECAP  0x100
 #definePCI_PCIE_ECAP_ID(x) (((x) & 0x))
 #define PCI_PCIE_ECAP_VER(x)   (((x) >> 16) & 0x0f)
-#definePCI_PCIE_ECAP_NEXT(x)   ((x) >> 20)
+#definePCI_PCIE_ECAP_NEXT(x)   (((x) >> 20) & 0xffc)
 #define PCI_PCIE_ECAP_LAST 0x0

 /*

Re: acme-client(1): remove useless owner check

[Sebastian Benoit]

i never was happy with that anyway. ok

Florian Obser(flor...@openbsd.org) on 2017.03.23 12:04:56 +:
> 
> Prosody starts up as _prosody so key and cert are owned by
> that user, which is perfectly valid.
> Also "current user" will always be root anyway.
> 
> OK?
> 
> diff --git parse.y parse.y
> index 1595b52a752..6ee026c2427 100644
> --- parse.y
> +++ parse.y
> @@ -1034,10 +1034,6 @@ conf_check_file(char *s, int dontstat)
>   warn("cannot stat %s", s);
>   return (0);
>   }
> - if (st.st_uid != 0 && st.st_uid != getuid()) {
> - warnx("%s: owner not root or current user", s);
> - return (0);
> - }
>   if (st.st_mode & (S_IRWXG | S_IRWXO)) {
>   warnx("%s: group read/writable or world read/writable", s);
>   return (0);
> 
> 
> -- 
> I'm not entirely sure you are real.
> 

Re: acme-client(1): move root check up

[Sebastian Benoit]

ok

Florian Obser(flor...@openbsd.org) on 2017.03.23 12:02:52 +:
> ... the parser will bomb out anyway
> 
> OK?
> 
> diff --git main.c main.c
> index dde8e8b638e..4f977451bbc 100644
> --- main.c
> +++ main.c
> @@ -85,6 +85,9 @@ main(int argc, char *argv[])
>   goto usage;
>   }
>  
> + if (getuid() != 0)
> + errx(EXIT_FAILURE, "must be run as root");
> +
>   /* parse config file */
>   if ((conf = parse_config(conffile, popts)) == NULL)
>   exit(EXIT_FAILURE);
> @@ -100,9 +103,6 @@ main(int argc, char *argv[])
>   argc--;
>   argv++;
>  
> - if (getuid() != 0)
> - errx(EXIT_FAILURE, "must be run as root");
> -
>   if (domain->cert != NULL) {
>   if ((certdir = dirname(domain->cert)) != NULL) {
>   if ((certdir = strdup(certdir)) == NULL)
> 
> 
> -- 
> I'm not entirely sure you are real.
> 

acme-client(1): remove useless owner check

[Florian Obser]

Prosody starts up as _prosody so key and cert are owned by
that user, which is perfectly valid.
Also "current user" will always be root anyway.

OK?

diff --git parse.y parse.y
index 1595b52a752..6ee026c2427 100644
--- parse.y
+++ parse.y
@@ -1034,10 +1034,6 @@ conf_check_file(char *s, int dontstat)
warn("cannot stat %s", s);
return (0);
}
-   if (st.st_uid != 0 && st.st_uid != getuid()) {
-   warnx("%s: owner not root or current user", s);
-   return (0);
-   }
if (st.st_mode & (S_IRWXG | S_IRWXO)) {
warnx("%s: group read/writable or world read/writable", s);
return (0);


-- 
I'm not entirely sure you are real.

acme-client(1): move root check up

[Florian Obser]

... the parser will bomb out anyway

OK?

diff --git main.c main.c
index dde8e8b638e..4f977451bbc 100644
--- main.c
+++ main.c
@@ -85,6 +85,9 @@ main(int argc, char *argv[])
goto usage;
}
 
+   if (getuid() != 0)
+   errx(EXIT_FAILURE, "must be run as root");
+
/* parse config file */
if ((conf = parse_config(conffile, popts)) == NULL)
exit(EXIT_FAILURE);
@@ -100,9 +103,6 @@ main(int argc, char *argv[])
argc--;
argv++;
 
-   if (getuid() != 0)
-   errx(EXIT_FAILURE, "must be run as root");
-
if (domain->cert != NULL) {
if ((certdir = dirname(domain->cert)) != NULL) {
if ((certdir = strdup(certdir)) == NULL)


-- 
I'm not entirely sure you are real.

Re: backport lld version string change

[Mark Kettenis]

> Date: Thu, 23 Mar 2017 14:34:48 +1100
> From: Jonathan Gray 
> 
> Backport a change to add "(compatible with GNU linkers)" to the lld
> version output to avoid having to regenerate a large number of configure
> scripts.
> 
> https://reviews.llvm.org/D31199?id=
> http://llvm.org/viewvc/llvm-project?view=revision=298532
> 
> The output is now
> 
> LLD 4.0.0 (compatible with GNU linkers)
> 
> Among other things this is required to build xenocara on arm64 without
> patching libtool and regenerating the configure script for Mesa.

Go for it.

> Index: ELF/Driver.cpp
> ===
> RCS file: /cvs/src/gnu/llvm/tools/lld/ELF/Driver.cpp,v
> retrieving revision 1.5
> diff -u -p -r1.5 Driver.cpp
> --- ELF/Driver.cpp18 Mar 2017 16:36:56 -  1.5
> +++ ELF/Driver.cpp23 Mar 2017 00:34:19 -
> @@ -281,11 +281,27 @@ void LinkerDriver::main(ArrayRef  return;
>}
>  
> -  // GNU linkers disagree here. Though both -version and -v are mentioned
> -  // in help to print the version information, GNU ld just normally exits,
> -  // while gold can continue linking. We are compatible with ld.bfd here.
> +  // Handle -v or -version.
> +  //
> +  // A note about "compatible with GNU linkers" message: this is a hack for
> +  // scripts generated by GNU Libtool 2.4.6 (released in February 2014 and
> +  // still the newest version in March 2017) or earlier to recognize LLD as
> +  // a GNU compatible linker. As long as an output for the -v option
> +  // contains "GNU" or "with BFD", they recognize us as GNU-compatible.
> +  //
> +  // This is somewhat ugly hack, but in reality, we had no choice other
> +  // than doing this. Considering the very long release cycle of Libtool,
> +  // it is not easy to improve it to recognize LLD as a GNU compatible
> +  // linker in a timely manner. Even if we can make it, there are still a
> +  // lot of "configure" scripts out there that are generated by old version
> +  // of Libtool. We cannot convince every software developer to migrate to
> +  // the latest version and re-generate scripts. So we have this hack.
>if (Args.hasArg(OPT_version) || Args.hasArg(OPT_v))
> -outs() << getLLDVersion() << "\n";
> +outs() << getLLDVersion() << " (compatible with GNU linkers)\n";
> +
> +  // ld.bfd always exits after printing out the version string.
> +  // ld.gold proceeds if a given option is -v. Because gold's behavior
> +  // is more permissive than ld.bfd, we chose what gold does here.
>if (Args.hasArg(OPT_version))
>  return;
>  
> 
>