Re: removing SVR4 binary compatibilty layer

[mokhi]

Well, I'd like to offer help keeping it (because on a personal
opinion, I'd like being compatible `:-D).
But the reasons are pretty reasonable and convincing :-).
I have no more objections against removing it when security risks involves.

--
Best wishes, MMokhi.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: removing SVR4 binary compatibilty layer

[mokhi]

Hi,

Is this removing is because no-interest on maintaining it?

If it helps, I am working to use the `kern_* instead sys_*` as
mentioned patch in that discussion suggests for svr4, if this helps.


--
Best wishes, MMokhi.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Is there possible run a MacOS X binary

[mokhi]

>  Have you considered adding it to the FreeBSD Google Summer of Code Ideas 
> wiki[2]?
>  Maybe some brave student will like the idea and decide to spend some time on 
> this project.
No I didn't, maybe it worth doing it :)
I can do it if you suggest.

I myself was brave (but officially mentor-less) while doing this :D,
(I actually didn't know how i can find a mentor for this idea).
I also didn't find interest among developers after call of review (for
logically good sensible reasons, like why should we add it in kernel,
who will maintain it, instability in first, Apple+Law issues, etc).

Best wishes, Mokhi.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Is there possible run a MacOS X binary

[mokhi]

I had started a writing a Mach-O image activator monthes ago, but
time/daily-life distracted me from continuing it.
Maybe some day I continue it :D
Currently it's available on my github[1] if it helps.
I had some success-like running of some super-simple less-than 'return
A+B' programs with it :)


Best regards, Mokhi.
==
[1] https://github.com/m0khi/FreeBSD_MachO
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: WITNESS messages on 11

[mokhi]

I'm not sure, but maybe this is related to [1].
FWIW, according to [2], LORs of witness means deadlock could be
happened in that situation (if it's not a false positive), not
necessarily an accurate deadlock happening IMO :)

I hope it helps :)

[1]http://lists.freebsd.org/pipermail/freebsd-current/2016-May/061195.html
[2]https://www.freebsd.org/doc/faq/troubleshoot.html#idp63374416

Best Regards, Mokhi.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lock order reversal errors during boot

[mokhi]

I see this LOR often too.
I thought maybe this is happening because of my Virtual Box setting :) (?!?)

On 5/21/16, Will Brokenbourgh  wrote:
> On 05/16/16 00:44, Bjoern A. Zeeb wrote:
>>> On 15 May 2016, at 07:44 , Kurt Jaeger  wrote:
>>>
>>> Hi!
>>>
 I am seeing 'lock order reversal' errors during boot on 11-CURRENT -
 r298793.  A sample error:

 lock order reversal:
   1st 0xf8011280d068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
   2nd 0xfe01ca539400 bufwait (bufwait) @
 /usr/src/sys/ufs/ffs/ffs_vnops.c:263
   3rd 0xf80112a23b78 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
 stack backtrace:
 #0 0x80a94bf0 at witness_debugger+0x70
 #1 0x80a94ae4 at witness_checkorder+0xe54
 #2 0x80a0fdd6 at __lockmgr_args+0x4d6
 #3 0x80ce9626 at ffs_lock+0xa6
 [...snip...]

 I'm not sure if this is even something I should report, but better safe
 than sorry, yes?
>>> Yes, and there's even a page to compare your LOR against other ones:
>>>
>>> http://sources.zabbadoz.net/freebsd/lor.html
>>>
>>> Can you try if you find your LOR there ? If not, can you add it
>>> to that page ?
>> No he can’t and I haven’t in years either.   Searching bugs might however
>> be a good idea;  there is a LOR category or tag somewhere.
>>
>> /bz
> Thank you for the replies.
>
> I'm getting these LORs pretty frequently.  Is this a normal occurrence
> for 11-CURRENT or is it only me having this problem?
>
> Thanks
>
> Will Brokenbourgh
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD MachO File format, your comments on it.

[mokhi]

Hi again.

I've implemented FatElf support for Elf image activator too[1] :)
Any comments/reviews on this ?
I also pinged Ryan Gordon about this.

Also im curious to know if any comments/reviews are done on MachO
implementation[2]

Best wishes and thousands of regards, Mokhi.

==
[1] https://github.com/m0khi/FreeBSD_FatElf
[2] https://github.com/m0khi/FreeBSD_MachO
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD MachO File format, your comments on it.

[mokhi]

errr, typo ...

s/an FatELF both/and FatELF both/g

:)

On 3/25/16, mokhi <mokh...@gmail.com> wrote:
> Adrian, thanks for your +1 :P
>
> So, what about EULA related things that 'David' pointed to?
> If this isn't really a big problem, I have no problem to continue on
> working on it, an FatELF both ;)
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD MachO File format, your comments on it.

[mokhi]

Adrian, thanks for your +1 :P

So, what about EULA related things that 'David' pointed to?
If this isn't really a big problem, I have no problem to continue on
working on it, an FatELF both ;)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD MachO File format, your comments on it.

[mokhi]

So, I'll try to port FatELF as well as MachO.
Choosing the better one is up to you ;)

All opinions/idea are welcome and I appreciate.

Best wishes, Mokhi.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD MachO File format, your comments on it.

[mokhi]

On 3/24/16, mokhi <mokh...@gmail.com> wrote:
> Then you think the better idea is porting FatELF to FreeBSD, rather
> than working on MachO?
>


If yes,
I am ready to put dedicated time on it :) [as I did for MachO]

But before that, you think, is there any changes we can/should make on it?

* I read something about FatELF when I was doing research for macho :)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD MachO File format, your comments on it.

[mokhi]

Then you think the better idea is porting FatELF to FreeBSD, rather
than working on MachO?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD MachO File format, your comments on it.

[mokhi]

On 3/24/16, Achim Patzner <a...@bnc.net> wrote:
> Would that project end in having an intelligent loader that will only map
> the relevant architecture to memory (i. e. I’ll have extremely fat
> executables supporting any known architecture in the universe on /usr/local
> or even for all files that can be shared between machines) and keep the load
> on memory and network as low as possible?
It'll be one of its results, (at least) I expect :D though I'm not
sure how it will have effect on network.

> automatic cross-compilation to building I feel like Christmas came early.
Then happy vacation  ;)

Thanks and thousands of regards, Mokhi.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD MachO File format, your comments on it.

[mokhi]

Hi.

I'm agreed with point you told about improvements we can do for fat
format (or more).
And I'm ready to do them (with your helps, sure :D).

But we need short steps and more of them (a local proverb :D) IMO.
If we completely do this image activator, then we can have 2 sub plans
for OSX emulation and/or fat data segment redesign.

I saw netbsd's way of mach-kernel/darwin emulation.
They have been stopped in porting/simulating quartz (the reason
described lack of developers' interest IIRC), and that relates to OSX
emulating.
If we wanna complete/continue that way, first we need this image
activator, what's your opinion about it?

BTW, in brief I believe we can have strategies to do (sub plans) and
it worth (at least for me, because I'll learn good things). What's
your opinion?


Best wishes, Mokhi.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD MachO File format, your comments on it.

[mokhi]

Hi guys.
I'm Mahdi Mokhtari (aka Mokhi between FreeBSD friends).

I am working on adding Mach-O binary format to supported formats for FreeBSD.
Not for emulations on first step, but as a native supported format
just like a.out [or Elf]
(though it can go in both ways too).

There are good reasons to have Mach-O format support IMO.
It's well/clear designed file format.
Can supports multiple Arch by default (It's Fat Format).
Because of its Fat Format support, it can even help porting/packaging easier for
projects such as Freebsd-arm or others IMO :D.
At end (even not among its interesting parts, maybe :D) point, it
leads and helps to have
OSX emulation support on FreeBSD.

BTW, i've coded[1] Mach-O support for FreeBSD with helps of
FreeBSD-ppl on IRC about various aspects of this works (from
fundamental points of VM-MAP, to SysEntVec for Mach-O format) and
with help of Elf and a.out format codes and mach-o references.
It's in Alpha state (or before it) IMO, as I'm not sure about some of
its parts, but I've tested a mach-o formatted binary with it and it at
least loads and maps it segments correctly :D. (it was actually a
simple "return 0" C Code, compiled in a OSX, if you know how can I
force my FreeBSD clang to produce mach-o files instead of ELF I'd be
happy to know it, and I appreciate :D)

I'd like to have your helps and comments on it, in hope to make it better
and make it ready for review.

Thanks and thousands of regards, Mokhi.

==
[1] https://github.com/m0khi/FreeBSD_MachO
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: thread-unsafety problems as spl*() ones are NOP

[mokhi]

So in your opinion I shouldn't put mutex/spin/lock/unlock under splitty/splx?
Can you please explain a bit more about MPSAFE using for me too?

Regards, Mokhi.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

thread-unsafety problems as spl*() ones are NOP

[mokhi]

Hi.
in kbd.c there are many places spltty()/splx() used assuming it locks/unlocks.
though there is bug filed for this, and ive asked in #bsddev, Ive
preferred to ask and ensure it from here again.
As these functions are obsoleted now, this assumption is incorrect and
some places we have thread-unsafely which leads to security problems
(and/or for example double-free, etc)

can i use mutex/spin/lock/unlock under where assumed a lock/unlock by
using spltty()/splx() to patch it?

Thanks, Mokhi.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: thread-unsafety problems as spl*() ones are NOP

[mokhi]

i currently only wanna do patch on kbd.c (because i'm sure there is a
thread-unsafety)
and i don't want to add anything to spltty() nor splx(), i just wanna
add things under where they've been used.
isn't problem with using mutex/spin/lock/unlock etc there?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: thread-unsafety problems as spl*() ones are NOP

[mokhi]

@imp So you think I should start to put locks there and see what happens? :)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: thread-unsafety problems as spl*() ones are NOP

[mokhi]

@imp:
i exactly mean (Okay not so exact but very near ;D) what you said.
after analyzing kbd.c functions (eg, kbd_realloc_array()) i concluded
there are race conditions (and at  result in some places there are
un-protected data too)

i don't mean to blindly replace splXXX() with locks, but the places i
see race-conds.
Also i should say there are manythings i dunno well or i dont have
deep understanding of them and that's why im here to ask (ie what
special condition Giant-Lock makes here [i should care about] and what
is MPSAFE basically)
i'd happy if you answer me those question too :D

Regards, Mokhi.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"