Hello,
please find the minutes below. Next meeting in 2 weeks, on Dec 14th.
Have a nice day,
Hannes
# MirageOS meeting 2022-11-30
participants: mindy, pierre, taka, hannes, christiano, reynir, dinosaure
## Mirage-kv.batch (reynir, https://github.com/mirage/mirage-kv/issues/36)
- the semantics as described in the documentation is not met
- it is rather hard to implement in various scenarios (littlefs, tar)
- let's just remove it from the interface, any KV implementation can
always extend the interface
## Mirage-block (reynir,
https://github.com/mirage/mirage-block-solo5/pull/28)
- this is merged and released as part of mirage-block-solo5 0.8.1 :)
## Memory leak on `mirage-tcpip` (dinosaure,
https://github.com/mirage/mirage-tcpip/issues/499)
- a fiber is never cancelled and is kept alive indefinitely; memory leak
- appears in http, bob, ..
- if someone has knowledge about the codebase and knows how to fix it,
dinosaure is eager to test it out :)
- christiano took a look into the tcp library, and couldn't find a
solution. Is more motivated for utcp (https://github.com/roburio/utcp)
- previous patch on mirage-solo5 (to not sleep for paused tasks,
mirage-solo5 0.9.1) amplifies the memory leak
- christiano also mentions there may be a DoS if a future segment is
received (i.e. some missing segment)
- there's also a maybe related issue about memory usage in keepalive
https://github.com/mirage/mirage-tcpip/issues/367
- and an issue that the window never opens
https://github.com/mirage/mirage-tcpip/issues/340
## `mmap` available on `Mirage_block.S` (dinosaure,
https://github.com/mirage/mirage-block/issues/53)
- dinosaure has an implementation to get a part of the block (similar to
mmap), without being in the Lwt monad
- at the moment, read is in Lwt.t, i.e. does not block, but returns the
filled page(s)
- dinosaure needs a blocking function that returns the data
- the solo5 interface is already blocking (and synchronous),
mirage-block-solo5 adds the asynchronous stuff
- christiano mentions that it could be done with locking
- maybe develop a block read-only interface with a synchronous read
## Qubes-mirage-firewall
- released 0.8.3 (thanks Hannes!):
https://github.com/mirage/qubes-mirage-firewall/releases/tag/v0.8.3
- pierre now uses 16MB memory for the qubes-firewall (but it is
constantly collecting garbage, so let's stick to 32MB)
- DemiMarie (a QubesOS developer) also mentioned that if
mirage-qubes-firewall becomes fast enough, it could be the default
firewall for QubesOS
- proposed to be included in qubes community repository
- https://github.com/QubesOS/qubes-issues/issues/7884
- https://github.com/mirage/qubes-mirage-firewall/issues/157
- next steps for development (if a OpenBSD/HardenedBSD sys-net is used,
which doesn't have netback support)
- https://github.com/jcholsap/freemod/issues/1
-
https://forum.qubes-os.org/t/unable-to-shutdown-mirage-firewall-without-netvm-attached/13606/2
- there's a performance difference between TCP and UDP
- iperf3 is not bidirectional by default, so the data may be stacking
up, and the ACKS not being delivered
- there may as well be more work done for TCP packets (header
decoding, checksum computation)
- christiano developed https://github.com/bluhm/tcpbench-portable as
alternative to iperf
## `mirage/mirage` release? (dinosaure)
- pierre is in favour of a release, due to mirage-block-ccm support
- also mirage-skeleton has a ccm-block example, which doesn't compile
with mirage 4.3.1
- is there a way in config.ml to restrict / lower bound a mirage
version? - no, but we should work on such a check:
- in config.ml specify the lower bound of mirage
- mirage configure should check its version against the lower bound
and complain if it is not compatible
On 29/11/2022 18:54, Hannes Mehnert wrote:
Hi,
since we missed that meeting last week, let's meet tomorrow (Nov 30th)
at 14:00 CET on whereby.com/ocamllabs. The agenda is in the pad
https://pad.data.coop/V5YCNQ9HSGioZ46aeQaHoQ?view (feel free to add your
points).
Best,
Hannes
On 15/11/2022 15:46, Reynir wrote:
Hello,
It seems that since the retreat, we have not properly updated our
MirageOS
meetings (although some have been organised). We should have warned you
that these are coming back (once every fortnight).
So, we propose to continue these useful meetings (in order to stay in
sync
with what we are doing). The next meeting will be held on 23 November at
14:00 UTC+1 (as usual) if this is convenient for you.
I drafted a meeting agenda (future meeting notes). Please feel free to
add any items.
https://pad.data.coop/V5YCNQ9HSGioZ46aeQaHoQ?view
Best,
Reynir
