Re: Under FREEBSD network control.
I would like to build a bridge using FREEBSD system.At the same time, they can do the network traffic control.How to do it? read manuals thank you! ___ 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-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: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
I think this is unintentionally specious reasoning. No offense intended. :) true The program itself is fairly trivial to write. i don't need such a tool, but if it would be separate tool, then it is all right if someone like to write it. This would be unix way. So it's really not possible to write the tool and associated documentation "myself". Otherwise I would. The "pointless debating" is really an attempt to get a critical mass of knowledgeable developers to agree to participate in not really. the idea was to integrate it with shell and turn on it by default, prefering newbies over norml users, and making another change that would actually prevent getting knowledge to newbie. I've been using FreeBSD since the 90s. My perception (over many years of observation) is that the FreeBSD people most able to document what exists and how to use it seem to also have the greatest resistance to writing any documentation. what do you mean? FreeBSD manual pages is what i consider great part. i mean manual pages. handbook is not always up to date but still fine for a NEW USER to learn FreeBSD. And that's the right way. "creators", "helpers" like proposed reminds me windows. A "Help" that doesn't really help learning anything. There are already lots of stupid things that is ALREADY done in FreeBSD without reason. Few examples: 1) XML output from some sysctl variables. It isn't just stupid. It's sad. 2) bsdlabel -e allows editing only when NONE of partitions are open/mounted, in spite that they are not modified. In FreeBSD 6 it allowed editing everytime and all worked. "Preventing people doing stupid things would prevent doing clever things". OK there is gpart now but still bsdlabel is far easier and useful. 3) replacing C compiler with immature one just because licencing is "better". Still - GCC licencing is fine for use in FreeBSD. 4) Adding features that are not really finished and in working state. gjournal is an example, background fsck is another (everyone actually ends in background_fsck=NO) and more that i don't probably get contact with. Of course in the same time where are hundreds of good things done, and we all know it. But if people won't understand a problem NOW and fight it, it will become worse. ___ 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: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
greatest resistance to writing any documentation. I'll just note that over the past ~6 months, the documentation team has seen a lot of new contributors and new energy. So from my view, the situation is improving. And is already great. The topic wasn't about documentation. ___ 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: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
On 18 Jul 2012 09:39, "Wojciech Puchar" wrote: >> >> >> I think this is unintentionally specious reasoning. No offense intended. :) >> > true > > >> The program itself is fairly trivial to write. > > > i don't need such a tool, but if it would be separate tool, then it is all right if someone like to write it. This would be unix way. > > >> So it's really not possible to write the tool and associated documentation "myself". Otherwise I would. The "pointless debating" is really an attempt to get a critical mass of knowledgeable developers to agree to participate in > > > not really. the idea was to integrate it with shell and turn on it by default, prefering newbies over norml users, and making another change that would actually prevent getting knowledge to newbie. > > >> I've been using FreeBSD since the 90s. My perception (over many years of observation) is that the FreeBSD people most able to document what exists and how to use it seem to also have the greatest resistance to writing any documentation. > > > what do you mean? FreeBSD manual pages is what i consider great part. > > i mean manual pages. handbook is not always up to date but still fine for a NEW USER to learn FreeBSD. > > And that's the right way. > > "creators", "helpers" like proposed reminds me windows. A "Help" that doesn't really help learning anything. > > > There are already lots of stupid things that is ALREADY done in FreeBSD without reason. > > Few examples: > > 1) XML output from some sysctl variables. It isn't just stupid. It's sad. > 2) bsdlabel -e allows editing only when NONE of partitions are open/mounted, in spite that they are not modified. In FreeBSD 6 it allowed editing everytime and all worked. > > "Preventing people doing stupid things would prevent doing clever things". > > OK there is gpart now but still bsdlabel is far easier and useful. Bsdlabel was a monstrosity that required a calculator to hand to do anything useful. Gpart on the other hand is easily scriptable. Chris ___ 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: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
On 07/18/12 01:36, Wojciech Puchar wrote: not really. the idea was to integrate it with shell and turn on it by default, prefering newbies over norml users, and making another change that would actually prevent getting knowledge to newbie. I don't agree with modifying the shell either, and I really doubt that is going to happen here. I've been using FreeBSD since the 90s. My perception (over many years of observation) is that the FreeBSD people most able to document what exists and how to use it seem to also have the greatest resistance to writing any documentation. what do you mean? FreeBSD manual pages is what i consider great part. i mean manual pages. handbook is not always up to date but still fine for a NEW USER to learn FreeBSD. And that's the right way. While I have learned much from man pages, as I remember hearing it explained to me...man pages are -reference- material. They are not intended to be the 'right way' to learn something, but instead as a quick reference guide. Of course, I doubt anyone can make a case for the 'one true right way' to learn FreeBSD. I would never teach someone to read the man pages as a way to familiarize themselves with...say...geom(8). (In fact, I'd love to find some better introductory/overview documentation for geom, but I digress.) The notion of a 'new user' is unfortunately too wide of a category to target documentation to. A secretary who's never seen anything but windows, a 5 year old child, and a fresh PhD in computer science might all fit this category. Each of these people requires different levels of teaching. Everytime I see these discussions my mind flashes to a web based wiki where everyone writes helpful information (like the Emacs Wiki) on various topics and it's fairly well indexed so you can see related ideas. Does something like this exist for FreeBSD? 4) Adding features that are not really finished and in working state. gjournal is an example, background fsck is another (everyone actually ends in background_fsck=NO) Well you have me there, I thought background fsck worked...I just left it on because it's set like that in /etc/defaults/rc.conf. Of course in the same time where are hundreds of good things done, and we all know it. But if people won't understand a problem NOW and fight it, it will become worse. If everyone is busy fighting evil, who is left to create the good? :) -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org *The opinions expressed above are entirely my own* A free society is one where it is safe to be unpopular. -- Adlai Stevenson ___ 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: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.3
Xin,
Thanks for the reply!
Unfortunately I tried to put the code from the patch in place but there
seems to be some missing functions in the header file and too many
arguments to a function and some other errors below:
../../../amd64/amd64/trap.c: In function `syscall':
../../../amd64/amd64/trap.c:884: warning: implicit declaration of function
`ksiginfo_init_trap'
../../../amd64/amd64/trap.c:884: warning: nested extern declaration of
`ksiginfo_init_trap'
../../../amd64/amd64/trap.c:884: error: `ksi' undeclared (first use in this
function)
../../../amd64/amd64/trap.c:884: error: (Each undeclared identifier is
reported only once
../../../amd64/amd64/trap.c:884: error: for each function it appears in.)
../../../amd64/amd64/trap.c:886: error: `BUS_OBJERR' undeclared (first use
in this function)
../../../amd64/amd64/trap.c:889: error: too few arguments to function
`trapsignal'
*** Error code 1
I can possibly take a stab at writing something to handle this...but I
don't write in C very often and I am sure others are much more experienced
in the FreeBSD kernel than I am.
If anyone can help further please let me know.
Thanks!
On Thu, Jul 12, 2012 at 6:11 PM, Xin Li wrote:
> On 07/12/12 09:36, Bill Crisp wrote:
>
>> Good Morning!
>>
>> This was also posted to the FreeBSD forums:
>>
>> I have been researching CVE-2012-0217 and while I have patched the kernels
>> on servers with 7.3/8.2 that I have, I would like to see if anyone knows
>> for sure if 6.2/6.3 are also vulnerable? I am aware that those kernels are
>> out of support from looking at the documentation. I have looked at the
>> code
>> in trap.c to see if the current patch would work with 6.3 source but it
>> won't based on what I saw. I am also aware of upgrading as an option to
>> resolve this unfortunately in some cases I have this is not possible right
>> now.
>>
> I believe that 6.x are vulnerable. You will have to backport the change
> (something like this against sys/amd64/amd64/trap.c, in syscall() right
> after
>
> PTRACESTOP_SC(p, td, S_PT_SCX);
>
> Add:
>
> + /*
> +* If the user-supplied value of %rip is not a canonical
> +* address, then some CPUs will trigger a ring 0 #GP during
> +* the sysret instruction. However, the fault handler would
> +* execute with the user's %gs and %rsp in ring 0 which would
> +* not be safe. Instead, preemptively kill the thread with a
> +* SIGBUS.
> +*/
> + if (td->td_frame->tf_rip>= VM_MAXUSER_ADDRESS) {
> + ksiginfo_init_trap(&ksi);
> + ksi.ksi_signo = SIGBUS;
> + ksi.ksi_code = BUS_OBJERR;
> + ksi.ksi_trapno = T_PROTFLT;
> + ksi.ksi_addr = (void *)td->td_frame->tf_rip;
> + trapsignal(td,&ksi);
> + }
>
> Right before:
>
> WITNESS_WARN(...)
>
>
> Cheers,
>
>
>
___
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"
ULE scheduler miscalculates CPU utilization for threads that run in short bursts
At $WORK we use a modification of DEVICE_POLLING instead of running
our NICs in interrupt mode. With the ULE scheduler we are seeing that
CPU utilization (e.g. in top -SH) is completely wrong: the polling
threads always end up being reported at a utilization of 0%.
I see problems both with the CPU utilization algorithm introduced in
r232917 as well as the original one. The problem with the original
algorithm is pretty easy to explain: ULE was sampling for CPU usage in
hardclock(), which also kicks off the polling threads, so samples are
never taken when the polling thread was running.
It appears that r232917 attempts to do time-based CPU accounting
instead of sampling based. sched_pctcpu_update() is called at various
places to update the CPU usage of each thread:
static void
sched_pctcpu_update(struct td_sched *ts, int run)
{
int t = ticks;
if (t - ts->ts_ltick >= SCHED_TICK_TARG) {
ts->ts_ticks = 0;
ts->ts_ftick = t - SCHED_TICK_TARG;
} else if (t - ts->ts_ftick >= SCHED_TICK_MAX) {
ts->ts_ticks = (ts->ts_ticks / (ts->ts_ltick - ts->ts_ftick)) *
(ts->ts_ltick - (t - SCHED_TICK_TARG));
ts->ts_ftick = t - SCHED_TICK_TARG;
}
if (run)
ts->ts_ticks += (t - ts->ts_ltick) << SCHED_TICK_SHIFT;
ts->ts_ltick = t;
}
The problem with it is that it only seems to work at the granularity
of 1 tick. My polling threads get woken up at each hardclock()
invocation and stop running before the next hardclock() invocation, so
ticks is (almost) never incremented while the polling thread is
running. This means that when sched_pctcpu_update is called when the
polling thread is going to sleep, run=1 but ts->ts_ltick == ticks, so
ts_ticks is incremented by 0. When the polling thread is woken up
again, ticks has been incremented in the meantime and
sched_pctcpu_update is called with run=0, so ts_ticks is not
incremented but ltick is set to ticks. The effect is that ts_ticks is
never incremented so CPU usage is always reported as 0.
I think that you'll see the same effect with the softclock threads, too.
I've experimented with reverting r232917 and instead moving the
sampling code from sched_tick() to sched_clock(), and that seems to
give me reasonably accurate results (for my workload, anyway). The
other option would be to use a timer with a higher granularity than
ticks in sched_pctcpu_update().
___
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: ULE scheduler miscalculates CPU utilization for threads that run in short bursts
On 18.07.2012 23:29, Ryan Stone wrote:
At $WORK we use a modification of DEVICE_POLLING instead of running
our NICs in interrupt mode. With the ULE scheduler we are seeing that
CPU utilization (e.g. in top -SH) is completely wrong: the polling
threads always end up being reported at a utilization of 0%.
I see problems both with the CPU utilization algorithm introduced in
r232917 as well as the original one. The problem with the original
algorithm is pretty easy to explain: ULE was sampling for CPU usage in
hardclock(), which also kicks off the polling threads, so samples are
never taken when the polling thread was running.
It appears that r232917 attempts to do time-based CPU accounting
instead of sampling based. sched_pctcpu_update() is called at various
places to update the CPU usage of each thread:
static void
sched_pctcpu_update(struct td_sched *ts, int run)
{
int t = ticks;
if (t - ts->ts_ltick >= SCHED_TICK_TARG) {
ts->ts_ticks = 0;
ts->ts_ftick = t - SCHED_TICK_TARG;
} else if (t - ts->ts_ftick >= SCHED_TICK_MAX) {
ts->ts_ticks = (ts->ts_ticks / (ts->ts_ltick - ts->ts_ftick)) *
(ts->ts_ltick - (t - SCHED_TICK_TARG));
ts->ts_ftick = t - SCHED_TICK_TARG;
}
if (run)
ts->ts_ticks += (t - ts->ts_ltick) << SCHED_TICK_SHIFT;
ts->ts_ltick = t;
}
The problem with it is that it only seems to work at the granularity
of 1 tick. My polling threads get woken up at each hardclock()
invocation and stop running before the next hardclock() invocation, so
ticks is (almost) never incremented while the polling thread is
running. This means that when sched_pctcpu_update is called when the
polling thread is going to sleep, run=1 but ts->ts_ltick == ticks, so
ts_ticks is incremented by 0. When the polling thread is woken up
again, ticks has been incremented in the meantime and
sched_pctcpu_update is called with run=0, so ts_ticks is not
incremented but ltick is set to ticks. The effect is that ts_ticks is
never incremented so CPU usage is always reported as 0.
I think that you'll see the same effect with the softclock threads, too.
That is obvious that it is impossible to measure pctcpu for hardclock -
synchronized threads using hardclock as the only time source. Mentioned
change made things neither more nor less broken then they already were.
I've experimented with reverting r232917 and instead moving the
sampling code from sched_tick() to sched_clock(), and that seems to
give me reasonably accurate results (for my workload, anyway).
That approach will fix pctcpu accounting for thread synchronized to
hardclock, but I worry can make worse for threads switching context
around statclock.
The
other option would be to use a timer with a higher granularity than
ticks in sched_pctcpu_update().
That would be great it we had reliable and cheap timers on x86. Now ones
that are fast (TSC) are unreliable, others that are reliable are too
slow for this use.
--
Alexander Motin
___
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: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.3
On Wed, Jul 18, 2012 at 3:26 PM, Bill Crisp wrote: > > Unfortunately I tried to put the code from the patch in place but there > seems to be some missing functions in the header file and too many > arguments to a function and some other errors below: Hi Bill. Yes, the patch for >= FreeBSD 7 won't apply directly to 6. ksi and the refined SIGBUS traps don't exist yet. Here's how I fixed it at work. Using this on multiple releng_6* branches. HTH! -- James. CVE-2012-0217_releng_6.patch Description: Binary data ___ 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"
