chromium crashes on latest version
Synopsis: chromium crashes when loading certain websites or resizes window while sites are loaded Category: user Environment: System : OpenBSD 6.6 Details : OpenBSD 6.6-current (GENERIC.MP) #40: Sun Mar 8 20:17:34 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: After upgrading to latest snapshot and packages chromium (chromium-80.0.3987.132p0) crashes when I loaded cnn.com and some other sites. When I load twitter.com (not logged in, usually on various people's twitter pages) and resize (double clicking on top bar to maximize) it also crashes. How-To-Repeat: Load cnn.com or twitter.com and resize chromium window (maximize) Fix: Nothing I've tried yet! dmesg: OpenBSD 6.6-current (GENERIC.MP) #40: Sun Mar 8 20:17:34 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8254586880 (7872MB) avail mem = 7991812096 (7621MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9c000 (68 entries) bios0: vendor LENOVO version "G2ETB7WW (2.77 )" date 09/24/2019 bios0: LENOVO 2324A57 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI POAT SSDT SSDT DMAR UEFI DBG2 acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.56 MHz, 06-3a-09 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT, DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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: 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT, DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 4 (EXP3) acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2 acpitz0 at acpi0: critical temperature is 103 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 tpm0 at acpi0: TPM_ addr 0xfed4/0x5000, device 0x104a rev 0x4e acpibat0 at acpi0: BAT0 model "45N1023" serial 16566 type LION oem "SANYO" acpiac0 at acpi0: AC unit online "LEN0078" at acpi0 not configured acpithinkpad0 at acpi0: version 1.0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured acpidock0 at acpi0: GDCK not docked (0) acpivideo0 at acpi0: VID_ acpivout0 at acpivideo0: LCD0 acpivideo1 at acpi0: VID_ cpu0: using VERW MDS workaround (except on vmm entry) cpu0: Enhanced SpeedStep 2594 MHz: speeds: 2601, 2600, 2500, 2400, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 drm0 at inteldrm0 inteldrm0: msi xhci0 at pci0 dev 20 function 0 "Intel 7 Series xHCI" rev 0x04: msi, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 "Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address 3c:97:0e:1f:de:53 ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 7
Re: Process killed on self-exec after pledge+unveil
Sebastien Marie wrote:
> On Sun, Mar 08, 2020 at 12:04:07AM +, int3resting27 wrote:
> > Example program:
> >
> > #include
> > #include
> > int main(int argc, char **argv) {
> > char *const args[] = { "Z", NULL, };
> > char *const env[] = { NULL, };
> >
> > if (argv[0][0] == 'Z') {
> > printf("success\n");
> > return (0);
> > }
> >
> > unveil(argv[0], "x");
> > pledge("exec", "stdio rpath");
> > execve(argv[0], args, env);
> > }
> >
> > Expected behavior: execve's itself then prints "success" and exits
> > Actual behavior: killed by SIGABRT when calling execve. It doesn't seem
> > to be pledge's usual SIGABRT because nothing gets logged to syslog like
> > pledge is supposed to do and core isn't dumped
>
> unveil(2) setting in the process isn't cleared on execve(2) due to
> execpromises
> use. see https://github.com/openbsd/src/blob/master/sys/kern/kern_exec.c#L530
>
> I am unsure if it is intented or not. but at some point, it has been discussed
> if unveil(2) should be inherited or not (comments in kern_exec.c are trace of
> that).
>
> For now, you need to unveil(2) all files required to reexecute your file, or
> not
> use execpromises.
Don't use execpromises.
The code for it will probably be deleted.
There were all sorts of mocking words about pledge not being carried over
through execve, so I provided a tool that would do it.
I tried to do it for $PAGER and $EDITOR in many programs. It is
basically impossible to handle symbolic link traversal, as well as
the potential for the sub-program to want to do more. And then get
killed. So I introduced "error", and found out that some editors fail
just as hard as having been killed when they receive an unexpected error.
But I waited a bit longer, to see if anyone found a usage case and could
make it work.
Noone has. The people who said pledge is wrong because it can't be maintained
over execve are wrong -- rather than understanding the workings of Unix they
are only thinking of their impossible desires.
Re: Process killed on self-exec after pledge+unveil
On Sun, Mar 08, 2020 at 12:04:07AM +, int3resting27 wrote:
> Example program:
>
> #include
> #include
> int main(int argc, char **argv) {
> char *const args[] = { "Z", NULL, };
> char *const env[] = { NULL, };
>
> if (argv[0][0] == 'Z') {
> printf("success\n");
> return (0);
> }
>
> unveil(argv[0], "x");
> pledge("exec", "stdio rpath");
> execve(argv[0], args, env);
> }
>
> Expected behavior: execve's itself then prints "success" and exits
> Actual behavior: killed by SIGABRT when calling execve. It doesn't seem
> to be pledge's usual SIGABRT because nothing gets logged to syslog like
> pledge is supposed to do and core isn't dumped
unveil(2) setting in the process isn't cleared on execve(2) due to execpromises
use. see https://github.com/openbsd/src/blob/master/sys/kern/kern_exec.c#L530
I am unsure if it is intented or not. but at some point, it has been discussed
if unveil(2) should be inherited or not (comments in kern_exec.c are trace of
that).
For now, you need to unveil(2) all files required to reexecute your file, or not
use execpromises.
Thanks.
--
Sebastien Marie
Re: Process killed on self-exec after pledge+unveil
int3resting27 wrote:
> Example program:
>
> #include
> #include
> int main(int argc, char **argv) {
> char *const args[] = { "Z", NULL, };
> char *const env[] = { NULL, };
>
> if (argv[0][0] == 'Z') {
> printf("success\n");
> return (0);
> }
>
> unveil(argv[0], "x");
> pledge("exec", "stdio rpath");
> execve(argv[0], args, env);
> }
>
> Expected behavior: execve's itself then prints "success" and exits
You are making quite a big an assumption, and it is wrong.
Process killed on self-exec after pledge+unveil
Example program:
#include
#include
int main(int argc, char **argv) {
char *const args[] = { "Z", NULL, };
char *const env[] = { NULL, };
if (argv[0][0] == 'Z') {
printf("success\n");
return (0);
}
unveil(argv[0], "x");
pledge("exec", "stdio rpath");
execve(argv[0], args, env);
}
Expected behavior: execve's itself then prints "success" and exits
Actual behavior: killed by SIGABRT when calling execve. It doesn't seem
to be pledge's usual SIGABRT because nothing gets logged to syslog like
pledge is supposed to do and core isn't dumped
What fixes it:
- execve-ing something other than argv[0]
- unveiling /usr/libexec/ld.so and /usr/lib with "r" permission
(along with the original unveil) before execve. Not unveiling /usr/lib
makes ld.so complain about not finding libc.so
- Removing the pledge or unveil or both
- Setting pledge execpromises to NULL
What doesn't fix it:
- Setting pledge promises to NULL
- Setting every single pledge promise (including "error") for both
of pledge's arguments
- Unveiling everything except /usr/libexec/ld.so with "rwxc" permissions
(Surprisingly ld.so works without /usr/lib this time...)
- execve-ing a symlink (killed with SIGABRT) or a hard link (execve
returns with ENOENT) to the same program
- Checking return codes. None of the functions return errors
Another interesting effect is that removing "rpath" from execpromises
also causes the SIGABRT when execve-ing any program, not just argv[0].
This should really be documented in the pledge manpage!
Reproduced on 6.6-stable and one day old -current on amd64
Re: -current 100% CPU, softdep related
I can confirm that the softdep related hangs i saw are gone. No more issues since the beginning of my tests almost one week ago. Thanks, -Mark On 2020-03-09 17:51, Todd C. Miller wrote: I just committed my minimal fix. - todd -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
Re: -current 100% CPU, softdep related
I just committed my minimal fix. - todd
Re: -current 100% CPU, softdep related
On Sun, Mar 08, 2020 at 10:15:08AM -0600, Todd C. Miller wrote: > On Sat, 07 Mar 2020 19:35:10 -0700, Bob Beck wrote: > > > makes sense to me and has my ok. could we see if bluhm@ can be sure this > > still works with his workload? > > Thanks, waiting to see if bluhm@ can confirm this doesn't cause > problems makes sense. I'm currently travelling but will be home > this evening. Diff makes sense, OK bluhm@ I am trying to get this installed on our 6.6 production server where all the vnd, softdep and needbuf bugs showed up. bluhm
