Re: C startup code: make crtbegin code safe for clang
On Mon, Aug 1, 2016 at 11:45 AM, Mark Kettenis wrote: >> From: j...@wxcvbn.org (Jeremie Courreges-Anglas) >> Date: Mon, 01 Aug 2016 20:30:33 +0200 >> >> Stefan Kempf writes: >> >> > The constructor and destructor tables are declared as arrays with one >> > non-NULL element. Walking those until a NULL element is reached looks >> > like out-of-bound accesses to newer compilers, and they turn the code >> > into infinite loops (e.g. clang 3.8), because it is undefined behavior. So it needs to reference the pointers via an extern incomplete array? Can we move to setting up the leading count via the linker script magic documented in the ld info page, and then just use __CTOR_LIST__ as the extern array? >> > While there, clean up crtbegin.c and crtbegin.S a little and make them >> > more similar. I'm fine with this being done...once we sure we actually have nailed down what are the actual changes necessary to get the code to compile correctly without changing behavior. ... >> The existing code tries to retrieve the number of valid ctors entries >> from __CTOR_LIST__[0], only when that number is -1 it tries to find >> the actual value by walking the array. Since we only have one version of ld doing linking now, can't we switch from the -1 to the real count version? ... > Also, aren't ctor_list and dtor_list polluting the namespace? Yep. Philip
confpars.c patch
I'm not sure if this was intentional or not, but here is a small diff
for usr.sbin/dhcpd/confpars.c.
--
Edgar Pettijohn
Index: confpars.c
===
RCS file: /cvs/src/usr.sbin/dhcpd/confpars.c,v
retrieving revision 1.26
diff -u -p -u -r1.26 confpars.c
--- confpars.c 6 Feb 2016 23:50:10 - 1.26
+++ confpars.c 2 Aug 2016 03:57:41 -
@@ -176,13 +176,9 @@ read_leases(void)
| VENDOR_CLASS class-declaration
| USER_CLASS class-declaration
| RANGE address-range-declaration */
-
-int parse_statement(cfile, group, type, host_decl, declaration)
- FILE *cfile;
- struct group *group;
- int type;
- struct host_decl *host_decl;
- int declaration;
+int
+parse_statement(FILE *cfile, struct group *group, int type,
+ struct host_decl *host_decl, int declaration)
{
int token;
char *val;
LibreSSL 2.4.2 and 2.3.7 released
We have released LibreSSL 2.4.2 and 2.3.7, which will be arriving in the LibreSSL directory of your local OpenBSD mirror soon. LibreSSL 2.4.2 is based on the new OpenBSD 6.0 release branch, and is now the current stable version. LibreSSL 2.3.7 is based on the previous OpenBSD 5.9 release, and will be supported for one more release cycle. LibreSSL 2.2.x support has now ended. LibreSSL 2.4.2 and 2.3.7 contain the following changes: * Fixed several issues in the OCSP code that could result in the incorrect generation and parsing of OCSP requests. This remediates a lack of error checking on time parsing in these functions, and ensures that only GENERALIZEDTIME formats are accepted for OCSP, as per RFC 6960. Issues reported, and fixes provided by Kazuki Yamaguchi and Kinichiro Inoguchi LibreSSL 2.4.2 contains additional changes: * Fixed loading default certificate locations with openssl s_client. * Improved behavior of arc4random on Windows to not appear to leak memory in debug tools, reduced privileges of allocated memory. * Fixed incorrect results from BN_mod_word() when the modulus is too large, thanks to Brian Smith from BoringSSL. * Correctly handle an EOF prior to completing the TLS handshake in libtls. * Improved libtls ceritificate loading and cipher string validation. * Updated libtls cipher group suites into four categories: "secure" (TLSv1.2+AEAD+PFS) "compat" (HIGH:!aNULL) "legacy" (HIGH:MEDIUM:!aNULL) "insecure" (ALL:!aNULL:!eNULL) This allows for flexibility and finer grained control, rather than having two extremes. * Limited support for 'backward compatible' SSLv2 handshake packets to when TLS 1.0 is enabled, providing more restricted compatibility with TLS 1.0 clients. * openssl(1) and other documentation improvements. * Removed flags for disabling constant-time operations. This removes support for DSA_FLAG_NO_EXP_CONSTTIME, DH_FLAG_NO_EXP_CONSTTIME, and RSA_FLAG_NO_CONSTTIME flags, making all of these operations unconditionally constant-time. The LibreSSL project continues improvement of the codebase to reflect modern, safe programming practices. We welcome feedback and improvements from the broader community. Thanks to all of the contributors who helped make this release possible.
Re: armv7 pmap fix for Cortex A53 (and Cortex A7?)
On Mon, Aug 01, 2016 at 10:19:17PM -0300, Daniel Bolgheroni wrote: > On Sun, Jul 31, 2016 at 08:03:58PM +0200, Mark Kettenis wrote: > > So the CPU might speculatively load TLB entries. The upshot from this > > is that we always have to perform a TLB flush if we modify a valid > > entry. So we can't rely on PV_BEEN_REFD() to decide whether we should > > flush or not. The diff below fixes thi. The diff seems to fix the > > pmap_fault_fixup() messages on a Cortex A53 system. It's very likely > > that this will fix them on Cortex A7 as well. > > Tested on Cortex-A8 and it seems ok. My bad. This is related to the unified TLBs diff. -- db
Re: armv7 pmap fix for Cortex A53 (and Cortex A7?)
On Sun, Jul 31, 2016 at 08:03:58PM +0200, Mark Kettenis wrote: > So the CPU might speculatively load TLB entries. The upshot from this > is that we always have to perform a TLB flush if we modify a valid > entry. So we can't rely on PV_BEEN_REFD() to decide whether we should > flush or not. The diff below fixes thi. The diff seems to fix the > pmap_fault_fixup() messages on a Cortex A53 system. It's very likely > that this will fix them on Cortex A7 as well. Tested on Cortex-A8 and it seems ok. -- U-Boot SPL 2016.07 (Jul 12 2016 - 14:45:59) Trying to boot from MMC1 MMC partition switch failed *** Warning - MMC partition switch failed, using default environment reading u-boot.img reading u-boot.img U-Boot 2016.07 (Jul 12 2016 - 14:45:59 +1000) Watchdog enabled I2C: ready DRAM: 512 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - bad CRC, using default environment Net:not set. Validating first E-fuse MAC cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 reading boot.scr ** Unable to read file boot.scr ** reading uEnv.txt ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... reading /am335x-boneblack.dtb 32577 bytes read in 9 ms (3.5 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi reading efi/boot/bootarm.efi 65276 bytes read in 14 ms (4.4 MiB/s) ## Starting EFI application at 0x8200 ... Scanning disks on usb... Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 6 disks >> OpenBSD/armv7 BOOTARM 0.1 boot> boot tbsd booting sd0a:tbsd: 3674688+100668+479244 [64+490880+230122]=0x4c5b68 OpenBSD/armv7 booting ... arg0 0x8000 arg1 0xe05 arg2 0x8800 Allocating page tables freestart = 0x807c6000, free_pages = 129082 (0x0001f83a) IRQ stack: p0x807f4000 v0xc07f4000 ABT stack: p0x807f5000 v0xc07f5000 UND stack: p0x807f6000 v0xc07f6000 SVC stack: p0x807f7000 v0xc07f7000 Creating L1 page table at 0x807c8000 Mapping kernel Constructing L2 page tables undefined page pmap [ using 721440 bytes of bsd ELF symbol table ] board type: 3589 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2016 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 6.0-current (GENERIC) #0: Mon Aug 1 18:57:26 BRT 2016 dbolgher...@wbs.my.domain:/usr/src/sys/arch/armv7/compile/GENERIC real mem = 536870912 (512MB) avail mem = 518017024 (494MB) mainbus0 at root: TI AM335x BeagleBone Black cpu0 at mainbus0: ARM Cortex A8 R3 rev 2 (ARMv7 core) cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu0: 32KB(64b/l,4way) I-cache, 32KB(64b/l,4way) wr-back D-cache omap0 at mainbus0 prcm0 at omap0 rev 0.2 sitaracm0 at omap0: control module, rev 1.0 intc0 at omap0 rev 5.0 edma0 at omap0 rev 0.0 dmtimer0 at omap0 rev 3.1 dmtimer1 at omap0 rev 3.1 omgpio0 at omap0: rev 0.1 gpio0 at omgpio0: 32 pins omgpio1 at omap0: rev 0.1 gpio1 at omgpio1: 32 pins omgpio2 at omap0: rev 0.1 gpio2 at omgpio2: 32 pins omgpio3 at omap0: rev 0.1 gpio3 at omgpio3: 32 pins simplebus0 at mainbus0: "ocp" simplebus1 at simplebus0: "l4_wkup" simplebus2 at simplebus1: "scm" com0 at simplebus0: ti16750, 64 byte fifo com0: console tiiic0 at simplebus0 rev 0.11 iic0 at tiiic0 "ti,tps65217" at iic0 addr 0x24 not configured "at,24c256" at iic0 addr 0x50 not configured "nxp,tda998x" at iic0 addr 0x70 not configured tiiic1 at simplebus0 rev 0.11 iic1 at tiiic1 "at,24c256" at iic1 addr 0x54 not configured "at,24c256" at iic1 addr 0x55 not configured "at,24c256" at iic1 addr 0x56 not configured "at,24c256" at iic1 addr 0x57 not configured ommmc0 at simplebus0 sdmmc0 at ommmc0: 1-bit, mmc high-speed ommmc1 at simplebus0 sdmmc1 at ommmc1: 1-bit, mmc high-speed omdog0 at simplebus0 rev 0.1 cpsw0 at simplebus0: version 1.12 (0), address 1c:ba:8c:97:a7:03 ukphy0 at cpsw0 phy 0: Generic IEEE 802.3u media interface, rev. 1: OUI 0x0001f0, model 0x000f scsibus0 at sdmmc0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: SCSI2 0/direct fixed sd0: 15193MB, 512 bytes/sector, 31116288 sectors scsibus1 at sdmmc1: 2 targets, initiator 0 sd1 at scsibus1 targ 1 lun 0: SCSI2 0/direct fixed sd1: 1832MB, 512 bytes/sector, 3751936 sectors vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets boot device: sd0 root on sd0a (fe311afb0f7c1b3f.a) swap on sd0b dump on sd0b WARNING: CHECK AND RESET THE DATE! Automatic boot in progress: starting file system checks. /dev/sd0a (fe311afb0f7c1b3f.a): file system is clean; not checking /dev/sd0j (fe311afb0f7c1b3f.j): file system is clean; not checking /dev/sd0d (fe311afb0f7c1b3f.d): file system is clean; not checking /dev/sd0f (fe311afb0f7c1b3f.f): file system is clean; not checking /dev/sd0g (fe311afb0f7c1b3f.g): file system is clean; not checking /dev/sd0h (fe311afb0f7c1b3f.h): file system is
Re: [PATCH] shutdown: dot not write non-printable characters to wall(1)
On 22:31 Mon 01 Aug, Martijn van Duren wrote: > On 08/01/16 20:58, Consus wrote: > > The wall(1) utility now replaces non-printable ASCII characters with a > > quotation mark. This results in a funny message: > > > > ?*** System shutdown message from consus@localhost ***? > > > > This patch fixes the issue by removing '\007' from the shutdown > > notification. > > Fixed in wall(1). Thanks for the report. Great, thank you!
Re: [PATCH] shutdown: dot not write non-printable characters to wall(1)
On 08/01/16 20:58, Consus wrote: > The wall(1) utility now replaces non-printable ASCII characters with a > quotation mark. This results in a funny message: > > ?*** System shutdown message from consus@localhost ***? > > This patch fixes the issue by removing '\007' from the shutdown > notification. Fixed in wall(1). Thanks for the report.
Re: [Bug 64] Any user can trigger a panic in mmap with an overlapping mapping
Yup, waiting a day or two is no problem, we’re happy to wait until you guys have a patch/errata ready :) > On Aug 1, 2016, at 3:23 PM, Tim Newsham wrote: > > Yup. Thank you! > > On Mon, Aug 1, 2016 at 9:17 AM, Bob Beck wrote: > >> And just to confirm tim, we're sorting out the nature of a minimal patch >> for a possible errata, and we'll >> need to get the errata signed. I don't anticipate this will be more than a >> day or two if you can wait that long. >> >> >> On Mon, Aug 1, 2016 at 1:09 PM, Mark Kettenis >> wrote: >> From: Jesse Hertz Date: Mon, 1 Aug 2016 14:38:19 -0400 Hi All, Is a fix for this in the works? We'd like to be able to point to a fix before posting to oss-sec :) >>> >>> Hi Jesse, >>> >>> The fix suggested in the analysis has been committed, and we have >>> committed two other fixes to prevent against overflows/underflows in >>> related uvm code. Not sure if somebody is doing an errata for -stable >>> for this. >>> >>> CVSROOT:/cvs >>> Module name:src >>> Changes by: t...@cvs.openbsd.org2016/07/29 14:44:40 >>> >>> Modified files: >>>sys/uvm: uvm_map.c >>> >>> Log message: >>> add a check that the arguments to isavail don't overflow. >>> callers should probably check too, but checking here won't hurt. >>> possible panic reported by tim newsham. >>> ok kettenis >>> >>> >>> CVSROOT:/cvs >>> Module name:src >>> Changes by: kette...@cvs.openbsd.org2016/07/30 10:37:55 >>> >>> Modified files: >>>sys/uvm: uvm_addr.c >>> >>> Log message: >>> Add a few checks for potential integer overflow and underflow related to >>> the >>> size of an address range. >>> >>> ok deraadt@, tedu@ >>> >>> >>> CVSROOT:/cvs >>> Module name:src >>> Changes by: kette...@cvs.openbsd.org2016/07/30 10:43:44 >>> >>> Modified files: >>>sys/uvm: uvm_map.c >>> >>> Log message: >>> Check for wraparound before the "commit" phase of uvm_map() and >>> uvm_mapanon(), >>> to prevent hitting assertions and/or corrupting data structures during >> that >>> phase. >>> >>> ok deraadt@, tedu@ >>> >>> >>> >>> >> > > > > -- > Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PATCH] shutdown: dot not write non-printable characters to wall(1)
On 13:06 Mon 01 Aug, Andy Bradford wrote: > Thus said Consus on Mon, 01 Aug 2016 21:58:16 +0300: > > > This patch fixes the issue by removing '\007' from the shutdown > > notification. > > Do ttys no longer understand bel? It won't hit a tty because wall(1) will replace it with '?' before writing. See the diff for yourself: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/wall/wall.c.diff?r1=1.29&r2=1.30
Re: [Bug 64] Any user can trigger a panic in mmap with an overlapping mapping
Yup. Thank you! On Mon, Aug 1, 2016 at 9:17 AM, Bob Beck wrote: > And just to confirm tim, we're sorting out the nature of a minimal patch > for a possible errata, and we'll > need to get the errata signed. I don't anticipate this will be more than a > day or two if you can wait that long. > > > On Mon, Aug 1, 2016 at 1:09 PM, Mark Kettenis > wrote: > > > > From: Jesse Hertz > > > Date: Mon, 1 Aug 2016 14:38:19 -0400 > > > > > > Hi All, > > > > > > Is a fix for this in the works? We'd like to be able to point to a > > > fix before posting to oss-sec :) > > > > Hi Jesse, > > > > The fix suggested in the analysis has been committed, and we have > > committed two other fixes to prevent against overflows/underflows in > > related uvm code. Not sure if somebody is doing an errata for -stable > > for this. > > > > CVSROOT:/cvs > > Module name:src > > Changes by: t...@cvs.openbsd.org2016/07/29 14:44:40 > > > > Modified files: > > sys/uvm: uvm_map.c > > > > Log message: > > add a check that the arguments to isavail don't overflow. > > callers should probably check too, but checking here won't hurt. > > possible panic reported by tim newsham. > > ok kettenis > > > > > > CVSROOT:/cvs > > Module name:src > > Changes by: kette...@cvs.openbsd.org2016/07/30 10:37:55 > > > > Modified files: > > sys/uvm: uvm_addr.c > > > > Log message: > > Add a few checks for potential integer overflow and underflow related to > > the > > size of an address range. > > > > ok deraadt@, tedu@ > > > > > > CVSROOT:/cvs > > Module name:src > > Changes by: kette...@cvs.openbsd.org2016/07/30 10:43:44 > > > > Modified files: > > sys/uvm: uvm_map.c > > > > Log message: > > Check for wraparound before the "commit" phase of uvm_map() and > > uvm_mapanon(), > > to prevent hitting assertions and/or corrupting data structures during > that > > phase. > > > > ok deraadt@, tedu@ > > > > > > > > > -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com
Re: [Bug 64] Any user can trigger a panic in mmap with an overlapping mapping
And just to confirm tim, we're sorting out the nature of a minimal patch for a possible errata, and we'll need to get the errata signed. I don't anticipate this will be more than a day or two if you can wait that long. On Mon, Aug 1, 2016 at 1:09 PM, Mark Kettenis wrote: > > From: Jesse Hertz > > Date: Mon, 1 Aug 2016 14:38:19 -0400 > > > > Hi All, > > > > Is a fix for this in the works? We'd like to be able to point to a > > fix before posting to oss-sec :) > > Hi Jesse, > > The fix suggested in the analysis has been committed, and we have > committed two other fixes to prevent against overflows/underflows in > related uvm code. Not sure if somebody is doing an errata for -stable > for this. > > CVSROOT:/cvs > Module name:src > Changes by: t...@cvs.openbsd.org2016/07/29 14:44:40 > > Modified files: > sys/uvm: uvm_map.c > > Log message: > add a check that the arguments to isavail don't overflow. > callers should probably check too, but checking here won't hurt. > possible panic reported by tim newsham. > ok kettenis > > > CVSROOT:/cvs > Module name:src > Changes by: kette...@cvs.openbsd.org2016/07/30 10:37:55 > > Modified files: > sys/uvm: uvm_addr.c > > Log message: > Add a few checks for potential integer overflow and underflow related to > the > size of an address range. > > ok deraadt@, tedu@ > > > CVSROOT:/cvs > Module name:src > Changes by: kette...@cvs.openbsd.org2016/07/30 10:43:44 > > Modified files: > sys/uvm: uvm_map.c > > Log message: > Check for wraparound before the "commit" phase of uvm_map() and > uvm_mapanon(), > to prevent hitting assertions and/or corrupting data structures during that > phase. > > ok deraadt@, tedu@ > > > >
Re: [Bug 64] Any user can trigger a panic in mmap with an overlapping mapping
> From: Jesse Hertz > Date: Mon, 1 Aug 2016 14:38:19 -0400 > > Hi All, > > Is a fix for this in the works? We'd like to be able to point to a > fix before posting to oss-sec :) Hi Jesse, The fix suggested in the analysis has been committed, and we have committed two other fixes to prevent against overflows/underflows in related uvm code. Not sure if somebody is doing an errata for -stable for this. CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2016/07/29 14:44:40 Modified files: sys/uvm: uvm_map.c Log message: add a check that the arguments to isavail don't overflow. callers should probably check too, but checking here won't hurt. possible panic reported by tim newsham. ok kettenis CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2016/07/30 10:37:55 Modified files: sys/uvm: uvm_addr.c Log message: Add a few checks for potential integer overflow and underflow related to the size of an address range. ok deraadt@, tedu@ CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2016/07/30 10:43:44 Modified files: sys/uvm: uvm_map.c Log message: Check for wraparound before the "commit" phase of uvm_map() and uvm_mapanon(), to prevent hitting assertions and/or corrupting data structures during that phase. ok deraadt@, tedu@
Re: [PATCH] shutdown: dot not write non-printable characters to wall(1)
Thus said Consus on Mon, 01 Aug 2016 21:58:16 +0300: > This patch fixes the issue by removing '\007' from the shutdown > notification. Do ttys no longer understand bel? Thanks, Andy -- TAI64 timestamp: 4000579f9de9
[PATCH] shutdown: dot not write non-printable characters to wall(1)
The wall(1) utility now replaces non-printable ASCII characters with a quotation mark. This results in a funny message: ?*** System shutdown message from consus@localhost ***? This patch fixes the issue by removing '\007' from the shutdown notification. --- sbin/shutdown/shutdown.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sbin/shutdown/shutdown.c b/sbin/shutdown/shutdown.c index f85f103..419bdc4 100644 --- a/sbin/shutdown/shutdown.c +++ b/sbin/shutdown/shutdown.c @@ -294,7 +294,7 @@ timewarn(int timeleft) } (void)fprintf(pf, - "\007*** %sSystem shutdown message from %s@%s ***\007\n", + "*** %sSystem shutdown message from %s@%s ***\n", timeleft ? "": "FINAL ", whom, hostname); if (timeleft > 10*60) -- 2.9.0
Re: [Bug 64] Any user can trigger a panic in mmap with an overlapping mapping
Hi Tim,
Yes, a fix is being discussed ATM.. we'll let you know shortly I believe.
On Mon, Aug 1, 2016 at 12:38 PM, Jesse Hertz
wrote:
> Hi All,
>
> Is a fix for this in the works? We’d like to be able to point to a fix
> before posting to oss-sec :)
>
> Best,
> -jh
> > On Jul 28, 2016, at 8:58 PM, Tim Newsham
> wrote:
> >
> > Hi, We just came across another issue that allows a user to crash the
> system through mmap. Despite trying, we didn't notice any more serious
> privilege escalation opportunities.
> >
> > /*
> > * mmap_dup_panic.c
> > *Demonstrate a panic through the mmap system call.
> > *
> > * gcc -g mmap_dup_panic.c -o mmap_dup_panic
> > */
> >
> > #ifdef BUG_WRITEUP //---
> > Any user can trigger a panic in mmap with an overlapping mapping
> >
> > Impact:
> > Any user can trigger a panic by requesting a large mapping
> > that overlaps with an existing mapping.
> >
> > Description:
> > It is possible for an mmap() call to request a mapping at a
> > virtual address that overlaps an existing mapping. This is checked
> > for in uvm_map() by calling uvm_map_isavail() with the hint address and
> > size.. There is a flaw in uvm_map_isavail() when the requested size is
> very
> > large. The code looks up the maps at the start and end address with:
> >
> >if (*start_ptr == NULL) {
> >*start_ptr = uvm_map_entrybyaddr(atree, addr);
> >if (*start_ptr == NULL)
> >return 0;
> >} else
> >KASSERT(*start_ptr == uvm_map_entrybyaddr(atree, addr));
> >if (*end_ptr == NULL) {
> >if (VMMAP_FREE_END(*start_ptr) >= addr + sz)
> >*end_ptr = *start_ptr;
> >else {
> >*end_ptr = uvm_map_entrybyaddr(atree, addr + sz - 1);
> >if (*end_ptr == NULL)
> >return 0;
> >}
> >} else
> >KASSERT(*end_ptr == uvm_map_entrybyaddr(atree, addr + sz - 1));
> >
> > Due to an integer overflow that can occur when computing
> > "addr + sz" it is possible for the end_ptr map to be
> > computed incorrectly (setting "*end_ptr = *start_ptr"). Later
> > when this same function iterates over the maps between the start
> > and end maps, the function may fail to notice that a large mapping
> > overlaps with an existing mapping.
> >
> > If uvm_map_isavail() indicates that the hint address is available,
> > uvm_map() will continue its processing without assigning a new
> > address. It will eventually call uvm_map_fix_space() which
> > performs its own sanity lookup with uvm_mapent_addr_insert(),
> > and panics if an overlapping mapping is added:
> >
> >res = RB_INSERT(uvm_map_addr, &map->addr, entry);
> >if (res != NULL) {
> >panic("uvm_mapent_addr_insert: map %p entry %p "
> >"(0x%lx-0x%lx G=0x%lx F=0x%lx) insert collision "
> >"with entry %p (0x%lx-0x%lx G=0x%lx F=0x%lx)",
> >map, entry,
> >entry->start, entry->end, entry->guard, entry->fspace,
> >res, res->start, res->end, res->guard, res->fspace);
> >}
> >
> > An attacker can take advantage of this to intentionally
> > trigger a panic to crash the system. This does not require
> > any special privileges.
> >
> > In theory this flaw might allow an attacker to make a mapping
> > that wraps around from user addresses, through kernel addresses
> > and back to low user addresses. Such a mapping might allow
> > access to kernel memory or to the NULL page (useful for performing
> > certain attacks against NULL pointer use in the kernel).
> > However NCC was unable to find any way to create such a mapping
> > without causing a panic since it does not appear to be possible
> > to make a mapping above the stack segment. All wrap-around mappings
> > lower than this address overlap with the stack segment and result
> > in a panic.
> >
> > Reproduction:
> > Run the attached mmap_dup_panic.c program. It first maps a
> > page in and then performs a second mmap() call to request
> > another mapping at the next page address. This second mapping overlaps
> > the first due to the large size, and causes a panic message such as
> > "panic: uvm_mapent_addr_insert: map 0xff00036be300 entry
> 0xff000311d178 (0x1dcc5600-0x1dcc5600 G=0x0 F=0x2)
> insert collision with entry 0xff000272de08
> (0x1dcc5600-0x1dcc5600 G=0x0 F=0x1000)"
> > NCC Group was able to reproduce this issue on OpenBSD 5.9-stable kernel
> > pulled from CVS on July 25, 2016.
> >
> > Recommendation:
> > Detect when "addr + sz" causes an integer overflow in uvm_map_isavail().
> > Return zero indicating that this mapping is not available in this case.
> >
> > Reported: 2016-07-28
> > Fixed:notyet
> > #endif // BUG_WRITEUP ---
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > void xperror(int cond, char *msg)
> > {
> >if(cond) {
> >perror(msg);
> >e
Re: [Bug 64] Any user can trigger a panic in mmap with an overlapping mapping
Hi All,
Is a fix for this in the works? We’d like to be able to point to a fix before
posting to oss-sec :)
Best,
-jh
> On Jul 28, 2016, at 8:58 PM, Tim Newsham wrote:
>
> Hi, We just came across another issue that allows a user to crash the system
> through mmap. Despite trying, we didn't notice any more serious privilege
> escalation opportunities.
>
> /*
> * mmap_dup_panic.c
> *Demonstrate a panic through the mmap system call.
> *
> * gcc -g mmap_dup_panic.c -o mmap_dup_panic
> */
>
> #ifdef BUG_WRITEUP //---
> Any user can trigger a panic in mmap with an overlapping mapping
>
> Impact:
> Any user can trigger a panic by requesting a large mapping
> that overlaps with an existing mapping.
>
> Description:
> It is possible for an mmap() call to request a mapping at a
> virtual address that overlaps an existing mapping. This is checked
> for in uvm_map() by calling uvm_map_isavail() with the hint address and
> size.. There is a flaw in uvm_map_isavail() when the requested size is very
> large. The code looks up the maps at the start and end address with:
>
>if (*start_ptr == NULL) {
>*start_ptr = uvm_map_entrybyaddr(atree, addr);
>if (*start_ptr == NULL)
>return 0;
>} else
>KASSERT(*start_ptr == uvm_map_entrybyaddr(atree, addr));
>if (*end_ptr == NULL) {
>if (VMMAP_FREE_END(*start_ptr) >= addr + sz)
>*end_ptr = *start_ptr;
>else {
>*end_ptr = uvm_map_entrybyaddr(atree, addr + sz - 1);
>if (*end_ptr == NULL)
>return 0;
>}
>} else
>KASSERT(*end_ptr == uvm_map_entrybyaddr(atree, addr + sz - 1));
>
> Due to an integer overflow that can occur when computing
> "addr + sz" it is possible for the end_ptr map to be
> computed incorrectly (setting "*end_ptr = *start_ptr"). Later
> when this same function iterates over the maps between the start
> and end maps, the function may fail to notice that a large mapping
> overlaps with an existing mapping.
>
> If uvm_map_isavail() indicates that the hint address is available,
> uvm_map() will continue its processing without assigning a new
> address. It will eventually call uvm_map_fix_space() which
> performs its own sanity lookup with uvm_mapent_addr_insert(),
> and panics if an overlapping mapping is added:
>
>res = RB_INSERT(uvm_map_addr, &map->addr, entry);
>if (res != NULL) {
>panic("uvm_mapent_addr_insert: map %p entry %p "
>"(0x%lx-0x%lx G=0x%lx F=0x%lx) insert collision "
>"with entry %p (0x%lx-0x%lx G=0x%lx F=0x%lx)",
>map, entry,
>entry->start, entry->end, entry->guard, entry->fspace,
>res, res->start, res->end, res->guard, res->fspace);
>}
>
> An attacker can take advantage of this to intentionally
> trigger a panic to crash the system. This does not require
> any special privileges.
>
> In theory this flaw might allow an attacker to make a mapping
> that wraps around from user addresses, through kernel addresses
> and back to low user addresses. Such a mapping might allow
> access to kernel memory or to the NULL page (useful for performing
> certain attacks against NULL pointer use in the kernel).
> However NCC was unable to find any way to create such a mapping
> without causing a panic since it does not appear to be possible
> to make a mapping above the stack segment. All wrap-around mappings
> lower than this address overlap with the stack segment and result
> in a panic.
>
> Reproduction:
> Run the attached mmap_dup_panic.c program. It first maps a
> page in and then performs a second mmap() call to request
> another mapping at the next page address. This second mapping overlaps
> the first due to the large size, and causes a panic message such as
> "panic: uvm_mapent_addr_insert: map 0xff00036be300 entry
> 0xff000311d178 (0x1dcc5600-0x1dcc5600 G=0x0 F=0x2) insert
> collision with entry 0xff000272de08 (0x1dcc5600-0x1dcc5600 G=0x0
> F=0x1000)"
> NCC Group was able to reproduce this issue on OpenBSD 5.9-stable kernel
> pulled from CVS on July 25, 2016.
>
> Recommendation:
> Detect when "addr + sz" causes an integer overflow in uvm_map_isavail().
> Return zero indicating that this mapping is not available in this case.
>
> Reported: 2016-07-28
> Fixed:notyet
> #endif // BUG_WRITEUP ---
>
> #include
> #include
> #include
> #include
> #include
>
> void xperror(int cond, char *msg)
> {
>if(cond) {
>perror(msg);
>exit(1);
>}
> }
>
> int main(int argc, char **argv)
> {
>int fd;
>char *p, *pg;
>
>fd = open("/tmp/mapfile", O_RDWR|O_CREAT, 0666);
>xperror(fd == -1, "/tmp/mapfile");
>write(fd, "testing\n", 8);
>
>pg = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS,
> -1, 0);
>xperror(pg == MAP_FAILED, "m
Re: C startup code: make crtbegin code safe for clang
> From: j...@wxcvbn.org (Jeremie Courreges-Anglas)
> Date: Mon, 01 Aug 2016 20:30:33 +0200
>
> Stefan Kempf writes:
>
> > The constructor and destructor tables are declared as arrays with one
> > non-NULL element. Walking those until a NULL element is reached looks
> > like out-of-bound accesses to newer compilers, and they turn the code
> > into infinite loops (e.g. clang 3.8), because it is undefined behavior.
> >
> > Use constructor/destructor calling code that should be legal in both the
> > gcc and clang C dialect, to hopefully be immune from undefined behavior
> > optimizations in the future.
> >
> > While there, clean up crtbegin.c and crtbegin.S a little and make them
> > more similar.
> >
> > ok?
> >
> > Index: lib/csu/crtbegin.c
> > ===
> > RCS file: /cvs/src/lib/csu/crtbegin.c,v
> > retrieving revision 1.20
> > diff -u -p -r1.20 crtbegin.c
> > --- lib/csu/crtbegin.c 10 Nov 2015 04:14:03 - 1.20
> > +++ lib/csu/crtbegin.c 1 Aug 2016 16:56:31 -
> > @@ -85,36 +85,37 @@ long __guard_local __dso_hidden __attrib
> >
> >
> > static const init_f __CTOR_LIST__[1]
> > -__attribute__((section(".ctors"))) = { (void *)-1 }; /* XXX */
> > +__used __attribute__((section(".ctors"))) = { (void *)-1 };/* XXX
> > */
> > static const init_f __DTOR_LIST__[1]
> > -__attribute__((section(".dtors"))) = { (void *)-1 }; /* XXX */
> > +__used __attribute__((section(".dtors"))) = { (void *)-1 };/* XXX
> > */
> > +
> > +extern const init_f ctor_list[] asm(".ctors");
> > +extern const init_f dtor_list[] asm(".dtors");
> >
> > static void__dtors(void) __used;
> > static void__ctors(void) __used;
> >
> > static void
> > -__ctors()
> > +__ctors(void)
> > {
> > - unsigned long i = (unsigned long) __CTOR_LIST__[0];
> > - const init_f *p;
> > + int i;
> > +
> > + for (i = 0; ctor_list[i + 1] != NULL; i++)
> > + continue;
> >
> > - if (i == -1) {
> > - for (i = 1; __CTOR_LIST__[i] != NULL; i++)
> > - ;
> > + while (i > 0) {
> > + ctor_list[i]();
>
> The existing code tries to retrieve the number of valid ctors entries
> from __CTOR_LIST__[0], only when that number is -1 it tries to find
> the actual value by walking the array.
>
> The ld(1) info page states:
>
> The symbol `__CTOR_LIST__' marks the start of the global
> constructors, and the symbol `__CTOR_END__' marks the end.
> Similarly, `__DTOR_LIST__' and `__DTOR_END__' mark the start and
> end of the global destructors. The first word in the list is the
> number of entries, followed by the address of each constructor or
> destructor, followed by a zero word. The compiler must arrange to
> actually run the code. For these object file formats GNU C++
> normally calls constructors from a subroutine `__main'; a call to
> `__main' is automatically inserted into the startup code for
> `main'. GNU C++ normally runs destructors either by using
> `atexit', or directly from the function `exit'.
>
> If that is correct your code should behave the same. But what if...?
Right, the code is not equivalent. We'd have to look carefully at gcc
and ld to see if that matters.
Also, aren't ctor_list and dtor_list polluting the namespace?
Re: C startup code: make crtbegin code safe for clang
Stefan Kempf writes:
> The constructor and destructor tables are declared as arrays with one
> non-NULL element. Walking those until a NULL element is reached looks
> like out-of-bound accesses to newer compilers, and they turn the code
> into infinite loops (e.g. clang 3.8), because it is undefined behavior.
>
> Use constructor/destructor calling code that should be legal in both the
> gcc and clang C dialect, to hopefully be immune from undefined behavior
> optimizations in the future.
>
> While there, clean up crtbegin.c and crtbegin.S a little and make them
> more similar.
>
> ok?
>
> Index: lib/csu/crtbegin.c
> ===
> RCS file: /cvs/src/lib/csu/crtbegin.c,v
> retrieving revision 1.20
> diff -u -p -r1.20 crtbegin.c
> --- lib/csu/crtbegin.c10 Nov 2015 04:14:03 - 1.20
> +++ lib/csu/crtbegin.c1 Aug 2016 16:56:31 -
> @@ -85,36 +85,37 @@ long __guard_local __dso_hidden __attrib
>
>
> static const init_f __CTOR_LIST__[1]
> -__attribute__((section(".ctors"))) = { (void *)-1 }; /* XXX */
> +__used __attribute__((section(".ctors"))) = { (void *)-1 }; /* XXX
> */
> static const init_f __DTOR_LIST__[1]
> -__attribute__((section(".dtors"))) = { (void *)-1 }; /* XXX */
> +__used __attribute__((section(".dtors"))) = { (void *)-1 }; /* XXX
> */
> +
> +extern const init_f ctor_list[] asm(".ctors");
> +extern const init_f dtor_list[] asm(".dtors");
>
> static void __dtors(void) __used;
> static void __ctors(void) __used;
>
> static void
> -__ctors()
> +__ctors(void)
> {
> - unsigned long i = (unsigned long) __CTOR_LIST__[0];
> - const init_f *p;
> + int i;
> +
> + for (i = 0; ctor_list[i + 1] != NULL; i++)
> + continue;
>
> - if (i == -1) {
> - for (i = 1; __CTOR_LIST__[i] != NULL; i++)
> - ;
> + while (i > 0) {
> + ctor_list[i]();
The existing code tries to retrieve the number of valid ctors entries
from __CTOR_LIST__[0], only when that number is -1 it tries to find
the actual value by walking the array.
The ld(1) info page states:
The symbol `__CTOR_LIST__' marks the start of the global
constructors, and the symbol `__CTOR_END__' marks the end.
Similarly, `__DTOR_LIST__' and `__DTOR_END__' mark the start and
end of the global destructors. The first word in the list is the
number of entries, followed by the address of each constructor or
destructor, followed by a zero word. The compiler must arrange to
actually run the code. For these object file formats GNU C++
normally calls constructors from a subroutine `__main'; a call to
`__main' is automatically inserted into the startup code for
`main'. GNU C++ normally runs destructors either by using
`atexit', or directly from the function `exit'.
If that is correct your code should behave the same. But what if...?
> i--;
> }
> - p = __CTOR_LIST__ + i;
> - while (i--)
> - (**p--)();
> }
>
> static void
> -__dtors()
> +__dtors(void)
> {
> - const init_f *p = __DTOR_LIST__ + 1;
> + int i;
>
> - while (*p)
> - (**p++)();
> + for (i = 1; dtor_list[i] != NULL; i++)
> + dtor_list[i]();
> }
>
> void __init(void);
> @@ -130,8 +131,8 @@ MD_SECT_CALL_FUNC(".init", __do_init);
> MD_SECT_CALL_FUNC(".fini", __do_fini);
>
>
> -void
> -__do_init()
> +static void
> +__do_init(void)
> {
> static int initialized = 0;
> static struct dwarf2_eh_object object;
> @@ -146,14 +147,14 @@ __do_init()
> __register_frame_info(__EH_FRAME_BEGIN__, &object);
> if (__JCR_LIST__[0] && _Jv_RegisterClasses)
> _Jv_RegisterClasses(__JCR_LIST__);
> - (__ctors)();
> + __ctors();
>
> atexit(__fini);
> }
> }
>
> -void
> -__do_fini()
> +static void
> +__do_fini(void)
> {
> static int finalized = 0;
>
> @@ -162,7 +163,7 @@ __do_fini()
> /*
>* Call global destructors.
>*/
> - (__dtors)();
> + __dtors();
> }
> }
>
> Index: lib/csu/crtbeginS.c
> ===
> RCS file: /cvs/src/lib/csu/crtbeginS.c,v
> retrieving revision 1.16
> diff -u -p -r1.16 crtbeginS.c
> --- lib/csu/crtbeginS.c 7 Apr 2015 01:27:06 - 1.16
> +++ lib/csu/crtbeginS.c 1 Aug 2016 16:56:31 -
> @@ -38,7 +38,6 @@
> * constructors and destructors. The first element contains the
> * number of pointers in each.
> * The tables are also null-terminated.
> -
> */
> #include
>
> @@ -96,39 +95,39 @@ asm(".hidden pthread_atfork\n .weak pthr
>
>
> static init_f __CTOR_LIST__[1]
> -__attribute__((section(".ctors"))) = { (void *)-1 }; /* XXX */
> +__used __attribute__((section(".ct
Re: nc getaddrinfo cleanup
look ok to me.. go for it
On Fri, Jul 29, 2016 at 6:00 PM, Alexander Hall wrote:
> Use the style from the man page examples for getaddrinfo, which makes a
> bit more sense.
>
> No functional change intended, and prior to the do/while => for
> transition, no .o files were harmed.
>
> OK?
>
> /Alexander
>
>
> Index: netcat.c
> ===
> RCS file: /cvs/src/usr.bin/nc/netcat.c,v
> retrieving revision 1.160
> diff -u -p -r1.160 netcat.c
> --- netcat.c13 Jul 2016 16:35:47 - 1.160
> +++ netcat.c29 Jul 2016 23:47:52 -
> @@ -834,13 +834,12 @@ remote_connect(const char *host, const c
> struct addrinfo *res, *res0;
> int s, error, on = 1, save_errno;
>
> - if ((error = getaddrinfo(host, port, &hints, &res)))
> + if ((error = getaddrinfo(host, port, &hints, &res0)))
> errx(1, "getaddrinfo: %s", gai_strerror(error));
>
> - res0 = res;
> - do {
> - if ((s = socket(res0->ai_family, res0->ai_socktype |
> - SOCK_NONBLOCK, res0->ai_protocol)) < 0)
> + for (res = res0; res; res = res->ai_next) {
> + if ((s = socket(res->ai_family, res->ai_socktype |
> + SOCK_NONBLOCK, res->ai_protocol)) < 0)
> continue;
>
> /* Bind to a local port or source address if specified. */
> @@ -850,7 +849,7 @@ remote_connect(const char *host, const c
> /* try SO_BINDANY, but don't insist */
> setsockopt(s, SOL_SOCKET, SO_BINDANY, &on,
> sizeof(on));
> memset(&ahints, 0, sizeof(struct addrinfo));
> - ahints.ai_family = res0->ai_family;
> + ahints.ai_family = res->ai_family;
> ahints.ai_socktype = uflag ? SOCK_DGRAM :
> SOCK_STREAM;
> ahints.ai_protocol = uflag ? IPPROTO_UDP :
> IPPROTO_TCP;
> ahints.ai_flags = AI_PASSIVE;
> @@ -863,9 +862,9 @@ remote_connect(const char *host, const c
> freeaddrinfo(ares);
> }
>
> - set_common_sockopts(s, res0->ai_family);
> + set_common_sockopts(s, res->ai_family);
>
> - if (timeout_connect(s, res0->ai_addr, res0->ai_addrlen) ==
> 0)
> + if (timeout_connect(s, res->ai_addr, res->ai_addrlen) == 0)
> break;
> if (vflag)
> warn("connect to %s port %s (%s) failed", host,
> port,
> @@ -875,9 +874,9 @@ remote_connect(const char *host, const c
> close(s);
> errno = save_errno;
> s = -1;
> - } while ((res0 = res0->ai_next) != NULL);
> + }
>
> - freeaddrinfo(res);
> + freeaddrinfo(res0);
>
> return (s);
> }
> @@ -932,37 +931,36 @@ local_listen(char *host, char *port, str
> if (host == NULL && hints.ai_family == AF_UNSPEC)
> hints.ai_family = AF_INET;
>
> - if ((error = getaddrinfo(host, port, &hints, &res)))
> + if ((error = getaddrinfo(host, port, &hints, &res0)))
> errx(1, "getaddrinfo: %s", gai_strerror(error));
>
> - res0 = res;
> - do {
> - if ((s = socket(res0->ai_family, res0->ai_socktype,
> - res0->ai_protocol)) < 0)
> + for (res = res0; res; res = res->ai_next) {
> + if ((s = socket(res->ai_family, res->ai_socktype,
> + res->ai_protocol)) < 0)
> continue;
>
> ret = setsockopt(s, SOL_SOCKET, SO_REUSEPORT, &x,
> sizeof(x));
> if (ret == -1)
> err(1, NULL);
>
> - set_common_sockopts(s, res0->ai_family);
> + set_common_sockopts(s, res->ai_family);
>
> - if (bind(s, (struct sockaddr *)res0->ai_addr,
> - res0->ai_addrlen) == 0)
> + if (bind(s, (struct sockaddr *)res->ai_addr,
> + res->ai_addrlen) == 0)
> break;
>
> save_errno = errno;
> close(s);
> errno = save_errno;
> s = -1;
> - } while ((res0 = res0->ai_next) != NULL);
> + }
>
> if (!uflag && s != -1) {
> if (listen(s, 1) < 0)
> err(1, "listen");
> }
>
> - freeaddrinfo(res);
> + freeaddrinfo(res0);
>
> return (s);
> }
>
>
C startup code: make crtbegin code safe for clang
The constructor and destructor tables are declared as arrays with one
non-NULL element. Walking those until a NULL element is reached looks
like out-of-bound accesses to newer compilers, and they turn the code
into infinite loops (e.g. clang 3.8), because it is undefined behavior.
Use constructor/destructor calling code that should be legal in both the
gcc and clang C dialect, to hopefully be immune from undefined behavior
optimizations in the future.
While there, clean up crtbegin.c and crtbegin.S a little and make them
more similar.
ok?
Index: lib/csu/crtbegin.c
===
RCS file: /cvs/src/lib/csu/crtbegin.c,v
retrieving revision 1.20
diff -u -p -r1.20 crtbegin.c
--- lib/csu/crtbegin.c 10 Nov 2015 04:14:03 - 1.20
+++ lib/csu/crtbegin.c 1 Aug 2016 16:56:31 -
@@ -85,36 +85,37 @@ long __guard_local __dso_hidden __attrib
static const init_f __CTOR_LIST__[1]
-__attribute__((section(".ctors"))) = { (void *)-1 }; /* XXX */
+__used __attribute__((section(".ctors"))) = { (void *)-1 };/* XXX
*/
static const init_f __DTOR_LIST__[1]
-__attribute__((section(".dtors"))) = { (void *)-1 }; /* XXX */
+__used __attribute__((section(".dtors"))) = { (void *)-1 };/* XXX
*/
+
+extern const init_f ctor_list[] asm(".ctors");
+extern const init_f dtor_list[] asm(".dtors");
static void__dtors(void) __used;
static void__ctors(void) __used;
static void
-__ctors()
+__ctors(void)
{
- unsigned long i = (unsigned long) __CTOR_LIST__[0];
- const init_f *p;
+ int i;
+
+ for (i = 0; ctor_list[i + 1] != NULL; i++)
+ continue;
- if (i == -1) {
- for (i = 1; __CTOR_LIST__[i] != NULL; i++)
- ;
+ while (i > 0) {
+ ctor_list[i]();
i--;
}
- p = __CTOR_LIST__ + i;
- while (i--)
- (**p--)();
}
static void
-__dtors()
+__dtors(void)
{
- const init_f *p = __DTOR_LIST__ + 1;
+ int i;
- while (*p)
- (**p++)();
+ for (i = 1; dtor_list[i] != NULL; i++)
+ dtor_list[i]();
}
void __init(void);
@@ -130,8 +131,8 @@ MD_SECT_CALL_FUNC(".init", __do_init);
MD_SECT_CALL_FUNC(".fini", __do_fini);
-void
-__do_init()
+static void
+__do_init(void)
{
static int initialized = 0;
static struct dwarf2_eh_object object;
@@ -146,14 +147,14 @@ __do_init()
__register_frame_info(__EH_FRAME_BEGIN__, &object);
if (__JCR_LIST__[0] && _Jv_RegisterClasses)
_Jv_RegisterClasses(__JCR_LIST__);
- (__ctors)();
+ __ctors();
atexit(__fini);
}
}
-void
-__do_fini()
+static void
+__do_fini(void)
{
static int finalized = 0;
@@ -162,7 +163,7 @@ __do_fini()
/*
* Call global destructors.
*/
- (__dtors)();
+ __dtors();
}
}
Index: lib/csu/crtbeginS.c
===
RCS file: /cvs/src/lib/csu/crtbeginS.c,v
retrieving revision 1.16
diff -u -p -r1.16 crtbeginS.c
--- lib/csu/crtbeginS.c 7 Apr 2015 01:27:06 - 1.16
+++ lib/csu/crtbeginS.c 1 Aug 2016 16:56:31 -
@@ -38,7 +38,6 @@
* constructors and destructors. The first element contains the
* number of pointers in each.
* The tables are also null-terminated.
-
*/
#include
@@ -96,39 +95,39 @@ asm(".hidden pthread_atfork\n .weak pthr
static init_f __CTOR_LIST__[1]
-__attribute__((section(".ctors"))) = { (void *)-1 }; /* XXX */
+__used __attribute__((section(".ctors"))) = { (void *)-1 };/* XXX
*/
static init_f __DTOR_LIST__[1]
-__attribute__((section(".dtors"))) = { (void *)-1 }; /* XXX */
+__used __attribute__((section(".dtors"))) = { (void *)-1 };/* XXX
*/
+
+extern const init_f ctor_list[] asm(".ctors");
+extern const init_f dtor_list[] asm(".dtors");
static void__dtors(void) __used;
static void__ctors(void) __used;
-void
+static void
__ctors(void)
{
- unsigned long i = (unsigned long) __CTOR_LIST__[0];
- init_f *p;
+ int i;
- if (i == -1) {
- for (i = 1; __CTOR_LIST__[i] != NULL; i++)
- ;
+ for (i = 0; ctor_list[i + 1] != NULL; i++)
+ continue;
+
+ while (i > 0) {
+ ctor_list[i]();
i--;
}
- p = __CTOR_LIST__ + i;
- while (i--) {
- (**p--)();
- }
}
static void
__dtors(void)
{
- init_f *p = __DTOR_LIST__ + 1;
+ int i;
- while (*p) {
- (**p++)();
- }
+ for (i = 1; dtor_list[i] != NULL; i++)
+ dtor_list[i]();
}
+
void _init(void);
void _fini(void);
static void _do_init(void) __used;
@@ -141,7 +140,7 @@
armv7 and unified TLBs
So the ARMv7 ARM says in B4.2.2:
- on an implementation with separate data and instruction TLBs, any
unified TLB operation operates on both TLBs
- on an implementation with a unified TLB, any instruction TLB
operation, and any data TLB operation, operates on the unified TLB
- ARM deprecates use of instruction TLB operations and data TLB
operations, and recommends that software always uses the unified
TLB operations.
It seems that All the Cortex-A CPUs, with the exception of the
Cortex-A8 have a unified TLB. Since the non-unified TLB operations
are deprecated, and using the unified TLB operations leads to some
code simplifications, I think it makes sense to switch armv7 to these.
This might be a slight pessimisation on Cortex-A8, although I'm not
sure it will be noticable.
Thoughts?
Tested on Cortex-A9. Would be nice if somebody could test this on
Cortex-A8.
Index: arch/arm/arm/cpufunc_asm_armv7.S
===
RCS file: /cvs/src/sys/arch/arm/arm/cpufunc_asm_armv7.S,v
retrieving revision 1.10
diff -u -p -r1.10 cpufunc_asm_armv7.S
--- arch/arm/arm/cpufunc_asm_armv7.S25 Apr 2016 04:46:56 - 1.10
+++ arch/arm/arm/cpufunc_asm_armv7.S1 Aug 2016 14:34:36 -
@@ -55,15 +55,14 @@ ENTRY(armv7_setttb)
* TLB functions
*/
ENTRY(armv7_tlb_flushID_SE)
- mcr CP15_DTLBIMVA /* flush D tlb single entry */
- mcr CP15_ITLBIMVA /* flush I tlb single entry */
+ mcr CP15_TLBIMVA(r0)/* flush unified tlb single entry */
mcr CP15_BPIMVA /* flush va from BP */
dsb sy
isb sy
mov pc, lr
ENTRY(armv7_tlb_flushI_SE)
- mcr CP15_ITLBIMVA /* flush I tlb single entry */
+ mcr CP15_TLBIMVA(r0)/* flush unified tlb single entry */
mcr CP15_BPIMVA /* flush va from BP */
dsb sy
isb sy
@@ -73,27 +72,27 @@ ENTRY(armv7_tlb_flushI_SE)
* TLB functions
*/
ENTRY(armv7_tlb_flushID)
- mcr CP15_TLBIALL(r0)/* flush I+D tlb */
+ mcr CP15_TLBIALL(r0)/* flush unified tlb */
mcr CP15_BPIALL /* Flush BP cache */
dsb sy
isb sy
mov pc, lr
ENTRY(armv7_tlb_flushI)
- mcr CP15_ITLBIALL /* flush I tlb */
+ mcr CP15_TLBIALL(r0)/* flush unified tlb */
mcr CP15_BPIALL /* Flush BP cache */
dsb sy
isb sy
mov pc, lr
ENTRY(armv7_tlb_flushD)
- mcr CP15_DTLBIALL /* flush D tlb */
+ mcr CP15_TLBIALL(r0)/* flush unified tlb */
dsb sy
isb sy
mov pc, lr
ENTRY(armv7_tlb_flushD_SE)
- mcr CP15_DTLBIMVA /* flush D tlb single entry */
+ mcr CP15_TLBIMVA(r0)/* flush unified tlb single entry */
dsb sy
isb sy
mov pc, lr
Index: arch/arm/arm/pmap7.c
===
RCS file: /cvs/src/sys/arch/arm/arm/pmap7.c,v
retrieving revision 1.31
diff -u -p -r1.31 pmap7.c
--- arch/arm/arm/pmap7.c31 Jul 2016 22:27:07 - 1.31
+++ arch/arm/arm/pmap7.c1 Aug 2016 14:34:37 -
@@ -1028,12 +1028,8 @@ pmap_clearbit(struct vm_page *pg, u_int
*ptep = npte;
PTE_SYNC(ptep);
/* Flush the TLB entry if a current pmap. */
- if (l2pte_valid(opte)) {
- if (PV_BEEN_EXECD(oflags))
- pmap_tlb_flushID_SE(pm, pv->pv_va);
- else
- pmap_tlb_flushD_SE(pm, pv->pv_va);
- }
+ if (l2pte_valid(opte))
+ pmap_tlb_flushID_SE(pm, pv->pv_va);
}
NPDEBUG(PDB_BITS,
@@ -1281,7 +1277,6 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
ptep = &l2b->l2b_kva[l2pte_index(va)];
opte = *ptep;
npte = pa;
- oflags = 0;
if (opte != 0) {/* not l2pte_valid!!! MIOD */
/*
@@ -1367,7 +1362,6 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
* must remove it from the PV list
*/
pve = pmap_remove_pv(opg, pm, va);
- oflags = pve->pv_flags;
} else
if ((pve = pool_get(&pmap_pv_pool, PR_NOWAIT)) == NULL){
if ((flags & PMAP_CANFAIL) == 0)
@@ -1397,8 +1391,6 @@ pmap_enter(pmap_t pm, vaddr_t va, paddr_
* at this address.
*/
pve = pmap_remove_pv(opg, pm, va);
-
Announce: OpenSSH 7.3 released
OpenSSH 7.3 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. OpenSSH also includes transitional support for the legacy SSH 1.3 and 1.5 protocols that may be enabled at compile-time. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: http://www.openssh.com/donations.html Future deprecation notice = We plan on retiring more legacy cryptography in a near-future release, specifically: * Refusing all RSA keys smaller than 1024 bits (the current minimum is 768 bits) * Removing server-side support for the SSH v.1 protocol (currently compile-time disabled). * In approximately 1 year, removing all support for the SSH v.1 protocol (currently compile-time disabled). This list reflects our current intentions, but please check the final release notes for future releases. Changes since OpenSSH 7.2 = This is primarily a bugfix release. Security * sshd(8): Mitigate a potential denial-of-service attack against the system's crypt(3) function via sshd(8). An attacker could send very long passwords that would cause excessive CPU use in crypt(3). sshd(8) now refuses to accept password authentication requests of length greater than 1024 characters. Independently reported by Tomas Kuthan (Oracle), Andres Rojas and Javier Nieto. * sshd(8): Mitigate timing differences in password authentication that could be used to discern valid from invalid account names when long passwords were sent and particular password hashing algorithms are in use on the server. CVE-2016-6210, reported by EddieEzra.Harari at verint.com * ssh(1), sshd(8): Fix observable timing weakness in the CBC padding oracle countermeasures. Reported by Jean Paul Degabriele, Kenny Paterson, Torben Hansen and Martin Albrecht. Note that CBC ciphers are disabled by default and only included for legacy compatibility. * ssh(1), sshd(8): Improve operation ordering of MAC verification for Encrypt-then-MAC (EtM) mode transport MAC algorithms to verify the MAC before decrypting any ciphertext. This removes the possibility of timing differences leaking facts about the plaintext, though no such leakage has been observed. Reported by Jean Paul Degabriele, Kenny Paterson, Torben Hansen and Martin Albrecht. * sshd(8): (portable only) Ignore PAM environment vars when UseLogin=yes. If PAM is configured to read user-specified environment variables and UseLogin=yes in sshd_config, then a hostile local user may attack /bin/login via LD_PRELOAD or similar environment variables set via PAM. CVE-2015-8325, found by Shayan Sadigh. New Features * ssh(1): Add a ProxyJump option and corresponding -J command-line flag to allow simplified indirection through a one or more SSH bastions or "jump hosts". * ssh(1): Add an IdentityAgent option to allow specifying specific agent sockets instead of accepting one from the environment. * ssh(1): Allow ExitOnForwardFailure and ClearAllForwardings to be optionally overridden when using ssh -W. bz#2577 * ssh(1), sshd(8): Implement support for the IUTF8 terminal mode as per draft-sgtatham-secsh-iutf8-00. * ssh(1), sshd(8): Add support for additional fixed Diffie-Hellman 2K, 4K and 8K groups from draft-ietf-curdle-ssh-kex-sha2-03. * ssh-keygen(1), ssh(1), sshd(8): support SHA256 and SHA512 RSA signatures in certificates; * ssh(1): Add an Include directive for ssh_config(5) files. * ssh(1): Permit UTF-8 characters in pre-authentication banners sent from the server. bz#2058 Bugfixes * ssh(1), sshd(8): Reduce the syslog level of some relatively common protocol events from LOG_CRIT. bz#2585 * sshd(8): Refuse AuthenticationMethods="" in configurations and accept AuthenticationMethods=any for the default behaviour of not requiring multiple authentication. bz#2398 * sshd(8): Remove obsolete and misleading "POSSIBLE BREAK-IN ATTEMPT!" message when forward and reverse DNS don't match. bz#2585 * ssh(1): Close ControlPersist background process stderr except in debug mode or when logging to syslog. bz#1988 * misc: Make PROTOCOL description for direct-streamlo...@openssh.com channel open messages match deployed code. bz#2529 * ssh(1): Deduplicate LocalForward and RemoteForward entries to fix failures when both ExitOnForwardFailure and hostname canonicalisation are enabled. bz#2562 * sshd(8): Remove fallback from moduli to obsolete "primes" file that was deprecated in 2001. bz#2559. * sshd_config(5): Correct description of UseDNS: it affects s
Re: libtool -bindir support
> > > Index: Link.pm > > > === > > > RCS file: /cvs/src/usr.bin/libtool/LT/Mode/Link.pm,v > > > retrieving revision 1.31 > > > diff -u -p -p -u -r1.31 Link.pm > > > --- Link.pm 27 Apr 2016 09:50:57 - 1.31 > > > +++ Link.pm 1 Aug 2016 11:36:31 - > > > @@ -127,6 +127,7 @@ sub run > > > 'all-static', > > > 'allow-undefined', # we don't care about THAT one > > > 'avoid-version', > > > + 'bindir:', > > > 'dlopen:', > > > 'dlpreopen:', > > > 'export-dynamic', > > > @@ -152,7 +153,7 @@ sub run > > > 'version-info:', > > > 'version-number:'); > > > > > > - # XXX options ignored: dlopen, dlpreopen, no-fast-install, > > > + # XXX options ignored: bindir, dlopen, dlpreopen, no-fast-install, > > > # no-install, no-undefined, precious-files-regex, > > > # shrext, thread-safe, prefer-pic, prefer-non-pic > > > > I'm wondering about the second hunk: is this a mix of options that we > > don't support on purpose and of options that could be useful? > > (eg. -no-undefined.) So is the second hunk of this diff desirable? > > > The main thing about that diff is that it has to go into a successful > bulk. I think that goes without saying... I'll do that in a few. > As for ignored options, it's informative. It tells us we ignore those > options. Which ones should actually be supported is another story. > -- Antoine
Re: libtool -bindir support
On Mon, Aug 01, 2016 at 01:58:24PM +0200, Jeremie Courreges-Anglas wrote: > j...@wxcvbn.org (Jeremie Courreges-Anglas) writes: > > > +cc espie and jasper > > > > Antoine Jacoutot writes: > > > >> On Sun, Jul 31, 2016 at 07:21:39PM +0200, Antoine Jacoutot wrote: > >>> On July 31, 2016 7:14:21 PM GMT+02:00, j...@wxcvbn.org wrote: > >>> > > >>> >Making read(2) return EISDIR for directories breaks two ports, both > >>> >because they use libtool -bindir. cc(1) gets executed with an unknown > >>> >option, -bindir, and a path such as /usr/local/bin, which then gets > >>> >passed to ld(1). ld(1) copes with read(2) returning 0, not with > >>> >EISDIR. > >>> >Thanks to Antoine who ran the bulk builds that exposed this problem. > >>> > > >>> >-bindir support is meaningless on OpenBSD so handling that option > >>> >should > >>> >be easy. The problem is that I don't know how to implement it in > >>> >libtool(1). GNU libtool recognizes -bindir among cc flags, while our > >>> >version seems to only handle options passed right after argv[0]. > >>> > > >>> >I plan to work around that problem by using GNU libtool for the ports > >>> >mentioned above, but someone else might want to poke at libtool(1) > >>> >internals. :) > >>> > > >>> >-- > >>> >jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 > >>> >E7EE > >>> > >>> I can have a look at it during g2k16 if no one beats me to it. > >>> -- > >>> Antoine > >> > >> Hi Jeremie. > >> > >> This seems to do the trick for me: > > > > Thanks for looking at it. Yup, that works, but I think I know > > understand why I got confused first. > > > > -bindir is just one option among others that should be recognized and > > ignored in *link* mode. The following diff does just that, I think it > > fits better in the existing code. I can successfully build > > devel/libiscsi, -bindir /usr/local/bin doesn't get passed to cc(1). > > > > Thoughts? > > > > > > Index: Link.pm > > === > > RCS file: /cvs/src/usr.bin/libtool/LT/Mode/Link.pm,v > > retrieving revision 1.31 > > diff -u -p -p -u -r1.31 Link.pm > > --- Link.pm 27 Apr 2016 09:50:57 - 1.31 > > +++ Link.pm 1 Aug 2016 11:36:31 - > > @@ -127,6 +127,7 @@ sub run > > 'all-static', > > 'allow-undefined', # we don't care about THAT one > > 'avoid-version', > > + 'bindir:', > > 'dlopen:', > > 'dlpreopen:', > > 'export-dynamic', > > @@ -152,7 +153,7 @@ sub run > > 'version-info:', > > 'version-number:'); > > > > - # XXX options ignored: dlopen, dlpreopen, no-fast-install, > > + # XXX options ignored: bindir, dlopen, dlpreopen, no-fast-install, > > # no-install, no-undefined, precious-files-regex, > > # shrext, thread-safe, prefer-pic, prefer-non-pic > > I'm wondering about the second hunk: is this a mix of options that we > don't support on purpose and of options that could be useful? > (eg. -no-undefined.) So is the second hunk of this diff desirable? > The main thing about that diff is that it has to go into a successful bulk. As for ignored options, it's informative. It tells us we ignore those options. Which ones should actually be supported is another story.
Re: libtool -bindir support
j...@wxcvbn.org (Jeremie Courreges-Anglas) writes: > +cc espie and jasper > > Antoine Jacoutot writes: > >> On Sun, Jul 31, 2016 at 07:21:39PM +0200, Antoine Jacoutot wrote: >>> On July 31, 2016 7:14:21 PM GMT+02:00, j...@wxcvbn.org wrote: >>> > >>> >Making read(2) return EISDIR for directories breaks two ports, both >>> >because they use libtool -bindir. cc(1) gets executed with an unknown >>> >option, -bindir, and a path such as /usr/local/bin, which then gets >>> >passed to ld(1). ld(1) copes with read(2) returning 0, not with >>> >EISDIR. >>> >Thanks to Antoine who ran the bulk builds that exposed this problem. >>> > >>> >-bindir support is meaningless on OpenBSD so handling that option >>> >should >>> >be easy. The problem is that I don't know how to implement it in >>> >libtool(1). GNU libtool recognizes -bindir among cc flags, while our >>> >version seems to only handle options passed right after argv[0]. >>> > >>> >I plan to work around that problem by using GNU libtool for the ports >>> >mentioned above, but someone else might want to poke at libtool(1) >>> >internals. :) >>> > >>> >-- >>> >jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 >>> >E7EE >>> >>> I can have a look at it during g2k16 if no one beats me to it. >>> -- >>> Antoine >> >> Hi Jeremie. >> >> This seems to do the trick for me: > > Thanks for looking at it. Yup, that works, but I think I know > understand why I got confused first. > > -bindir is just one option among others that should be recognized and > ignored in *link* mode. The following diff does just that, I think it > fits better in the existing code. I can successfully build > devel/libiscsi, -bindir /usr/local/bin doesn't get passed to cc(1). > > Thoughts? > > > Index: Link.pm > === > RCS file: /cvs/src/usr.bin/libtool/LT/Mode/Link.pm,v > retrieving revision 1.31 > diff -u -p -p -u -r1.31 Link.pm > --- Link.pm 27 Apr 2016 09:50:57 - 1.31 > +++ Link.pm 1 Aug 2016 11:36:31 - > @@ -127,6 +127,7 @@ sub run > 'all-static', > 'allow-undefined', # we don't care about THAT one > 'avoid-version', > + 'bindir:', > 'dlopen:', > 'dlpreopen:', > 'export-dynamic', > @@ -152,7 +153,7 @@ sub run > 'version-info:', > 'version-number:'); > > - # XXX options ignored: dlopen, dlpreopen, no-fast-install, > + # XXX options ignored: bindir, dlopen, dlpreopen, no-fast-install, > # no-install, no-undefined, precious-files-regex, > # shrext, thread-safe, prefer-pic, prefer-non-pic I'm wondering about the second hunk: is this a mix of options that we don't support on purpose and of options that could be useful? (eg. -no-undefined.) So is the second hunk of this diff desirable? -- jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: libtool -bindir support
+cc espie and jasper Antoine Jacoutot writes: > On Sun, Jul 31, 2016 at 07:21:39PM +0200, Antoine Jacoutot wrote: >> On July 31, 2016 7:14:21 PM GMT+02:00, j...@wxcvbn.org wrote: >> > >> >Making read(2) return EISDIR for directories breaks two ports, both >> >because they use libtool -bindir. cc(1) gets executed with an unknown >> >option, -bindir, and a path such as /usr/local/bin, which then gets >> >passed to ld(1). ld(1) copes with read(2) returning 0, not with >> >EISDIR. >> >Thanks to Antoine who ran the bulk builds that exposed this problem. >> > >> >-bindir support is meaningless on OpenBSD so handling that option >> >should >> >be easy. The problem is that I don't know how to implement it in >> >libtool(1). GNU libtool recognizes -bindir among cc flags, while our >> >version seems to only handle options passed right after argv[0]. >> > >> >I plan to work around that problem by using GNU libtool for the ports >> >mentioned above, but someone else might want to poke at libtool(1) >> >internals. :) >> > >> >-- >> >jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 >> >E7EE >> >> I can have a look at it during g2k16 if no one beats me to it. >> -- >> Antoine > > Hi Jeremie. > > This seems to do the trick for me: Thanks for looking at it. Yup, that works, but I think I know understand why I got confused first. -bindir is just one option among others that should be recognized and ignored in *link* mode. The following diff does just that, I think it fits better in the existing code. I can successfully build devel/libiscsi, -bindir /usr/local/bin doesn't get passed to cc(1). Thoughts? Index: Link.pm === RCS file: /cvs/src/usr.bin/libtool/LT/Mode/Link.pm,v retrieving revision 1.31 diff -u -p -p -u -r1.31 Link.pm --- Link.pm 27 Apr 2016 09:50:57 - 1.31 +++ Link.pm 1 Aug 2016 11:36:31 - @@ -127,6 +127,7 @@ sub run 'all-static', 'allow-undefined', # we don't care about THAT one 'avoid-version', + 'bindir:', 'dlopen:', 'dlpreopen:', 'export-dynamic', @@ -152,7 +153,7 @@ sub run 'version-info:', 'version-number:'); - # XXX options ignored: dlopen, dlpreopen, no-fast-install, + # XXX options ignored: bindir, dlopen, dlpreopen, no-fast-install, # no-install, no-undefined, precious-files-regex, # shrext, thread-safe, prefer-pic, prefer-non-pic -- jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Fwd: [PATCH] let the mbufs use more then 4gb of memory
I sent this message to dlg@ directly to discuss my modification of his
diff to make the
bigger mbuf clusters work. i got no response so far, thats why i
decided to post it on tech@
directly. Maybe this way i get faster some feedback :)
BR
Simon
### Original Mail:
-- Forwarded message --
From: Simon Mages
Date: Fri, 22 Jul 2016 13:24:24 +0200
Subject: Re: [PATCH] let the mbufs use more then 4gb of memory
To: David Gwynne
Hi,
I think i found the problem with your diff regarding the bigger mbuf clusters.
You choose a buffer size based on space and resid, but what happens when resid
is larger then space and space is for example 2050? The cluster choosen has
then the size 4096. But this size is to large for the socket buffer. In the
past this was never a problem because you only allocated external clusters
of size MCLBYTES and this was only done when space was larger then MCLBYTES.
diff:
Index: kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.152
diff -u -p -u -p -r1.152 uipc_socket.c
--- kern/uipc_socket.c 13 Jun 2016 21:24:43 - 1.152
+++ kern/uipc_socket.c 22 Jul 2016 10:56:02 -
@@ -496,15 +496,18 @@ restart:
mlen = MLEN;
}
if (resid >= MINCLSIZE && space >= MCLBYTES) {
- MCLGET(m, M_NOWAIT);
+ MCLGETI(m, M_NOWAIT, NULL, lmin(resid,
+ lmin(space, MAXMCLBYTES)));
if ((m->m_flags & M_EXT) == 0)
goto nopages;
if (atomic && top == 0) {
- len = ulmin(MCLBYTES - max_hdr,
- resid);
+ len = lmin(lmin(resid, space),
+ m->m_ext.ext_size -
+ max_hdr);
m->m_data += max_hdr;
} else
- len = ulmin(MCLBYTES, resid);
+ len = lmin(lmin(resid, space),
+ m->m_ext.ext_size);
space -= len;
} else {
nopages:
Im using this diff no for a while on my notebook and everything works as
expected. But i had no time to realy test it or test the performance. This will
be my next step.
I reproduced the unix socket problem you mentioned with the following little
programm:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define FILE "/tmp/afile"
int senddesc(int fd, int so);
int recvdesc(int so);
int
main(void)
{
struct stat sb;
int sockpair[2];
pid_t pid = 0;
int status;
int newfile;
if (unlink(FILE) < 0)
warn("unlink: %s", FILE);
int file = open(FILE, O_RDWR|O_CREAT|O_TRUNC);
if (socketpair(AF_UNIX, SOCK_STREAM|SOCK_NONBLOCK, 0, sockpair) < 0)
err(1, "socketpair");
if ((pid =fork())) {
senddesc(file, sockpair[0]);
if (waitpid(pid, &status, 0) < 0)
err(1, "waitpid");
} else {
newfile = recvdesc(sockpair[1]);
if (fstat(newfile, &sb) < 0)
err(1, "fstat");
}
return 0;
}
int
senddesc(int fd, int so)
{
struct msghdr msg;
struct cmsghdr *cmsg;
union {
struct cmsghdr hdr;
unsigned char buf[CMSG_SPACE(sizeof(int))];
} cmsgbuf;
char *cbuf = calloc(6392, sizeof(char));
memset(cbuf, 'K', 6392);
struct iovec iov = {
.iov_base = cbuf,
.iov_len = 6392,
};
memset(&msg, 0, sizeof(struct msghdr));
msg.msg_iov = &iov;
msg.msg_iovlen = 1;
msg.msg_control = &cmsgbuf.buf;
msg.msg_controllen = sizeof(cmsgbuf.buf);
cmsg = CMSG_FIRSTHDR(&msg);
cmsg->cmsg_len = CMSG_LEN(sizeof(int));
cmsg->cmsg_level = SOL_SOCKET;
cmsg->cmsg_type = SCM_RIGHTS;
*(int *)CMSG_DATA(cmsg) = fd;
struct pollfd pfd[1];
int nready;
int wrote = 0;
int wrote_total = 0;
pfd[0].fd = so;
pfd[0].events = POLLOUT;
while (1) {
nready = poll(pfd, 1, -1);
if (nready == -1)
err(1, "poll");
if ((pfd[0].revents & (POLLERR|POLLNVAL)))
Re: libtool -bindir support
On Sun, Jul 31, 2016 at 07:21:39PM +0200, Antoine Jacoutot wrote:
> On July 31, 2016 7:14:21 PM GMT+02:00, j...@wxcvbn.org wrote:
> >
> >Making read(2) return EISDIR for directories breaks two ports, both
> >because they use libtool -bindir. cc(1) gets executed with an unknown
> >option, -bindir, and a path such as /usr/local/bin, which then gets
> >passed to ld(1). ld(1) copes with read(2) returning 0, not with
> >EISDIR.
> >Thanks to Antoine who ran the bulk builds that exposed this problem.
> >
> >-bindir support is meaningless on OpenBSD so handling that option
> >should
> >be easy. The problem is that I don't know how to implement it in
> >libtool(1). GNU libtool recognizes -bindir among cc flags, while our
> >version seems to only handle options passed right after argv[0].
> >
> >I plan to work around that problem by using GNU libtool for the ports
> >mentioned above, but someone else might want to poke at libtool(1)
> >internals. :)
> >
> >--
> >jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524
> >E7EE
>
> I can have a look at it during g2k16 if no one beats me to it.
> --
> Antoine
Hi Jeremie.
This seems to do the trick for me:
Index: LT/Getopt.pm
===
RCS file: /cvs/src/usr.bin/libtool/LT/Getopt.pm,v
retrieving revision 1.12
diff -u -p -r1.12 Getopt.pm
--- LT/Getopt.pm19 Mar 2014 02:16:22 - 1.12
+++ LT/Getopt.pm1 Aug 2016 10:18:03 -
@@ -292,6 +292,11 @@ MAINLOOP2:
if ($arg =~ m/^\-\-$/) {
next; # XXX ?
}
+ # ignore "-bindir /path/to/dir" on OpenBSD (matches GNU libtool)
+ if ($arg =~ m/^\-bindir$/) {
+ shift @main::ARGV;
+ next;
+ }
if ($arg =~ m/^\-/) {
for my $opt (@options) {
if ($opt->match($arg, $self)) {
--
Antoine
Re: [PATCH] afterboot.8: clarify mail aliases handling
On Mon, Aug 01, 2016 at 08:32:12AM +0100, Jason McIntyre wrote: > On Sun, Jul 31, 2016 at 10:39:43PM +0300, Consus wrote: > > We have smtpd(8) that now uses file-based aliases table instead of > > db-based. This table backend requires running > > > > $ smtpctl update table aliases > > > > instead of > > > > $ newaliases > > > > in order to fetch changes. However, afterboot(8) still mentions the old > > way of doing things. > > --- > > share/man/man8/afterboot.8 | 8 +--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/share/man/man8/afterboot.8 b/share/man/man8/afterboot.8 > > index b754484..d7f9760 100644 > > --- a/share/man/man8/afterboot.8 > > +++ b/share/man/man8/afterboot.8 > > @@ -463,9 +463,11 @@ manager: root > > dumper:root > > .Ed > > .Pp > > -Run > > -.Xr newaliases 8 > > -after changes. > > +After changes you should tell your running mail agent to update it's > > +configuration. > > +Run: > > +.Pp > > +.Dl $ smtpctl update table aliases > > .Ss Mail > > The default mail agent on > > .Ox > > -- > > 2.9.0 > > > > i think you're right that the newaliases sentence should be removed. i'm > less sure about the change you propose though...it might be simpler to > tell people to restart smtpd, but even then i'm not sure this is the > business of afterboot(8). look at the text immediately after, which > shows how to change the mailer to accept external connections: it makes > no mention of restarting smtpd. in general, that's a normal pattern. > > i know afterboot(8) is a little different though. > > still, i would be inclined to say let's just zap the newaliases sentence. > agreed -- Gilles Chehade https://www.poolp.org @poolpOrg
armv7/imx: imxdisplay(4)
The following unfinished patch introduces the imxdisplay(4) driver
aiming to add HDMI framebuffer support on the armv7/imx6 platform:
imxdisplay0 at simplebus0
imxdisplay0: 240x322
Currently it sets up rasops(9) and adds functions for handling/enabling
the clocks and PLLs for the HDMI transmitter through the control module.
Ian
Index: sys/arch/armv7/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.31
diff -u -p -r1.31 GENERIC
--- sys/arch/armv7/conf/GENERIC 12 Jul 2016 19:17:49 - 1.31
+++ sys/arch/armv7/conf/GENERIC 1 Aug 2016 07:32:00 -
@@ -54,6 +54,8 @@ sdmmc*at imxesdhc?# SD/MMC bus
imxahci* at fdt? # AHCI/SATA
imxehci* at fdt? # EHCI
usb* at imxehci?
+imxdisplay*at fdt? # HDMI
+wsdisplay* at imxdisplay?
# OMAP3xxx/OMAP4xxx SoC
omap0 at mainbus?
Index: sys/arch/armv7/imx/files.imx
===
RCS file: /cvs/src/sys/arch/armv7/imx/files.imx,v
retrieving revision 1.15
diff -u -p -r1.15 files.imx
--- sys/arch/armv7/imx/files.imx12 Jul 2016 19:17:49 - 1.15
+++ sys/arch/armv7/imx/files.imx1 Aug 2016 07:32:00 -
@@ -51,3 +51,8 @@ file arch/armv7/imx/imxesdhc.c imxesdhc
device imxahci: scsi, atascsi
attach imxahci at fdt
file arch/armv7/imx/imxahci.cimxahci
+
+device imxdisplay: wsemuldisplaydev, rasops16
+attach imxdisplay at fdt
+file arch/armv7/imx/imxdisplay.c imxdisplay
+
Index: sys/arch/armv7/imx/imxccm.c
===
RCS file: /cvs/src/sys/arch/armv7/imx/imxccm.c,v
retrieving revision 1.5
diff -u -p -r1.5 imxccm.c
--- sys/arch/armv7/imx/imxccm.c 30 May 2015 08:09:19 - 1.5
+++ sys/arch/armv7/imx/imxccm.c 1 Aug 2016 07:32:00 -
@@ -75,6 +75,9 @@
#define CCM_ANALOG_PLL_USB2_SET0x4024
#define CCM_ANALOG_PLL_USB2_CLR0x4028
#define CCM_ANALOG_PLL_SYS 0x4030
+#define CCM_ANALOG_PLL_VIDEO 0x40A0
+#define CCM_ANALOG_PLL_VIDEO_SET 0x40A4
+#define CCM_ANALOG_PLL_VIDEO_CLR 0x40A8
#define CCM_ANALOG_USB1_CHRG_DETECT0x41b0
#define CCM_ANALOG_USB1_CHRG_DETECT_SET0x41b4
#define CCM_ANALOG_USB1_CHRG_DETECT_CLR0x41b8
@@ -114,6 +117,8 @@
#define CCM_CSCDR1_UART_PODF_MASK 0x7
#define CCM_CCGR1_ENET (3 << 10)
#define CCM_CCGR2_I2C(x) (3 << (6 + 2*x))
+#define CCM_CCGR2_HDMI_TX_ISFRCLK (3 << 4)
+#define CCM_CCGR2_HDMI_TX_IAHBCLK (3 << 0)
#define CCM_CCGR4_125M_PCIE(3 << 0)
#define CCM_CCGR5_100M_SATA(3 << 4)
#define CCM_CCGR6_USBOH3 (3 << 0)
@@ -151,6 +156,10 @@
#define CCM_PMU_MISC1_LVDSCLK1_CLK_SEL_MASK(0x1f << 0)
#define CCM_PMU_MISC1_LVDSCLK1_OBEN(1 << 10)
#define CCM_PMU_MISC1_LVDSCLK1_IBEN(1 << 12)
+#define CCM_ANALOG_PLL_VIDEO_ENABLE(1 << 13)
+#define CCM_ANALOG_PLL_VIDEO_LOCK (1U << 31)
+#define CCM_ANALOG_PLL_VIDEO_POWERDOWN (1 << 12)
+#define CCM_ANALOG_PLL_VIDEO_BYPASS(1 << 16)
#define HCLK_FREQ 24000
#define PLL3_80M 8
@@ -220,9 +229,11 @@ void imxccm_disable_usb2_chrg_detect(voi
void imxccm_enable_pll_usb1(void);
void imxccm_enable_pll_usb2(void);
void imxccm_enable_pll_enet(void);
+void imxccm_enable_pll_video(void);
void imxccm_enable_enet(void);
void imxccm_enable_sata(void);
void imxccm_enable_pcie(void);
+void imxccm_enable_hdmi(void);
struct cfattachimxccm_ca = {
sizeof (struct imxccm_softc), NULL, imxccm_attach
@@ -518,6 +529,23 @@ imxccm_enable_pll_enet(void)
}
void
+imxccm_enable_pll_video(void)
+{
+ struct imxccm_softc *sc = imxccm_sc;
+
+ if (HREAD4(sc, CCM_ANALOG_PLL_VIDEO) & CCM_ANALOG_PLL_VIDEO_ENABLE)
+ return;
+
+ HCLR4(sc, CCM_ANALOG_PLL_VIDEO, CCM_ANALOG_PLL_VIDEO_POWERDOWN);
+
+ HSET4(sc, CCM_ANALOG_PLL_VIDEO, CCM_ANALOG_PLL_VIDEO_ENABLE);
+
+ while(!(HREAD4(sc, CCM_ANALOG_PLL_VIDEO) & CCM_ANALOG_PLL_VIDEO_LOCK));
+
+ HCLR4(sc, CCM_ANALOG_PLL_VIDEO, CCM_ANALOG_PLL_VIDEO_BYPASS);
+}
+
+void
imxccm_enable_enet(void)
{
struct imxccm_softc *sc = imxccm_sc;
@@ -554,6 +582,16 @@ imxccm_enable_pcie(void)
HWRITE4(sc, CCM_ANALOG_PLL_ENET_SET, CCM_ANALOG_PLL_ENET_125M_PCIE);
HSET4(sc, CCM_CCGR4, CCM_CCGR4_125M_PCIE);
+}
+
+void
+imxccm_enable_hdmi(void)
+{
+ struct imxccm_softc *sc = imxccm_sc;
+
+ imxccm_enable_pll_video();
+ HSET4(sc, CCM_CCGR2, CCM_CCGR2_HDMI_TX_ISFRCLK);
+ HSET4(sc, CC
Re: [PATCH] afterboot.8: clarify mail aliases handling
On Sun, Jul 31, 2016 at 10:39:43PM +0300, Consus wrote: > We have smtpd(8) that now uses file-based aliases table instead of > db-based. This table backend requires running > > $ smtpctl update table aliases > > instead of > > $ newaliases > > in order to fetch changes. However, afterboot(8) still mentions the old > way of doing things. > --- > share/man/man8/afterboot.8 | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/share/man/man8/afterboot.8 b/share/man/man8/afterboot.8 > index b754484..d7f9760 100644 > --- a/share/man/man8/afterboot.8 > +++ b/share/man/man8/afterboot.8 > @@ -463,9 +463,11 @@ manager: root > dumper: root > .Ed > .Pp > -Run > -.Xr newaliases 8 > -after changes. > +After changes you should tell your running mail agent to update it's > +configuration. > +Run: > +.Pp > +.Dl $ smtpctl update table aliases > .Ss Mail > The default mail agent on > .Ox > -- > 2.9.0 > i think you're right that the newaliases sentence should be removed. i'm less sure about the change you propose though...it might be simpler to tell people to restart smtpd, but even then i'm not sure this is the business of afterboot(8). look at the text immediately after, which shows how to change the mailer to accept external connections: it makes no mention of restarting smtpd. in general, that's a normal pattern. i know afterboot(8) is a little different though. still, i would be inclined to say let's just zap the newaliases sentence. jmc
