The FreeBSD Project in the Google Code-In 2011 contest
Hello, (cross-posted message; please keep eventual comments on freebsd-hackers@) The FreeBSD project has been accepted to the Google Code-In 2011 contest. http://google-opensource.blogspot.com/2011/11/google-code-in-2011-participating.html We have proposed 50 tasks so far, and more are still coming! This is an event similar to the Google Summer of Code, but is targetted to people in the 13-17 age range. Young people will be working on FreeBSD-related tasks for the next weeks. If you know any potential candidates, feel free to forward this message. Brief summary: T-shirts and possibility of earning some $$$ for participants. The best participants get a chance to see the Google complex in Mountain View, Silicon Valley, California, USA. FreeBSD tasks are here: http://wiki.freebsd.org/GoogleCodeIn/2011 Ideas page can be extended till December, 16th! Contest's home page: http://www.google-melange.com/gci/homepage/google/gci2011 After you create an account, you can acquire tasks which you're interested in (if any of them are left!) Start date: November, 21st (tomorrow) Official communication channels: IRC (EFNet):#freebsd-soc Q/A:wkos...@freebsd.org, jc...@freebsd.org, ead...@freebsd.org wkoszek, jceel, eadler on IRC Mailing list: freebsd-hackers@ Please coordinate communication with your mentor. Include '[GCIN]' header when posting to freebsd-hackers@ In case of potential task candidates, ideas and suggestions, feel free to contact me. -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Google Code-In 2011 is over; 56 tasks got completed for FreeBSD!
Hello, (This is cross-posted message between current@, stable@ and hackers@; for eventual discussion, please use hackers@ mailing list.) I am glad to announce that we've successfully reached the end of Google Code-In 2011 Contest! FreeBSD participated first time, and in my personal opinion GCIN has proven to be a big success. I want to thank all the participants for their time, cooperation and dedication. Here's the list of this years participants: Alex Rucker, Andrey Sinitsyn, Anikan, Astha Sethi, Bebacz, Bharath Mohan, doctorkohaku, Eric Newberry, GarrettF, Isabell Long (issyl0), mpaloski, Violet Lin (n00l3), Nagato Yuki, Nathan, passstab, Reid Anderson, Robin, Roger, Rushil Paul, Thomas Turney, Utkarsh Pant, Zacharias Mitzelos I would like to point out Isabell Long (issyl0) completed 13 tasks for us and holds this years record. Some other numbers... We've had 19 mentors. I send special thanks to those who offered their help in mentoring/administration, since accepting/reviewing/judging tasks has proven to be challenging. We've had 78 tasks published. 56 tasks got completed, leading to ~72% successful completions. 1 task was claimed at the time of hitting the deadline, 10 tasks were claimed, but never finished, thus got reopened. 12 of tasks were never claimed. List of tasks, together with their outcome (uploaded results) are present here: http://www.google-melange.com/gci/org/google/gci2011/freebsd It would be my wish to have the work done in GCIN commited to FreeBSD with: Submitted by: Name (Google Code-In 2011) header or similar, clearly stating work comes from GCIN 2011. The hardest expectations for mentors was short response time. For students I think it was meeting FreeBSD's standards, however I'm positively surprised by the quality of submitted work. The complaint which I've heard is: "Not enough coding tasks". We should fix it next time, since most of the tasks were related with documentation and outreach/promotion. I think GCIN should become an integral part of the FreeBSD involvement in promotion of the Open Source software. Thank you. -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
FreeBSD in Google Code-In 2012? You can help too!
(cross-posted message; please keep discussion on freebsd-hackers@) Hello, Last year FreeBSD qualified for Google Code-In 2011 event--contest for youngest open-source hackers in 13-17yr age range: http://www.google-melange.com/gci/homepage/google/gci2012 It was successful. We gained one more FreeBSD developer thanks to that (Isabell Long) We're pondering participating in the contest this year as well. For now we only have 25 ideas. We need at least 100. I felt all members of the FreeBSD community should help, so please submit your own Google Code-In 2012 ideas here: http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 Examples of previously completed tasks: http://wiki.freebsd.org/GoogleCodeIn/2011Tasks Those of you who have Wiki access, please spent 2 more minutes and submit straight to Wiki: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks I plan to send out next e-mail if there's any progress on this project. Help will be appreciated. Thanks, -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD in Google Code-In 2012? You can help too!
On Tue, Oct 16, 2012 at 10:19:57AM +, Wojciech A. Koszek wrote: > (cross-posted message; please keep discussion on freebsd-hackers@) > > Hello, > > Last year FreeBSD qualified for Google Code-In 2011 event--contest for > youngest open-source hackers in 13-17yr age range: > > http://www.google-melange.com/gci/homepage/google/gci2012 > > It was successful. We gained one more FreeBSD developer thanks to that > (Isabell Long) We're pondering participating in the contest this year as > well. > > For now we only have 25 ideas. We need at least 100. > > I felt all members of the FreeBSD community should help, so please submit > your own Google Code-In 2012 ideas here: > > http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 > > Examples of previously completed tasks: > > http://wiki.freebsd.org/GoogleCodeIn/2011Tasks > > Those of you who have Wiki access, please spent 2 more minutes and submit > straight to Wiki: > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > I plan to send out next e-mail if there's any progress on this project. > > Help will be appreciated. Hi, (cross-posted message; please keep discussion on freebsd-hackers@) I made a mistake -- the web form didn't have "Contributor's name", thus I don't know who of you guys contributed first 9 ideas; e-mail me which ideas are yours, so that your name can be mentioned on Wiki: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks I made slight adjustments to the form to make some fields more precise: http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 Sorry and thanks, -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD in Google Code-In 2012? You can help too!
On Tue, Oct 16, 2012 at 10:19:57AM +, Wojciech A. Koszek wrote: > (cross-posted message; please keep discussion on freebsd-hackers@) > > Hello, > > Last year FreeBSD qualified for Google Code-In 2011 event--contest for > youngest open-source hackers in 13-17yr age range: > > http://www.google-melange.com/gci/homepage/google/gci2012 > > It was successful. We gained one more FreeBSD developer thanks to that > (Isabell Long) We're pondering participating in the contest this year as > well. > > For now we only have 25 ideas. We need at least 100. > > I felt all members of the FreeBSD community should help, so please submit > your own Google Code-In 2012 ideas here: > > http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 > > Examples of previously completed tasks: > > http://wiki.freebsd.org/GoogleCodeIn/2011Tasks > > Those of you who have Wiki access, please spent 2 more minutes and submit > straight to Wiki: > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > I plan to send out next e-mail if there's any progress on this project. > > Help will be appreciated. > Update: It looks pretty bad so far. Page: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks Has 38 tasks so far out of which: ~30 would qualify. Consider this e-mail to be the last call for action. Otherwise we'll have to pull back and concentrate our efforts on GSOC instead. -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD in Google Code-In 2012? You can help too!
On Mon, Oct 22, 2012 at 03:08:27PM -0500, dweimer wrote: > On 2012-10-22 12:44, Wojciech A. Koszek wrote: > > On Tue, Oct 16, 2012 at 10:19:57AM +, Wojciech A. Koszek wrote: > >> (cross-posted message; please keep discussion on freebsd-hackers@) > >> > >> Hello, > >> > >> Last year FreeBSD qualified for Google Code-In 2011 event--contest > >> for > >> youngest open-source hackers in 13-17yr age range: > >> > >>http://www.google-melange.com/gci/homepage/google/gci2012 > >> > >> It was successful. We gained one more FreeBSD developer thanks to > >> that > >> (Isabell Long) We're pondering participating in the contest this > >> year as > >> well. > >> > >> For now we only have 25 ideas. We need at least 100. > >> > >> I felt all members of the FreeBSD community should help, so please > >> submit > >> your own Google Code-In 2012 ideas here: > >> > >>http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 > >> > >> Examples of previously completed tasks: > >> > >>http://wiki.freebsd.org/GoogleCodeIn/2011Tasks > >> > >> Those of you who have Wiki access, please spent 2 more minutes and > >> submit > >> straight to Wiki: > >> > >>http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > >> > >> I plan to send out next e-mail if there's any progress on this > >> project. > >> > >> Help will be appreciated. > >> > > > > Update: > > > > It looks pretty bad so far. Page: > > > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > > > Has 38 tasks so far out of which: > > > > ~30 would qualify. > > > > Consider this e-mail to be the last call for action. Otherwise we'll > > have to > > pull back and concentrate our efforts on GSOC instead. > > One thing I can think to add if it's not already been done and if its a > practical idea for the Google project, would be to update the mount_udf > command to support newer versions of UDF. It looks like as of FreeBSD 7 > that 1.02 & 1.50 are supported, I( haven't been able to find any more > recent documentation to support whether or not updates have been made > since then. > > I only know that server I have running 9.0, for the purpose of hosting > ISO images on the network so they are available to our ESX environment > for mounting as a local CDROM/DVD within virtual machines, and also > available as files over a network share, can't mount the some of the > more recent DVDs in the UDF format, but I am unsure which format they > are in, they could be 2.0, 2.5, or 2.6. I think it's too hard for Google Code-In (participants are 13--17), but submit this idea via web form. We can always end up doing copy&paste to GSOC section, which I think would be more appropriate. -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD in Google Code-In 2012? You can help too!
On Mon, Oct 22, 2012 at 11:46:21AM -0700, Adrian Chadd wrote: > That wiki site has a distinct lack of help about: > > * what is required from us; > * what the target is (kids, right?) > * some examples of good and bad projects. > > Right now I have absolutely no idea what would constitute a good or > bad coding project. :/ > I updated the Wiki with "Sample ideas" section: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD in Google Code-In 2012? You can help too!
Dnia 23-10-2012 o 14:05:43 Adrian Chadd napisał(a): Right, lots of PHP coding. Attractive to a student. Nobody prevents students from serving FreeBSD by writing stuff in attractive, well documented (books, translations) technologies. We just need to craft a task list around things which people consider attractive. -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD in Google Code-In 2012? You can help too!
On Tue, Oct 16, 2012 at 10:19:57AM +, Wojciech A. Koszek wrote: > (cross-posted message; please keep discussion on freebsd-hackers@) > > Hello, > > Last year FreeBSD qualified for Google Code-In 2011 event--contest for > youngest open-source hackers in 13-17yr age range: > > http://www.google-melange.com/gci/homepage/google/gci2012 > > It was successful. We gained one more FreeBSD developer thanks to that > (Isabell Long) We're pondering participating in the contest this year as > well. > > For now we only have 25 ideas. We need at least 100. > > I felt all members of the FreeBSD community should help, so please submit > your own Google Code-In 2012 ideas here: > > http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 > > Examples of previously completed tasks: > > http://wiki.freebsd.org/GoogleCodeIn/2011Tasks > > Those of you who have Wiki access, please spent 2 more minutes and submit > straight to Wiki: > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > I plan to send out next e-mail if there's any progress on this project. > > Help will be appreciated. Hello, This is last call for action. As for now, we won't qualify. I suggest doc@ and ports@ and www@ and src@ teams to try to come up with some ideas and add them to Wiki. Most of the ideas which we have so far are more GSOC-alike. Unless we have at least 80 tasks of the "easy"/"medium" type, we'll have to postpone participating in Code-In for next year. Thanks, -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[Not this year] Re: FreeBSD in Google Code-In 2012? You can help too!
On Fri, Nov 02, 2012 at 08:13:18PM +, Wojciech A. Koszek wrote: > On Tue, Oct 16, 2012 at 10:19:57AM +0000, Wojciech A. Koszek wrote: > > (cross-posted message; please keep discussion on freebsd-hackers@) > > > > Hello, > > > > Last year FreeBSD qualified for Google Code-In 2011 event--contest for > > youngest open-source hackers in 13-17yr age range: > > > > http://www.google-melange.com/gci/homepage/google/gci2012 > > > > It was successful. We gained one more FreeBSD developer thanks to that > > (Isabell Long) We're pondering participating in the contest this year as > > well. > > > > For now we only have 25 ideas. We need at least 100. > > > > I felt all members of the FreeBSD community should help, so please submit > > your own Google Code-In 2012 ideas here: > > > > http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 > > > > Examples of previously completed tasks: > > > > http://wiki.freebsd.org/GoogleCodeIn/2011Tasks > > > > Those of you who have Wiki access, please spent 2 more minutes and submit > > straight to Wiki: > > > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > > > I plan to send out next e-mail if there's any progress on this project. > > > > Help will be appreciated. > > Hello, > > This is last call for action. > > As for now, we won't qualify. I suggest doc@ and ports@ and www@ and src@ > teams to try to come up with some ideas and add them to Wiki. Most of the > ideas which we have so far are more GSOC-alike. > > Unless we have at least 80 tasks of the "easy"/"medium" type, we'll have to > postpone participating in Code-In for next year. > > Thanks, Hello, We didn't make it this year. I want to thank all the people who submitted (and keep submitting) ideas for our Google Code-In wiki page: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks In total I got 61 ideas over e-mail from the web form (lessons learnt: for GSOC, we should also have a web form) All of them should be on the Wiki now. I suggest we keep collecting good ideas and try to make sure this years GSOC will be successful. On the other note--NetBSD guys are in Google Code-In.. Thanks, -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: config(8) -x headscratcher
On Sat, Apr 27, 2013 at 06:54:11PM +0300, Kimmo Paasiala wrote:
> I'm getting a core dump on 'config -x /boot/kernel/kernel' on 9.1-RELEASE
> i386.
>
> Assertion failed: (r != '\0' && ("Char present in the configuration "
> "string mustn't be equal to 0")), function kernconfdump, file
> /usr/src/usr.sbin/config/main.c, line 710.
>
> I have double checked that my config file is sane and does not have
> any funny characters anywhere.
>
> The system is i386 9.1-RELEASE r249856. The world and kernel are built
> with clang and I'm suspecting that the use of clang has something to
> do with this segfault.
>
> Looking at the kernel files I can see one very obvious difference.
> This is the 'elfdump -c kernel | grep -A 8 kern_conf' output (what
> config -x seems to use for finding out the config file from the kernel
> image) for the GENERIC kernel from the stock installation:
>
> sh_name: kern_conf
> sh_type: SHT_PROGBITS
> sh_flags: SHF_ALLOC
> sh_addr: 0xc1039f80
> sh_offset: 12820352
> sh_size: 3771
> sh_link: 0
> sh_info: 0
> sh_addralign: 32
>
> And this is from the kernel I have built myself using clang and a
> custom config file:
>
> sh_name: kern_conf
> sh_type: SHT_PROGBITS
> sh_flags: SHF_ALLOC
> sh_addr: 0xc09aee9c
> sh_offset: 5959324
> sh_size: 1994
> sh_link: 0
> sh_info: 0
> sh_addralign: 1
>
> The align field looks suspicious, config -x seems to use it to check
> for padding but to me it looks like the logic may not work if the
> alignment is 1.
>
> This the relevant bit from main.c of config(8)
>
Kimmo,
Lets keep discussion on hackers@ only. I do agree with you that config(8)
internal implementation might have its issues.
Can you make your kernel configuration file, faulty kernel image and exact
build instructions available to me?
--
Wojciech A. Koszek
wkos...@freebsd.czest.pl
http://FreeBSD.czest.pl/~wkoszek/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: config(8) -x headscratcher
On Sun, Apr 28, 2013 at 04:40:58AM +0300, Kimmo Paasiala wrote: > On Sat, Apr 27, 2013 at 11:53 PM, Kimmo Paasiala wrote: > > On Sat, Apr 27, 2013 at 11:42 PM, Kimmo Paasiala wrote: > >> On Sat, Apr 27, 2013 at 10:05 PM, Wojciech A. Koszek > >> wrote: > >>> On Sat, Apr 27, 2013 at 06:54:11PM +0300, Kimmo Paasiala wrote: > >>>> I'm getting a core dump on 'config -x /boot/kernel/kernel' on > >>>> 9.1-RELEASE i386. > >>>> [..] > >> > >> The kernel config file: > >> > >> http://pastebin.com/j0J9NPCi > >> > >> My /etc/make.conf: > >> > >> http://pastebin.com/HYudWCA9 > >> > >> And /etc/src.conf: > >> > >> http://pastebin.com/ZAKq6ABT > >> > >> I'll see how I can make the kernel image available. > >> > >> -Kimmo > > > > The kernel file: > > > > https://www.dropbox.com/s/07mjk6j4ditbl9r/kernel > > > > -Kimmo > > dmesg(8) output of the system: > > http://pastebin.com/hqjsak2n Kimmo, Thanks for the information. Can you try following patch: cd /usr/src/usr.sbin/config fetch http://people.freebsd.org/~wkoszek/patches/config-align.patch patch -p0 < config-align.patch make and see if it fixes your problem for all kernel images you're building? -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: config(8) -x headscratcher
On Mon, Apr 29, 2013 at 12:21:06AM +0300, Kimmo Paasiala wrote: > On Sun, Apr 28, 2013 at 8:09 PM, Wojciech A. Koszek > wrote: > > On Sun, Apr 28, 2013 at 04:40:58AM +0300, Kimmo Paasiala wrote: > >> On Sat, Apr 27, 2013 at 11:53 PM, Kimmo Paasiala > >> wrote: > >> > On Sat, Apr 27, 2013 at 11:42 PM, Kimmo Paasiala > >> > wrote: > >> >> On Sat, Apr 27, 2013 at 10:05 PM, Wojciech A. Koszek > >> >> wrote: > >> >>> On Sat, Apr 27, 2013 at 06:54:11PM +0300, Kimmo Paasiala wrote: > >> >>>> I'm getting a core dump on 'config -x /boot/kernel/kernel' on > >> >>>> 9.1-RELEASE i386. > >> >>>> > > > > > > [..] > > > >> >> > >> >> The kernel config file: > >> >> > >> >> http://pastebin.com/j0J9NPCi > >> >> > >> >> My /etc/make.conf: > >> >> > >> >> http://pastebin.com/HYudWCA9 > >> >> > >> >> And /etc/src.conf: > >> >> > >> >> http://pastebin.com/ZAKq6ABT > >> >> > >> >> I'll see how I can make the kernel image available. > >> >> > >> >> -Kimmo > >> > > >> > The kernel file: > >> > > >> > https://www.dropbox.com/s/07mjk6j4ditbl9r/kernel > >> > > >> > -Kimmo > >> > >> dmesg(8) output of the system: > >> > >> http://pastebin.com/hqjsak2n > > > > Kimmo, > > > > Thanks for the information. Can you try following patch: > > > > cd /usr/src/usr.sbin/config > > fetch http://people.freebsd.org/~wkoszek/patches/config-align.patch > > patch -p0 < config-align.patch > > make > > > > and see if it fixes your problem for all kernel images you're building? > > > > -- > > Thanks. That patch does fix the problem with config -x. However, is > the alignment of 1 an error that needs to be addressed as well? Kimmo, Thanks for this report. I fixed it in HEAD as of revision 250133. I'll MFC it after 10 days. I can't comment about alignment differences--I don't know. -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: config(8) -x headscratcher
On Tue, May 07, 2013 at 07:16:39AM -0500, Eric van Gyzen wrote: > > On 04/28/2013 12:09, Wojciech A. Koszek wrote: > > On Sun, Apr 28, 2013 at 04:40:58AM +0300, Kimmo Paasiala wrote: > >> On Sat, Apr 27, 2013 at 11:53 PM, Kimmo Paasiala > >> wrote: > >>> On Sat, Apr 27, 2013 at 11:42 PM, Kimmo Paasiala > >>> wrote: > >>>> On Sat, Apr 27, 2013 at 10:05 PM, Wojciech A. Koszek > >>>> wrote: > >>>>> On Sat, Apr 27, 2013 at 06:54:11PM +0300, Kimmo Paasiala wrote: > >>>>>> I'm getting a core dump on 'config -x /boot/kernel/kernel' on > >>>>>> 9.1-RELEASE i386. > >>>>>> > > > > [..] > > > >>>> The kernel config file: > >>>> > >>>> http://pastebin.com/j0J9NPCi > >>>> > >>>> My /etc/make.conf: > >>>> > >>>> http://pastebin.com/HYudWCA9 > >>>> > >>>> And /etc/src.conf: > >>>> > >>>> http://pastebin.com/ZAKq6ABT > >>>> > >>>> I'll see how I can make the kernel image available. > >>>> > >>>> -Kimmo > >>> The kernel file: > >>> > >>> https://www.dropbox.com/s/07mjk6j4ditbl9r/kernel > >>> > >>> -Kimmo > >> dmesg(8) output of the system: > >> > >> http://pastebin.com/hqjsak2n > > Kimmo, > > > > Thanks for the information. Can you try following patch: > > > > cd /usr/src/usr.sbin/config > > fetch http://people.freebsd.org/~wkoszek/patches/config-align.patch > > patch -p0 < config-align.patch > > make > > > > and see if it fixes your problem for all kernel images you're building? > > If I'm reading correctly, the patch puts a NUL byte at the beginning of > the assertion message. Eric, I've noticed my initial bug too before checkin. Checked-in version uses \\0 instead. -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[PATCH] Dangerous jail()<->ioctl interactions.
Hello hackers, I would like to let you know I've been doing [partial] audit of ioctl() code. There are some places, which may interest you. These are: sys/cam/cam_xpt.c sys/contrib/ipfilter/netinet/ip_fil.c sys/contrib/pf/net/pf_ioctl.c sys/dev/ata/ata-all.c sys/dev/md/md.c sys/geom/geom_ctl.c Those files contain ioctl()s, which let us to interact between jailed processes and each of these subsystems. Although files like /dev/mdctl should not appear in /dev with normal DEVFS rulesets, I think it would be better if FreeBSD had those ioctl() disabled within jail()ed environment. There is probably one reason for keeping ipf/pf, since someone may want fetch information about NATed connections. How to repeat? Reproducing is very simple. Test environment: # jail / hostname 127.0.0.1 /bin/csh After this step you can monipulate ATA devices: # atacontrol detach Create/remove md(4) devices: # mdconfig -a -t malloc -s 100M # mdconfig -d -u md0 Manipulate cam(4) devices: # camcontrol reset cd0 # camcontrol eject cd0 Manipulate gbde devices: # mdconfig -a -t malloc -s 10M # gbde Manipulate ipnat/ipf/pf rules: # ipnat -f /etc/ipnat.conf # ipnat -CF a # pfctl -f /etc/pf.some.rules # ipf -f /etc/ipf.some.rules Patches with simple suser() tests added are available at: (sys/cam/cam_xpt.c): http://FreeBSD.czest.pl/dunstan/FreeBSD/diff.1.jail (sys/contrib/ipfilter/netinet/ip_fil.c): http://FreeBSD.czest.pl/dunstan/FreeBSD/diff.2.jail (/usr/src/sys/contrib/pf/net/pf_ioctl.c): http://FreeBSD.czest.pl/dunstan/FreeBSD/diff.3.jail (/usr/src/sys/dev/ata/ata-all.c): http://FreeBSD.czest.pl/dunstan/FreeBSD/diff.4.jail (If someone would like to commit it, I can also write style patch). (/usr/src/sys/dev/md/md.c): http://FreeBSD.czest.pl/dunstan/FreeBSD/diff.5.jail (/usr/src/sys/geom/geom_ctl.c): http://FreeBSD.czest.pl/dunstan/FreeBSD/diff.6.jail And comments are welcome. If you find some of these patches useful, please let me know. Regards, -- * Wojciech A. Koszek && [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Dangerous jail()<->ioctl interactions.
On Thu, Feb 24, 2005 at 01:03:17AM +0800, Xin LI wrote: > On Mon, Feb 21, 2005 at 10:16:56PM +0000, Wojciech A. Koszek wrote: > > Hello hackers, > > I would like to let you know I've been doing [partial] audit of ioctl() [..] > > connections. > Default devfs configuration for a jail is not to mount it. Additionally, the > default devfs ruleset hides everything but a limited set of pseudo devices > that > should be commen for applications to consume. Therefore, I'd rather say that > it's a configuration mistake of the user (^_^) > > Do you imply that there are other devices that enforce check against whether > they > are ioctl'ed in jail? I agree these files should not appear inside jailed environment. I've just pointed devices, which are not secured by underlying code (I mean just like ioctl()ing interface files, which are secured with general ioctl() handler making suser() test). Cheers, -- * Wojciech A. Koszek && [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RFC: [conf/78257, PATCH] /etc/rc.d/memdisk for /dev/md* creation at startup
Hello hackers, Could you take a look at my PR which contains rc.d/ script for attaching memory disks managed with mdconfig(8) on system startup: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/78257 Comments are welcome. Best regards, -- * Wojciech A. Koszek && [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[CALL FOR TESTERS] New system call: abort2()
(discussed task was picked from Poul-Henning Kamp's TODO list) Hackers, I've implemented abort2() system call. Works just like abort(3), but delivers signal reliably. Here is a prototype: abort2(const char *why, int nargs, void **args); "why" is reason of program abort, "nargs" is number of arguments passed in "args". Both "why" and "args" (with "%p" format) will be printed via log(9). Sample output: [..] pid <3004> abort2: ABORT2 pid <3019> abort2: invalid argument [..] I put two versions: one implemented as KLD so that more people can test it without a problem: http://freebsd.czest.pl/dunstan/FreeBSD/abort2/abort2-0.3.tgz ..and also as a patch: http://freebsd.czest.pl/dunstan/FreeBSD/abort2/diff.1.abort2-sycall If I miss some tests, please let me know, especially in user<->kernelspace interaction area. (currently I run patched kernel and couldn't get a panic in testing process). Short description - function: abort2(const char *why, int nargs, void **args); ..never returns. If improper arguments are used, instead of SIGABRT, SIGKILL is delivered. By improper arguments I understand: invalid pointers -- "why" or "args" or 0 > "nargs" > 16. Comments are welcome! -- * Wojciech A. Koszek && [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [CALL FOR TESTERS] New system call: abort2()
On Fri, Dec 16, 2005 at 12:17:14AM +0100, Václav Haisman wrote:
> Wojciech A. Koszek wrote:
> [...]
> > Comments are welcome!
>
> As for the patch, the use of do {} while(0) instead of goto looks odd to me.
This can be changed easily in final version of the patch if needed.
> I would like to comment on FreeBSD style(9) a bit. Why does not mention
> or even encourage C99 style // comments? They are nice when one wants to
> comment out bigger chunks of code with /**/ comment.
>
> On the similar note, the ability to move declarations closer to the
> point of use in code is IMO nice feature, too. The style(9) doesn't
> mention this either.
This creates unnecessary problems: large blocks can duplicate name of
the variable so that they overlap, which has happened in the past.
Additionally, some files use this kind of declaration, and it makes
source hard to read.
Also please note that current comments probably needs changing. I'm
looking forward to hearing new comments in that field.
Thanks,
--
* Wojciech A. Koszek && [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [CALL FOR TESTERS] New system call: abort2()
On Fri, Dec 16, 2005 at 08:10:57PM +1100, Peter Jeremy wrote:
> On Thu, 2005-Dec-15 22:37:45 +0000, Wojciech A. Koszek wrote:
> > abort2(const char *why, int nargs, void **args);
> >
> >"why" is reason of program abort, "nargs" is number of arguments
> >passed in "args". Both "why" and "args" (with "%p" format) will be
> >printed via log(9). Sample output:
> >[..]
> >pid <3004> abort2: ABORT2
> >pid <3019> abort2: invalid argument
> >[..]
>
> I don't believe the following code is correct. uap->args is a
> userspace pointer so uap->args[i] is dereferencing a userspace
> argument in kernelspace.
> + arg = uargs[i] = (void *) fuword(uap->args[i]);
> I think it should be fuword(uap->args + i);
>
> I don't see the point of the following test. "arg" is printed using
> %p and never de-referenced so there's no reason it can't be NULL. I
> would see that a legitimate use of abort2() is when the application
> detects that a pointer is unexpectedly NULL. Aborting on -1 is less
> clear - if fuword() fails, it will return -1 but, equally, a faulty
> user application may have left -1 in a pointer. (Note that mmap(2)
> returns -1 on error so it's not inconceivable that a pointer could
> contain -1).
>
> + /* Prevent from faults in user-space */
> + if (arg == NULL || arg == (void *)-1) {
> + error = EINVAL;
> + break;
> + }
>
> Taking the above into account, I believe the code should be:
> + if (uap->args == NULL)
> + break;
> + error = copyin(uap->args, uargs, uap->nargs * sizeof (void
> *));
> + if (error != 0)
> + break;
Of course! Thanks for this comment! Updated version should be available
soon.
--
* Wojciech A. Koszek && [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [CALL FOR TESTERS] New system call: abort2()
On Fri, Dec 16, 2005 at 11:14:12AM -0500, John Baldwin wrote:
> On Friday 16 December 2005 04:10 am, Peter Jeremy wrote:
> > On Thu, 2005-Dec-15 22:37:45 +, Wojciech A. Koszek wrote:
> > > abort2(const char *why, int nargs, void **args);
> > >
> > >"why" is reason of program abort, "nargs" is number of arguments
> > >passed in "args". Both "why" and "args" (with "%p" format) will be
> > >printed via log(9). Sample output:
> > >[..]
> > >pid <3004> abort2: ABORT2
> > >pid <3019> abort2: invalid argument
> > >[..]
> >
> > I don't believe the following code is correct. uap->args is a
> > userspace pointer so uap->args[i] is dereferencing a userspace
> > argument in kernelspace.
> > + arg = uargs[i] = (void *) fuword(uap->args[i]);
> > I think it should be fuword(uap->args + i);
> >
> > I don't see the point of the following test. "arg" is printed using
> > %p and never de-referenced so there's no reason it can't be NULL. I
> > would see that a legitimate use of abort2() is when the application
> > detects that a pointer is unexpectedly NULL. Aborting on -1 is less
> > clear - if fuword() fails, it will return -1 but, equally, a faulty
> > user application may have left -1 in a pointer. (Note that mmap(2)
> > returns -1 on error so it's not inconceivable that a pointer could
> > contain -1).
> >
> > + /* Prevent from faults in user-space */
> > + if (arg == NULL || arg == (void *)-1) {
> > + error = EINVAL;
> > + break;
> > + }
> >
> > Taking the above into account, I believe the code should be:
> > + if (uap->args == NULL)
> > + break;
> > + error = copyin(uap->args, uargs, uap->nargs * sizeof (void
> > *)); + if (error != 0)
> > + break;
>
> Agreed. Also, copyinstr() can provide a better interface for copying the why
> string in. Also, the PROC LOCK isn't needed for reading the static p_pid and
> p_comm fields of struct proc. Also, I second the other comments of do { }
> while(0) vs goto. Many existing syscalls use 'goto out;' for error handling,
> and I think that is one of the very few cases when goto is useful and not
> harmful.
Thanks for the suggestions and comments!
My question is related with copying string from user-space: the only
difference I can see between those functions (other than operating of
strings/sbufs) is that sbuf_copyin() looses 'done' [1]. Since current
abort2() makes use of sbuf(9), I'll have to have additional buffer just
for string copying and than copy it to sbuf. Would you prefer this
solution or complete migration from sbufs to strl..()?
[1] Couldn't sbuf_copyin() simply return 'done' from copyinstr()
embedded in it, since it already returns -1 on failure? This function
is used in two places, which make no use of return value.
--
* Wojciech A. Koszek && [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [CALL FOR TESTERS] New system call: abort2()
On Mon, Dec 19, 2005 at 02:24:04PM -0500, John Baldwin wrote:
> On Friday 16 December 2005 05:19 pm, Wojciech A. Koszek wrote:
> > On Fri, Dec 16, 2005 at 11:14:12AM -0500, John Baldwin wrote:
> > > On Friday 16 December 2005 04:10 am, Peter Jeremy wrote:
> > > > On Thu, 2005-Dec-15 22:37:45 +, Wojciech A. Koszek wrote:
> > > > > abort2(const char *why, int nargs, void **args);
> > > > >
> > > > >"why" is reason of program abort, "nargs" is number of arguments
> > > > >passed in "args". Both "why" and "args" (with "%p" format) will be
> > > > >printed via log(9). Sample output:
> > > > >[..]
> > > > >pid <3004> abort2: ABORT2
> > > > >pid <3019> abort2: invalid argument
> > > > >[..]
> > > >
> > > > I don't believe the following code is correct. uap->args is a
> > > > userspace pointer so uap->args[i] is dereferencing a userspace
> > > > argument in kernelspace.
> > > > + arg = uargs[i] = (void *) fuword(uap->args[i]);
> > > > I think it should be fuword(uap->args + i);
> > > >
> > > > I don't see the point of the following test. "arg" is printed using
> > > > %p and never de-referenced so there's no reason it can't be NULL. I
> > > > would see that a legitimate use of abort2() is when the application
> > > > detects that a pointer is unexpectedly NULL. Aborting on -1 is less
> > > > clear - if fuword() fails, it will return -1 but, equally, a faulty
> > > > user application may have left -1 in a pointer. (Note that mmap(2)
> > > > returns -1 on error so it's not inconceivable that a pointer could
> > > > contain -1).
> > > >
> > > > + /* Prevent from faults in user-space */
> > > > + if (arg == NULL || arg == (void *)-1) {
> > > > + error = EINVAL;
> > > > + break;
> > > > + }
> > > >
> > > > Taking the above into account, I believe the code should be:
> > > > + if (uap->args == NULL)
> > > > + break;
> > > > + error = copyin(uap->args, uargs, uap->nargs * sizeof
> > > > (void *)); + if (error != 0)
> > > > + break;
> > >
> > > Agreed. Also, copyinstr() can provide a better interface for copying the
> > > why string in. Also, the PROC LOCK isn't needed for reading the static
> > > p_pid and p_comm fields of struct proc. Also, I second the other
> > > comments of do { } while(0) vs goto. Many existing syscalls use 'goto
> > > out;' for error handling, and I think that is one of the very few cases
> > > when goto is useful and not harmful.
> >
> > Thanks for the suggestions and comments!
> >
> > My question is related with copying string from user-space: the only
> > difference I can see between those functions (other than operating of
> > strings/sbufs) is that sbuf_copyin() looses 'done' [1]. Since current
> > abort2() makes use of sbuf(9), I'll have to have additional buffer just
> > for string copying and than copy it to sbuf. Would you prefer this
> > solution or complete migration from sbufs to strl..()?
> >
> > [1] Couldn't sbuf_copyin() simply return 'done' from copyinstr()
> > embedded in it, since it already returns -1 on failure? This function
> > is used in two places, which make no use of return value.
>
> That sounds good to me (fixing sbuf_copyin()).
>
I got no response from people for whom changing this function could be a
problem.
My patch is here:
http://freebsd.czest.pl/dunstan/FreeBSD/sbuf_copyin.0.patch
--
* Wojciech A. Koszek && [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [CALL FOR TESTERS] New system call: abort2()
On Fri, Dec 16, 2005 at 11:14:12AM -0500, John Baldwin wrote:
> On Friday 16 December 2005 04:10 am, Peter Jeremy wrote:
> > On Thu, 2005-Dec-15 22:37:45 +, Wojciech A. Koszek wrote:
> > > abort2(const char *why, int nargs, void **args);
> > >
> > >"why" is reason of program abort, "nargs" is number of arguments
> > >passed in "args". Both "why" and "args" (with "%p" format) will be
> > >printed via log(9). Sample output:
> > >[..]
> > >pid <3004> abort2: ABORT2
> > >pid <3019> abort2: invalid argument
> > >[..]
[..]
>
> Agreed. Also, copyinstr() can provide a better interface for copying the why
> string in. Also, the PROC LOCK isn't needed for reading the static p_pid and
> p_comm fields of struct proc. Also, I second the other comments of do { }
> while(0) vs goto. Many existing syscalls use 'goto out;' for error handling,
> and I think that is one of the very few cases when goto is useful and not
> harmful.
Updated patch is here:
http://freebsd.czest.pl/dunstan/FreeBSD/abort2/abort2.3.patch
If I have to change something, let me know. Once again -- comments are
welcome.
--
* Wojciech A. Koszek && [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
