Firefox Tab crashed due to some pledge error

x[71886]: pledge "proc", syscall 2 firefox[71886]: pledge "stdio", syscall 83 firefox[60964]: pledge "proc", syscall 2 firefox[12397]: pledge "proc", syscall 2 firefox[86483]: pledge "proc", syscall 2 firefox[5602]: pledge "proc", syscall 2 firefox[67287]: pledge "proc", syscall 2 firefox[84851]: pledge "proc", syscall 2 firefox[55785]: pledge "proc", syscall 2 firefox[52724]: pledge "proc", syscall 2 firefox[52724]: pledge "stdio", syscall 83 firefox[23437]: pledge "proc", syscall 2 firefox[92932]: pledge "proc", syscall 2 -- Thank you! Sincere regards; Neeraj Pal

Re: Firefox Tab crashed due to some pledge error

090 >> vscsi0 at root >> scsibus3 at vscsi0: 256 targets >> softraid0 at root >> scsibus4 at softraid0: 256 targets >> root on sd0a (034672908a364eeb.a) swap on sd0b dump on sd0b >> iwm0: hw rev 0x230, fw ver 22.361476.0, address 44:03:2c:a0:e5:d3 >> lock order reversal: >> 1st 0x81dbb6f8 _lock (_lock) @ >> /usr/src/sys/kern/kern_synch.c:444 >> 2nd 0x8023b270 _priv->irq_lock (_priv->irq_lock) @ >> /usr/src/sys/dev/pci/drm/i915/intel_lrc.c:1645 >> lock order "_priv->irq_lock"(mutex) -> "_lock"(sched_lock) >> first seen at: >> #0 witness_checkorder+0x4b4 >> #1 ___mp_lock+0x70 >> #2 wakeup_n+0x39 >> #3 task_add+0x93 >> #4 gen6_rps_boost+0x129 >> #5 __i915_wait_request+0x155 >> #6 i915_gem_object_wait_rendering__nonblocking+0x1d6 >> #7 i915_gem_set_domain_ioctl+0xdb >> #8 drm_do_ioctl+0x221 >> #9 drmioctl+0xf9 >> #10 VOP_IOCTL+0x5a >> #11 vn_ioctl+0x6b >> #12 sys_ioctl+0x457 >> #13 syscall+0x32a >> #14 Xsyscall_untramp+0xc0 >> lock order "_lock"(sched_lock) -> "_priv->irq_lock"(mutex) >> first seen at: >> #0 witness_checkorder+0x4b4 >> #1 _mtx_enter+0x31 >> #2 gen8_logical_ring_put_irq+0x36 >> #3 __i915_wait_request+0x367 >> #4 i915_gem_object_wait_rendering__nonblocking+0x1d6 >> #5 i915_gem_set_domain_ioctl+0xdb >> #6 drm_do_ioctl+0x221 >> #7 drmioctl+0xf9 >> #8 VOP_IOCTL+0x5a >> #9 vn_ioctl+0x6b >> #10 sys_ioctl+0x457 >> #11 syscall+0x32a >> #12 Xsyscall_untramp+0xc0 >> iwm0: reused group key update received from 70:62:b8:8b:1f:ae >> firefox[71886]: pledge "proc", syscall 2 >> firefox[71886]: pledge "stdio", syscall 83 >> firefox[60964]: pledge "proc", syscall 2 >> firefox[12397]: pledge "proc", syscall 2 >> firefox[86483]: pledge "proc", syscall 2 >> firefox[5602]: pledge "proc", syscall 2 >> firefox[67287]: pledge "proc", syscall 2 >> firefox[84851]: pledge "proc", syscall 2 >> firefox[55785]: pledge "proc", syscall 2 >> firefox[52724]: pledge "proc", syscall 2 >> firefox[52724]: pledge "stdio", syscall 83 >> firefox[23437]: pledge "proc", syscall 2 >> firefox[92932]: pledge "proc", syscall 2 >> >> >> >> >> -- >> >> Thank you! >> Sincere regards; >> >> Neeraj Pal >> -- Thank you! Sincere regards; Neeraj Pal

Extracting pledge information from kernel code for every process.

it possible to get same pledge hex bit for different pledge parameters? Or, Is there some other pledge variable in kernel which keeps track of permission bits that pass from user-space code using pledge()? Is it the correct way that I did above to extract pledge information or Am I missing or doing it wrong? -- Thank you, Neeraj Pal ツ  +91-8130344470

Regarding pledge system call bit value for a non-pledged process

pledge value. And, I don't know why every non-pledge process has only this value. It seems like there is some default pledge value for every process. So, please guys give me some hint or update me on something if I forgot or missed. -- Thank you, Neeraj Pal

Re: Regarding pledge system call bit value for a non-pledged process

t;s...@spacehopper.org> wrote: > On 2018/02/18 20:05, Neeraj Pal wrote: >> On Sun, Feb 18, 2018 at 6:21 PM, Stuart Henderson <s...@spacehopper.org> >> wrote: >> > On 2018/02/18 12:36, Neeraj Pal wrote: >> >> I read kern_pledge.c file, but, I am not able to fi

Re: Regarding pledge system call bit value for a non-pledged process

art Henderson <s...@spacehopper.org> wrote: > On 2018/02/18 16:25, Stuart Henderson wrote: >> On 2018/02/18 21:19, Neeraj Pal wrote: >> > yeah, but I am asking about pledge_xbit (pledge value of any process >> > in hex). See output: >> > >> > process name: plt

Re: Regarding pledge system call bit value for a non-pledged process

ssions like "stdio inet" etc. On Sun, Feb 18, 2018 at 8:45 PM, Stuart Henderson <s...@spacehopper.org> wrote: > On 2018/02/18 20:00, Neeraj Pal wrote: >> Okay. So, you told me that If I need to check which process pledge >> what, then I need to first check P

Re: Regarding pledge system call bit value for a non-pledged process

an example of sample1 code that I sent, then from where and how kernel computes this, 0x8009588f pledge bit value. On Sun, Feb 18, 2018 at 6:21 PM, Stuart Henderson <s...@spacehopper.org> wrote: > On 2018/02/18 12:36, Neeraj Pal wrote: >> I read kern_pledge.c file, but, I am not abl

Re: Regarding pledge system call bit value for a non-pledged process

On Sun, Feb 18, 2018 at 6:21 PM, Stuart Henderson <s...@spacehopper.org> wrote: > On 2018/02/18 12:36, Neeraj Pal wrote: >> I read kern_pledge.c file, but, I am not able to figure out the pledge >> bit value of a program which isn't using pledge() system call in >> user-

Re: Error in adding system call in OpenBSD 6.3

On Sun, Apr 22, 2018 at 3:14 AM, Paul Irofti <p...@irofti.net> wrote: > On Sun, Apr 22, 2018 at 12:23:09AM +0530, Neeraj Pal wrote: >> Hello guys, >> >> I am facing some issue during adding system call on OpenBSD 6.3. I >> have shown my pathways to add sy

Error in adding system call in OpenBSD 6.3

Hello guys, I am facing some issue during adding system call on OpenBSD 6.3. I have shown my pathways to add system call, please guys correct me if somewhere I have forgotten something to add or build. 1) echo "331 { int sys_hello(void); }" >> /usr/src/sys/kern/syscalls.master 2) make

Re: Error in adding system call in OpenBSD 6.3

And, from on next time I will keep things clear. So, that it would be easy to answer for everyone. And also I will try to solve the problem on my own and giving more time for self research instead of just asking here. On Tue, Apr 24, 2018 at 7:45 AM, Ted Unangst <t...@tedunangst.com> wro

Re: Error in adding system call in OpenBSD 6.3

en_t;/* length type for network syscalls */ ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** Error 1 in /usr/src/sys/arch/amd64/compile/CUSTOM.MP (Makefile:1018 'sys_test.o') On Tue, Apr 24, 2018 at 12:18 AM, Ted Unangst &l

Re: Error in adding system call in OpenBSD 6.3

, Theo de Raadt <dera...@openbsd.org> wrote: > So. you don't know what you are doing. > > > Neeraj Pal <neerajpa...@gmail.com> wrote: >> okay. Sure, >> >> Instead of sys_hello.c I created a new one sys_test.c. So, guys don't >> confuse with

Re: pkg_add -Dsnap not fetching any updates and packages on -current

Benoit wrote: > > Neeraj Pal(neerajpa...@gmail.com) on 2018.10.15 10:36:16 +0530: > > Hi there, > > > > Yesterday I installed OpenBSD 6.3-stable then upgraded it to OpenBSD > > -current by downloading and copying bsd.rd file into / > > Then, after that

pkg_add -Dsnap not fetching any updates and packages on -current

/amd64/: empty Can't find wget -- Thank you! Sincere regards; Neeraj Pal

Regarding the understanding of the malloc(3) code

Hi there, I am reading and learning the internals of malloc(3). So, after compiling the debug version of libc and using it for one basic sample code for malloc(3). Not able to understand some parts of the following code snippet: void _malloc_init(int from_rthreads) { u_int i, nmutexes;

Re: Regarding the understanding of the malloc(3) code

On Tue, Mar 10, 2020 at 4:03 PM Otto Moerbeek wrote: > There's an off by one in your question :-) Yeah, sorry about that, actually in flow of writing the mail forgot to notice. > Fo single threaded programs, two malloc_dir pools are maintained. > One for MAP_CONCEALED memory (#0) and one for

Re: Regarding the understanding of the malloc(3) code

On Wed, Mar 25, 2020 at 2:06 AM Otto Moerbeek wrote: > pp points to a page of chunks > bp point to the associated meta info: a bitmap that says which chunks > in the page are free. The bitmap is an aray of shorts, so 16 bits per > entry. > per entry means for our case bits[1], so only one

Re: Regarding the understanding of the malloc(3) code

chunk_info structure. Like for count = 256 case, size = (16 - 1) * 2 = 30. Then if canary then it calculates for the canary. So, from here, it calculates the size for bitmap like I have already mentioned above, that memset doing 30 bytes for bits = 4. So, that 30 bytes comes from here? Thanks, Neeraj Pal

Re: Regarding the understanding of the malloc(3) code

Hi Otto, I am having two small issues or confusions: First Query: 885 /* 886 * Allocate a page of chunks 887 */ 888 static struct chunk_info * 889 omalloc_make_chunks(struct dir_info *d, int bits, int listnum) 890 { 891 struct chunk_info *bp; 892 void *pp; 893 894

Re: Regarding the understanding of the malloc(3) code

On Fri, Mar 13, 2020, at 11:45 AM Otto Moerbeek wrote: > > Please indent your code snippets. yeah, my apologies. I shall indent the code snippets. > > di_info is special. Having a guard page on both sides for regular > allocation can be done, but would waste more pages. Note that > allocations

Re: Regarding the understanding of the malloc(3) code

On Wed, 18 Mar, 2020, 12:46 pm Otto Moerbeek, wrote: > There are several types of canaries. They try to detect corruption of > various meta data structures. There are alo canaries for user allocated > data, they are enabled with the C option. > Yeah, I am using option C through sysctl(8) to

Re: Regarding the understanding of the malloc(3) code

On Wed, Mar 18, 2020 at 4:01 PM Otto Moerbeek wrote: > Not all meta-data canaries live in r/o memory. > > A thing that also helps is to follow the cvs history of a file. The > first version of my malloc (form 2008) was more simple, and looking at > the diffs through the years gives you great

run(4): crash still observed on 6.7 and -current

Hi there, I have found that the crash is still observed which had already been discussed, here, https://marc.info/?l=openbsd-tech=143662082630187=2 on -current and also on 6.7 also verified that the patch (https://marc.info/?l=openbsd-tech=143693266301743=2) sent by @stefan fixes the problem for

[PATCH] tcpdump: Fix missing argument from icmp_print call in print-skip.c

fixes the same. Regards, Neeraj Pal Index: usr.sbin/tcpdump/print-skip.c === RCS file: /cvs/src/usr.sbin/tcpdump/print-skip.c,v retrieving revision 1.6 diff -u -p -u -p -r1.6 print-skip.c --- usr.sbin/tcpdump/print-skip.c16 Nov 2015