Re: W^X -wxneeded backported to 6.0-stable?

[Jack J. Woehr]

Theo de Raadt wrote:

You have clients and work, so instead your spam this mailing list?

I thought it might be a known problem. OpenBSD is your whole world. It's a very 
important part
of mine, but I really can't keep up on everything that flies by on the list as 
I did 18 years ago.

And it's not spam. It's just a question. You're a very silly person, sometimes, 
Mr. de Raadt.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

Re: W^X -wxneeded backported to 6.0-stable?

[Theo de Raadt]

>Theo de Raadt wrote:
>> In other words, it is pretty simple -- reinstall, and prove reproducibility. 
>
>I have clients and work to do. Did this all on a Sunday night.

You have clients and work, so instead your spam this mailing list?

That is the problem: Selfishness.

Re: W^X -wxneeded backported to 6.0-stable?

[Theo de Raadt]

>Theo de Raadt wrote:
>> In other words, it is pretty simple -- reinstall, and prove reproducibility. 
>
>I have clients and work to do. Did this all on a Sunday night.
>
>> And frankly, doing your entire system as /, should almost be an unsupported 
>> option. It is a ridiculous configuration 
>> for about 20 reasons. 
>
>Mais oui, m'sieu. Was my first try at whole-disk encryption. Next time I build 
>a new machine, I'll do it right.

That has nothing to do with having one / partition, via many partitions.

And secondly when it is the first try, and flaws become evident, why
keep digging a deeper hole.

Even the sorries become noise.

Re: W^X -wxneeded backported to 6.0-stable?

[Jack J. Woehr]

Theo de Raadt wrote:
In other words, it is pretty simple -- reinstall, and prove reproducibility. 


I have clients and work to do. Did this all on a Sunday night.

And frankly, doing your entire system as /, should almost be an unsupported option. It is a ridiculous configuration 
for about 20 reasons. 


Mais oui, m'sieu. Was my first try at whole-disk encryption. Next time I build 
a new machine, I'll do it right.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

Re: W^X -wxneeded backported to 6.0-stable?

[Jack J. Woehr]

Stuart Henderson wrote:

In 6.0 the packages for these did not have WXNEEDED annotations so
they would trigger the log, however the kernel did not enforce it on
wxallowed fs. So it expected to see this in dmesg but it is not expected
for them to die for this reason


Thanks, Stuart. Some Java stuff certainly seems to behave oddly. TN5250J hangs 
on exit sometimes.
Some NetBeans windows behave differently than they did on 5.9. But I'm getting 
work done, so I'm
reasonably happy. ("What? Did you want him to be *unreasonably* happy?" - 
George Carlin)

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

Re: W^X -wxneeded backported to 6.0-stable?

[Stuart Henderson]

On 2016/09/21 09:49, Jack J. Woehr wrote:
> As noted on the ports mailing list, after 6.0 upgrade/cvs source/build 
> kernel/build world/pkg_add -u I am experiencing
> wx violations on a single whole-disk label mounted as / wxallowed.

I see no changes between 6.0 and 6.0-stable in this area.


> Solène Rapenne  posted:
> 
> > On -current binaries now needs both wxallowed on their mountpoint AND have 
> > to be compiled with -wxneeded flag.
> > 
> > Maybe this has been backported to 6.0-stable ? I don't know where to
> > look to check that. Maybe someone have a clue ?
> 
> Any tips?
> 
> Example errors from dmesg:
> 
> seamonkey(89184): mmap W^X violation
> java(79321): mprotect W^X violation

In 6.0 the packages for these did not have WXNEEDED annotations so
they would trigger the log, however the kernel did not enforce it on
wxallowed fs. So it expected to see this in dmesg but it is not expected
for them to die for this reason.

In -current after 6.0 the kernel enforced it strictly for non-WXNEEDED
executables for a while and killed the process if it made any W|X map
requests.

In ports-land after this, many ports gained WXNEEDED annotations so
they would run normally and not print a message.

After that (and still present) this changed to failing W|X map
requests and logging, but not killing the process. In some cases they
will accept the failure and handle it gracefully; in most cases they
won't. Again those executables with WXNEEDED annotations work
normally if they are on a "wxallowed" filesystem..


> Output of mount command:
> 
> /dev/sd1a on / type ffs (local, wxallowed)
> 
> Output of dmesg command:
> 
> OpenBSD 6.0-stable (GENERIC.MP) #0: Sun Sep 18 20:37:21 MDT 2016
> jax@varian.jaxrcfb:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8553762816 (8157MB)
> avail mem = 8290054144 (7906MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb040 (17 entries)
> bios0: vendor American Megatrends Inc. version "R0200V3" date 02/10/2011
> bios0: Sony Corporation VPCF215FX
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC HPET SLIC MCFG SSDT SSDT ECDT SSDT
> acpi0: wakeup devices PEG0(S4) B0D4(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3)
> USB5(S3) USB6(S3) USB7(S3) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4)
> PXSX(S4) RP03(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.76 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> cpu4 at mainbus0: apid 1 (application processor)
> cpu4: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
> cpu4: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu4: 256KB 64b/line 8-way L2 cache
> cpu4: smt 1, core 0, package 0
> cpu5 at 

Re: W^X -wxneeded backported to 6.0-stable?

[Theo de Raadt]

> On 2016/09/21 09:49, Jack J. Woehr wrote:
> > As noted on the ports mailing list, after 6.0 upgrade/cvs source/build =
> kernel/build world/pkg_add -u I am experiencing
> > wx violations on a single whole-disk label mounted as / wxallowed.
> 
> I see no changes between 6.0 and 6.0-stable in this area.
> 
> 
> > Sol=E8ne Rapenne  posted:
> >=20
> > > On -current binaries now needs both wxallowed on their mountpoint AND=
>  have to be compiled with -wxneeded flag.
> > >=20
> > > Maybe this has been backported to 6.0-stable ? I don't know where to
> > > look to check that. Maybe someone have a clue ?
> >=20
> > Any tips?
> >=20
> > Example errors from dmesg:
> >=20
> > seamonkey(89184): mmap W^X violation
> > java(79321): mprotect W^X violation
> 
> In 6.0 the packages for these did not have WXNEEDED annotations so
> they would trigger the log, however the kernel did not enforce it on
> wxallowed fs. So it expected to see this in dmesg but it is not expected
> for them to die for this reason.
> 
> In -current after 6.0 the kernel enforced it strictly for non-WXNEEDED
> executables for a while and killed the process if it made any W|X map
> requests.
> 
> In ports-land after this, many ports gained WXNEEDED annotations so
> they would run normally and not print a message.
> 
> After that (and still present) this changed to failing W|X map
> requests and logging, but not killing the process. In some cases they
> will accept the failure and handle it gracefully; in most cases they
> won't. Again those executables with WXNEEDED annotations work
> normally if they are on a "wxallowed" filesystem..
> 
> 
> > Output of mount command:
> >=20
> > /dev/sd1a on / type ffs (local, wxallowed)
> >=20
> > Output of dmesg command:
> >=20
> > OpenBSD 6.0-stable (GENERIC.MP) #0: Sun Sep 18 20:37:21 MDT 2016
> > jax@varian.jaxrcfb:/usr/src/sys/arch/amd64/compile/GENERIC.MP

In other words, it is pretty simple -- reinstall, and prove reproducibility.

And frankly, doing your entire system as /, should almost be an
unsupported option.  It is a ridiculous configuration for about 20
reasons.