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
Hi there,
I have found that the crash is still observed which had already been
discussed, here,
https://marc.info/?l=openbsd-tech&m=143662082630187&w=2 on -current
and also on 6.7
also verified that the patch
(https://marc.info/?l=openbsd-tech&m=143693266301743&w=2) sent by
@stefan fixes the prob
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
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 entry
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
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 hin
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 under
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 ar
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 regu
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;
s
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, I am try
s/packages/amd64/: empty
Can't find wget
--
Thank you!
Sincere regards;
Neeraj Pal
>> #12 Xsyscall_untramp+0xc0
On Sat, Jun 9, 2018 at 12:24 AM, Elias M. Mariani
wrote:
> You should read the pkg-readme for Firefox.
>
> Firefox needs a dbus session to get started with X:
>
> Check here the readme of firefox and dbus on the info and howto:
> /usr/local/share/doc
ramp+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
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 wrote:
> Neeraj Pal wrote:
at 3:04 AM, Theo de Raadt wrote:
> So. you don't know what you are doing.
>
>
> Neeraj Pal wrote:
>> okay. Sure,
>>
>> Instead of sys_hello.c I created a new one sys_test.c. So, guys don't
>> confuse with above sys_hello.c and this time sys_test.c,
n_t'?
syscallarg(socklen_t *) alen;
^
__socklen_t
/usr/src/sys/sys/syscallargs.h:17:12: note: expanded from macro 'syscallarg'
struct { x datum; } le; \
^
/usr
On Sun, Apr 22, 2018 at 3:14 AM, Paul Irofti 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 system call, please guys correc
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 init_sysen
:
> On 2018/02/18 20:05, Neeraj Pal wrote:
>> On Sun, Feb 18, 2018 at 6:21 PM, Stuart Henderson
>> 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 p
PM, Stuart Henderson 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: pltestnopledg
ween permissions like
"stdio inet" etc.
On Sun, Feb 18, 2018 at 8:45 PM, Stuart Henderson 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 PS_PLEDGE bit
>>
ke 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 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 pledg
On Sun, Feb 18, 2018 at 6:21 PM, Stuart Henderson 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-space code.
>&
ke 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 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 pledg
some 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
route proc", NULL).
But, then, how is 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
27 matches
Mail list logo
