Re: veriexec(4) maintenance
On Tue, Dec 19, 2023 at 07:50:25AM +1030, Brett Lymn wrote:
> On Sat, Sep 02, 2023 at 08:57:03AM +0930, Brett Lymn wrote:
> > On Thu, Aug 31, 2023 at 10:24:07AM +0200, J. Hannken-Illjes wrote:
> > >
> > > I'm short on time, some remarks:
> > >
> >
> > Thanks, I will have a closer look at these issues. This could be where the
> > deadlock I was
> > seeing is coming from.
> >
>
> OK, I have, finally, updated the diff in line with the comments (thanks
> again for the good feedback).
Brett,
first it is difficult to read a diff that also introduces a "notyet" operation
on file pages.
Looks like you replace global and item rw-locks with refcounts/signals.
I tried to understand the rationale behind and failed. Your implementation
seems at least vulnerable to livelocks as the writer side is missing priority.
In general, what problem(s) are you trying to solve here?
What is wrong with a quite simple hashtable to hold fileid<->fingerprint
mapping accessed as:
mutex_enter table lock
lookup fileid -> item
mutex_enter item
mutex_exit table lock
while item state is busy
cv_wait item cv
if item state is unknown
set item state busy
mutex_exit item
compute fingerprint
mutex_enter item
set item state valid/invalid
cv_broadcast item cv
Here the item state is either valid or invalid
mutex_exit item
Some more problems (line numbers with your diff applied):
476 veriexec_fp_calc(struct lwp *l, struct vnode *vp, int lock_state,
477 struct veriexec_file_entry *vfe, u_char *fp)
478 {
524 error = vn_rdwr(UIO_READ, vp, buf, len, offset,
525 UIO_SYSSPACE, lock_state,
lock_state is sometimes VERIEXEC_UNLOCKED, sometimes IO_NODELOCKED.
1629 veriexec_dump(struct lwp *l, prop_array_t rarray)
1630 {
1631 struct mount *mp;
1632 mount_iterator_t *mpiter;
1633
1634 mountlist_iterator_init();
1635
1636 while ((mp = mountlist_iterator_trynext(mpiter)) != NULL) {
1637 /* If it fails, the file-system is [being] unmounted. */
1638 if (vfs_busy(mp) != 0)
1639 continue;
This is completely wrong. Operation mountlist_iterator_trynext() already
returns the mount busy and skips mounts currently unmounting or remounting.
Operation mountlist_iterator_next() was right or does this function get
called from inside unmount?
1653 veriexec_flush(struct lwp *l)
1654 {
1655 struct mount *mp;
1656 mount_iterator_t *mpiter;
1657 int error = 0;
1658
1659 mountlist_iterator_init();
1660
1661 while ((mp = mountlist_iterator_trynext(mpiter)) != NULL) {
1662 int lerror;
1663
1664 /* If it fails, the file-system is [being] unmounted. */
1665 if (vfs_busy(mp) != 0)
1666 continue;
This is completely wrong, see above.
--
J. Hannken-Illjes
Re: pvclock (kvm_clock) support: where to attach
On 12/31/23 15:17, Taylor R Campbell wrote: https://nxr.netbsd.org/xref/src/sys/arch/xen/xen/xen_clock.c oh. Unless there's a compelling reason that the pvclock and xenclock interfaces are different enough to warrant having multiple copies of the logic in src, I think we should adapt the existing code to work in both settings. I put a lot of work into the xen_clock.c driver to record useful diagnostics about when the host's time is not behaving right (vs when NetBSD itself has done something wrong), which we've seen in practice on various hosts, and it would be a shame to lose that. Ok, the point is to have an interface that is able to expose kvm_clock, which is used by Firecracker, I guess this could be added without much pain into this existing Xen code. If not, I think long-term we should introduce a new sys/dev/pv or something, move the bulk of xen_clock.c to that (other than the Xen-specific parts), and have both the Firecracker code and the Xen code use it. Actually that's what OpenBSD does, they do have a sys/dev/pv with a pvbus and it's honestly a classy way of dealing with various hypervisors. On a side note: I'm not used to this clock/rtc mechanisms, but something puzzles me, when the virtual machine is started without MC146818 RTC support, it hangs at todr_gettime_ymdhms, which is mapped to rtc_get_ymdhms in sys/arch/x86/isa/rtc.c, which at the end of the day calls mc146818_read(). Shouldn't sys/arch/x86/isa/clock.c:startrtclock() return when mc146818_read() fails? There seem to have nothing but MC146818 for RTC in x86. -- Emile `iMil' Heitor | https://imil.net
Re: pvclock (kvm_clock) support: where to attach
> Date: Sun, 31 Dec 2023 11:36:41 +0100 > From: Emile 'iMil' Heitor > > I ported pvclock / kvm_clock from OpenBSD in order for Firecracker to > have an RTC. It's working but I'm not entirely sure where to attach it. > > The device is x86 only so I added the source code in arch/x86/x86, and > for now I have it attached at cpufeaturebus which felt the more natural. > > Thoughts? > > Here's the code: > https://github.com/NetBSD/src/commit/c09440be5aca7e16ce845c3ccbdfb47bac03fb63 Oops... We already have a driver for what I think is essentially the same thing in Xen: https://nxr.netbsd.org/xref/src/sys/arch/xen/xen/xen_clock.c Unless there's a compelling reason that the pvclock and xenclock interfaces are different enough to warrant having multiple copies of the logic in src, I think we should adapt the existing code to work in both settings. I put a lot of work into the xen_clock.c driver to record useful diagnostics about when the host's time is not behaving right (vs when NetBSD itself has done something wrong), which we've seen in practice on various hosts, and it would be a shame to lose that. Do you know if there are substantive differences in the interface? If not, I think long-term we should introduce a new sys/dev/pv or something, move the bulk of xen_clock.c to that (other than the Xen-specific parts), and have both the Firecracker code and the Xen code use it. Couple notes having only glanced at this code, if we do want to keep it as is: - *_activate is obsolete; nothing but cardbus calls it and new drivers should never provide it. - virtio_membar_sync seems wrong -- this should read-before-read, which is membar_consumer, not membar_sync (but I don't know why there's a separate virtio_membar_*).
Re: PSA: Clock drift and pkgin
I believe you. But aren't we now getting into pretty realtime stuff? Not sure NetBSD is at all suitable for such applications/environments. As you say - if this only behaves acceptably if the system is not under load, then it's not a solution I would go for. But again - I guess we're talking very personal opinions/experiences/tradeoffs here. I still don't really believe we need very high resolution scheduling. And tickless is sortof a separate topic to this. Johnny On 2023-12-31 05:20, Konrad Schroder wrote: On 12/30/2023 3:42 PM, Johnny Billquist wrote: On 2023-12-31 00:11, Michael van Elst wrote: Better than 100Hz is possible and still precise. Something around 1000Hz is necessary for human interaction. Modern hardware could easily do 100kHz. ? If I remember right, anything less than 200ms is immediate response for a human brain. Which means you can get away with much coarser than even 100Hz. And there are certainly lots of examples of older computers with clocks running in the 10s of ms, where human interaction feels perfect. I'm not sure about visual and auditory sensation, but haptic VR requires position updates >= 1000Hz to get texture right. The timing of two impulses that close together may not be felt as two separate events, but the frequency of vibrations within the skin when it interacts with a surface (even through a tool, such as a stylus) is encoded by the nerve endings in the skin itself. We used to use PHANTOM haptic arms at $WORK, driven by an Indigo2. If the control loop operated at less than 1000Hz---for example, if the Indigo2 was under load--- it introduced noticeable differences in the sensation of running the pen over a virtual object. The simulation was much more sensitive to that than it was to the timing of the video output, for which anything greater than 72Hz was wasted. Take care, -Konrad -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
pvclock (kvm_clock) support: where to attach
I ported pvclock / kvm_clock from OpenBSD in order for Firecracker to have an RTC. It's working but I'm not entirely sure where to attach it. The device is x86 only so I added the source code in arch/x86/x86, and for now I have it attached at cpufeaturebus which felt the more natural. Thoughts? Here's the code: https://github.com/NetBSD/src/commit/c09440be5aca7e16ce845c3ccbdfb47bac03fb63 -- Emile `iMil' Heitor | https://imil.net
re: Perceivable time differences [was Re: PSA: Clock drift and pkgin]
Johnny Billquist writes: > Ok. I oversimplified. > > If I remember right, the point was that something sub 200ms is perceived > by the brain as being "instananeous" response. It don't mean that one > cannot discern shorter times, just that from an action-reaction point of > view, anything below 200ms is "good enough". > > My point was merely that I don't believe you need to have something down > to ms resolution when it comes to human interaction, which was the claim > I reacted to. mouse's example is actually not the limits. humans can tell audio down to about 1ms or less timing in the best cases. reaction time has nothing to do with expected time when you're doing music things. you can't react to the beat, you have to be ready to go at the same time, *MUCH* closer than 200ms, so that all the musicians in a band are in sync. what one needs from their computer is different for each of us and while most tasks are fine with our current tickless setup, there are plenty of cases we can do better with it. note that tickless and hi-res timers are not really the same thing even if we can achieve one by implementing the other, we *could* introduce hi-res timers on machines with it, but it would be easier with a tickless framework to use. .mrg.
Re: PSA: Clock drift and pkgin
On Saturday, December 30, 2023 at 10:43:34 AM PST, Martin Husemann wrote: > Kernels on that machines just would not run fully tickless. That makes sense. I personallly would call that "tickless where possible", not "fullly tickless".
