[MIR] liburing
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
liburing (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Availability]
liburing is in universe in groovy at version 0.6-3 without Ubuntu Delta at the moment.
It builds for the Ubuntu architectures amd64, arm64, armhf, ppc64el, riscv64, s390x.
[Rationale]
liburing can be used for advanced asynchronous IO in qemu (>=5),
samba (>=4.12.x) and probably more down the road.
- https:/
- https:/
- https:/
Since groovy is the first step towards 22.04 I think it would be great to
enable liburing now and see how things behave and if/how they are further
adopted.
[Security]
There was a CVE of the kernel side of the interface
https:/
It is already handled and fixed in all Ubuntu releases:
https:/
So far nothing else came up, but generally I/O interfaces are a good place
to exploit so there is an elevated risk I guess.
[Quality assurance]
The package has build time tests that are not yet working, so it ignores the
return value for now, but runs them to gather data. Mostly it seems permission
or kernel config errors.
It also has autopkgtests but those also miss permissions.
Note: I have forwarded an MP to Debian about the root permission at
build/test time.
Further all seems ok:
- No debconf questions.
- No long-term outstanding bugs.
- The package is maintained well in Debian/Ubuntu (sync, no open bugs)
- The package does not deal with exotic hardware (just very recent kernels)
- The package uses a debian/watch file
- not using python(2)
- symbols tracking is in place
- lintian --pedantic is rather happy
[UI standards]
this has no end-user UI, so no translations seem needed.
[Dependencies]
No other dependencies than libc6. This really is just a path to the kernel
and does not need many other components.
[Standards compliance]
- The package meets the FHS and Debian Policy standards.
- d/rules and d/control as small and well written
[Maintenance]
The Server team will subscribe for the package for maintenance
[Background]
quote https:/
"""
io_uring is a powerful new way to do asynchronous I/O programming under Linux.
Doing away with various limitations of previous generation I/O subsystems,
io_uring holds immense promise. For more details on what io_uring brings to
the table, please see the chapter What is io_uring?.
"""
Related branches
- Andreas Hasenack: Approve
- Canonical Server: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 175 lines (+106/-7)7 files modifieddebian/changelog (+6/-0)
debian/control (+2/-1)
debian/patches/disable-known-failures.patch (+75/-0)
debian/patches/series (+1/-0)
debian/rules (+13/-1)
debian/tests/control (+1/-1)
debian/tests/test-build (+8/-4)
CVE References
description: | updated |
description: | updated |
summary: |
- MIR: liburing + [MIR] liburing |
Changed in liburing (Ubuntu): | |
status: | Fix Released → In Progress |
assignee: | Christian Ehrhardt (paelzer) → nobody |
More context: 218-245- 87.hlrn. qwest.net) has joined
<andreas> brauner: hi, kernel uring, exciting?
<andreas> brauner: I'm wondering if it's too early to consider it for an MIR
<andreas> samba 4.12.x can use it
* trudd (Rudd@71-
<brauner> andreas: a lot of people want it i'm sure. especially db people. but it is a lot of code and relatively new. it should be enabled by default anyway, no?
<andreas> brauner: what do you mean enabled by default? Where?
<andreas> in the kernel?
<brauner> andreas: i.e. it's a new feature that defaults to =y in the kernel
<brauner> andreas: yes
<andreas> ah, sure
<andreas> I was asking about the userspace library
<brauner> andreas: oh ok
<andreas> but yeah, also about the feature in general
<andreas> agreed with "it's new"
<brauner> andreas: so if you have the kernel stuff enabled you can likely enable the userspace stuff too
<brauner> andreas: the problem really is the kernel side default
<andreas> brauner: right, but it's in universe
<andreas> the userspace bit
<brauner> andreas: one thing to consider is that io_uring offloads unprivileged user workloads on async kernel threads
<brauner> andreas: and that's pretty scary
<brauner> andreas: it has seen some naste cves already
<andreas> cves in the kernel?
<brauner> andreas: yes
<andreas> interesting
<andreas> mind if I paste this conversation in the MIR bug I'm preparing?
<brauner> andreas: an obvious problem is that kernel threads run with kernel creds usually and io_uring needs to override them with the creator's cred (of the io_uring instance)
<brauner> andreas: and they forgot that at one point so ...
<brauner> andreas: that was the first cve
<brauner> andreas: no, go ahead
<andreas> it's my understanding this shared space is the big benefit of uring
<brauner> andreas: there's more to it than that but yes, it means you don't have a lot of context switches
<andreas> no data to copy between kernel and user space
<andreas> right
<brauner> andreas: you register work, kernel does it, notifies you when done. data is shared in mmaped buffers basically
https:/ /cve.mitre. org/cgi- bin/cvename. cgi?name= CVE-2019- 19241