Re: MirageOS meeting 2022-11-30

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

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