Re: kqueue periodic timer confusion
On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote:
> On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
>> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
>> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
>> >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
>> >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
>> >> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
>> >> > > > Hi,
>> >> > > >
>> >> > > > Sorry about this repost but I'm confused about the responses I
>> >> > > > received
>> >> > > > in my last post so I'm looking for some clarification.
>> >> > > >
>> >> > > > Specifically, I though I could use the kqueue timer as essentially a
>> >> > > > "drop in" replacement for linuxfd_create/read, but was surprised
>> >> > > > that
>> >> > > > the accuracy of the kqueue timer is much less than what I need for
>> >> > > > my
>> >> > > > application.
>> >> > > >
>> >> > > > So my confusion at this point is whether this is consider to be a
>> >> > > > bug or
>> >> > > > "feature"?
>> >> > > >
>> >> > > > Here's some test code if you want to verify the problem:
>> >> > > >
>> >> > > > #include
>> >> > > > #include
>> >> > > > #include
>> >> > > > #include
>> >> > > > #include
>> >> > > > #include
>> >> > > > #include
>> >> > > > #include
>> >> > > >
>> >> > > > int
>> >> > > > main(void)
>> >> > > > {
>> >> > > > int i,msec;
>> >> > > > int kq,nev;
>> >> > > > struct kevent inqueue;
>> >> > > > struct kevent outqueue;
>> >> > > > struct timeval start,end;
>> >> > > >
>> >> > > > if ((kq = kqueue()) == -1) {
>> >> > > > fprintf(stderr, "kqueue error!? errno = %s",
>> >> > strerror(errno));
>> >> > > > exit(EXIT_FAILURE);
>> >> > > > }
>> >> > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0,
>> >> > > > 20, 0);
>> >> > > >
>> >> > > > gettimeofday(&start, 0);
>> >> > > > for (i = 0; i < 50; i++) {
>> >> > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1,
>> >> > > > NULL)) ==
>> >> > -1) {
>> >> > > > fprintf(stderr, "kevent error!? errno = %s",
>> >> > strerror(errno));
>> >> > > > exit(EXIT_FAILURE);
>> >> > > > } else if (outqueue.flags & EV_ERROR) {
>> >> > > > fprintf(stderr, "EV_ERROR: %s\n",
>> >> > strerror(outqueue.data));
>> >> > > > exit(EXIT_FAILURE);
>> >> > > > }
>> >> > > > }
>> >> > > > gettimeofday(&end, 0);
>> >> > > >
>> >> > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((100 +
>> >> > end.tv_usec - start.tv_usec) / 1000) - 1000);
>> >> > > >
>> >> > > > printf("msec = %d\n", msec);
>> >> > > >
>> >> > > > close(kq);
>> >> > > > return EXIT_SUCCESS;
>> >> > > > }
>> >> > > >
>> >> > > >
>> >> > >
>> >> > > What you are seeing is "just the way FreeBSD currently works."
>> >> > >
>> >> > > Sleeping (in most all of its various forms, and I've just looked at
>> >> > > the
>> >> > > kevent code to verify this is true there) is handled by converting the
>> >> > > amount of time to sleep (usually specified in a timeval or timespec
>> >> > > struct) to a count of timer ticks, using an internal routine called
>> >> > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to
>> >> > > account for the current tick. Whether that's a good idea or not (it
>> >> > > probably was once, and probably not anymore) it's how things currently
>> >> > > work, and could explain the fairly consistant +1ms you're seeing.
>> >> >
>> >> > This is all true, but mostly irrelevant for his case. EVFILT_TIMER
>> >> > installs a periodic callout that executes KNOTE() and then resets
>> >> > itself (via
>> >> > callout_reset()) each time it runs. This should generally be closer to
>> >> > regulary spaced intervals than something that does:
>> >> >
>> >>
>> >> In what way is it irrelevant? That is, what did I miss? It appears to
>> >> me that the next callout is scheduled by calling timertoticks() passing
>> >> a count of milliseconds, that count is converted to a struct timeval and
>> >> passed to tvtohz() which is where the +1 adjustment happens. If you ask
>> >> for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms.
>> >> There is some time, likely a small number of microseconds, that you've
>> >> consumed of the current tick, and that's what the +1 in tvtohz() is
>> >> supposed to account for according to the comments.
>> >>
>> >> The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick
>> >> and then adds one tick on top of that. That seems not quite right to
>> >> me, except that it is a way to g'tee that you don't return early, and
>> >> that is the one promise made by sleep routines on any OS; those magical
>> >> "at least" words always appear in the docs.
>> >>
>> >>
Re: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.3
On Thursday, July 12, 2012 12:36:07 pm 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. > > Any help would be greatly appreciated, and I can of course test anything > that might need it. Every FreeBSD/amd64 kernel in existent is vulnerable. In truth, my personal opinion is that Intel screwed up their implementation of that instruction whereas AMD got it right, and we are merely working around Intel's CPU bug. :( -- John Baldwin ___ 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: kqueue periodic timer confusion
On Friday, July 13, 2012 8:22:13 am Davide Italiano wrote:
> On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote:
> > On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
> >> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
> >> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
> >> >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
> >> >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
> >> >> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
> >> >> > > > Hi,
> >> >> > > >
> >> >> > > > Sorry about this repost but I'm confused about the responses I
received
> >> >> > > > in my last post so I'm looking for some clarification.
> >> >> > > >
> >> >> > > > Specifically, I though I could use the kqueue timer as
essentially a
> >> >> > > > "drop in" replacement for linuxfd_create/read, but was surprised
that
> >> >> > > > the accuracy of the kqueue timer is much less than what I need
for my
> >> >> > > > application.
> >> >> > > >
> >> >> > > > So my confusion at this point is whether this is consider to be
a bug or
> >> >> > > > "feature"?
> >> >> > > >
> >> >> > > > Here's some test code if you want to verify the problem:
> >> >> > > >
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > > #include
> >> >> > > >
> >> >> > > > int
> >> >> > > > main(void)
> >> >> > > > {
> >> >> > > > int i,msec;
> >> >> > > > int kq,nev;
> >> >> > > > struct kevent inqueue;
> >> >> > > > struct kevent outqueue;
> >> >> > > > struct timeval start,end;
> >> >> > > >
> >> >> > > > if ((kq = kqueue()) == -1) {
> >> >> > > > fprintf(stderr, "kqueue error!? errno = %s",
> >> >> > strerror(errno));
> >> >> > > > exit(EXIT_FAILURE);
> >> >> > > > }
> >> >> > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0,
20, 0);
> >> >> > > >
> >> >> > > > gettimeofday(&start, 0);
> >> >> > > > for (i = 0; i < 50; i++) {
> >> >> > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1,
NULL)) ==
> >> >> > -1) {
> >> >> > > > fprintf(stderr, "kevent error!? errno =
%s",
> >> >> > strerror(errno));
> >> >> > > > exit(EXIT_FAILURE);
> >> >> > > > } else if (outqueue.flags & EV_ERROR) {
> >> >> > > > fprintf(stderr, "EV_ERROR: %s\n",
> >> >> > strerror(outqueue.data));
> >> >> > > > exit(EXIT_FAILURE);
> >> >> > > > }
> >> >> > > > }
> >> >> > > > gettimeofday(&end, 0);
> >> >> > > >
> >> >> > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((100
+
> >> >> > end.tv_usec - start.tv_usec) / 1000) - 1000);
> >> >> > > >
> >> >> > > > printf("msec = %d\n", msec);
> >> >> > > >
> >> >> > > > close(kq);
> >> >> > > > return EXIT_SUCCESS;
> >> >> > > > }
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> > > What you are seeing is "just the way FreeBSD currently works."
> >> >> > >
> >> >> > > Sleeping (in most all of its various forms, and I've just looked
at the
> >> >> > > kevent code to verify this is true there) is handled by converting
the
> >> >> > > amount of time to sleep (usually specified in a timeval or
timespec
> >> >> > > struct) to a count of timer ticks, using an internal routine
called
> >> >> > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick
to
> >> >> > > account for the current tick. Whether that's a good idea or not
(it
> >> >> > > probably was once, and probably not anymore) it's how things
currently
> >> >> > > work, and could explain the fairly consistant +1ms you're seeing.
> >> >> >
> >> >> > This is all true, but mostly irrelevant for his case. EVFILT_TIMER
> >> >> > installs a periodic callout that executes KNOTE() and then resets
itself (via
> >> >> > callout_reset()) each time it runs. This should generally be closer
to
> >> >> > regulary spaced intervals than something that does:
> >> >> >
> >> >>
> >> >> In what way is it irrelevant? That is, what did I miss? It appears
to
> >> >> me that the next callout is scheduled by calling timertoticks()
passing
> >> >> a count of milliseconds, that count is converted to a struct timeval
and
> >> >> passed to tvtohz() which is where the +1 adjustment happens. If you
ask
> >> >> for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms.
> >> >> There is some time, likely a small number of microseconds, that you've
> >> >> consumed of the current tick, and that's what the +1 in tvtohz() is
> >> >> supposed to account for according to the comments.
> >> >>
> >> >> The tvtohz() routine both rounds up in the usual way
(value+tick-1)/tick
> >> >> and then adds one tick on top of that. That seems not quite right to
> >> >> me, except that it is
Re: CVE-2012-0217 Intel's sysret Kernel Privilege Escalation and FreeBSD 6.2/6.3
On Friday, July 13, 2012 10:42:04 am Poul-Henning Kamp wrote: > In message <201207130831.59211@freebsd.org>, John Baldwin writes: > > >Every FreeBSD/amd64 kernel in existent is vulnerable. In truth, my personal > >opinion is that Intel screwed up their implementation of that instruction > >whereas AMD got it right, and we are merely working around Intel's CPU bug. :( > > Given that the instruction set of AMD64 is defined by AMD originally, > while Intel was trying very hard to ram Itanic down everybodys > throat, that diagnosis is a given: Intel copied AMD, and difference > in functionality is a screwup on Intels part, even if they documented > their screwup in their manual. > > TL;DR: Which part of "compatible" doesn't Intel get ? In this case, I believe they were just lazy and reused some existing block to manage this exception case without properly thinking through the security implications of using a user-supplied stack pointer to handle a fault. -- John Baldwin ___ 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
In message <201207130831.59211@freebsd.org>, John Baldwin writes: >Every FreeBSD/amd64 kernel in existent is vulnerable. In truth, my personal >opinion is that Intel screwed up their implementation of that instruction >whereas AMD got it right, and we are merely working around Intel's CPU bug. :( Given that the instruction set of AMD64 is defined by AMD originally, while Intel was trying very hard to ram Itanic down everybodys throat, that diagnosis is a given: Intel copied AMD, and difference in functionality is a screwup on Intels part, even if they documented their screwup in their manual. TL;DR: Which part of "compatible" doesn't Intel get ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
Hi, On Fri, Jul 13, 2012 at 11:02 AM, John Baldwin wrote: > On Friday, July 13, 2012 10:42:04 am Poul-Henning Kamp wrote: >> In message <201207130831.59211@freebsd.org>, John Baldwin writes: >> >> >Every FreeBSD/amd64 kernel in existent is vulnerable. In truth, my > personal >> >opinion is that Intel screwed up their implementation of that instruction >> >whereas AMD got it right, and we are merely working around Intel's CPU bug. > :( >> >> Given that the instruction set of AMD64 is defined by AMD originally, >> while Intel was trying very hard to ram Itanic down everybodys >> throat, that diagnosis is a given: Intel copied AMD, and difference >> in functionality is a screwup on Intels part, even if they documented >> their screwup in their manual. >> >> TL;DR: Which part of "compatible" doesn't Intel get ? > > In this case, I believe they were just lazy and reused some existing block to > manage this exception case without properly thinking through the security > implications of using a user-supplied stack pointer to handle a fault. > Just as FreeBSD's developers were lazy when new-bus was designed ? Honestly, what's the point of this rock throwing and ad-hominem attacks ? I could start throwing a few more CVE-2009-2936 or CVE-2009-4488; just to point out nobody's perfect... - Arnaud ___ 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: newbus' ivar's limitation..
Hi, On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh wrote: > [..] > Honestly, though, I think you'll be more pissed when you find out that the > N:1 interface that you want is being done in the wrong domain. But I've been > wrong before and look forward to seeing your replacement. > I will just pass function pointers for now, if things should be done dirty, let's be explicit about it. Now, the hinted device attachment did work quite smoothly, however, I would have a few suggestion: 1) add a call to bus_enumerate_hinted_children() before the call DEVICE_IDENTIFY() call in bus_generic_driver_added() this is required to be able to support dynamic loading and attachment of hinted children. 2) have a generic bus_hinted_child method which would just add a new child to the bus. 3) have bus_enumerate_hinted_children() and bus_generic_attach() always ran on device attachment. There is current +100 explicit call to bus_generic_attach() in the sys/dev/ tree. This should be done always and implicitly. 4) have bus_generic_detach() always ran prior to device detachment If not already the case. There is still the same +100 direct call to bus_generic_detach is the tree. 5) have the bus_generic_* method be the default of their respective method 6) have device_delete_child() called upon device detachment. As a rule of thumb, when a kld is unloaded there should not be any remains of anything built previously. Without device_delete_child() or proper singleton implementation, multiple load/unload sequence of bus will attempt to attach multiple version of a child, even if the single child was added prior to the bus_generic_attach() call. Also, as a rule of thumb, if the same logic is implemented in more than a few buses, it should be made generic and implicit. I am lazy, I hate doing the same things over and over, not to say it raised the likelihood of bugs' introduction... - Arnaud ___ 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"
