Re: Seccomp support for linux-m68k
Hi,
On 3/22/20 12:18 AM, Michael Schmitz wrote:
Am 21.03.2020 um 11:59 schrieb John Paul Adrian Glaubitz:
On 3/20/20 11:49 PM, Finn Thain wrote:
I suspect (without evidence) that many m68k systems are actually virtual
machines. And the need for container hosting on m68k seems negligible.
It isn't about security. It's about being able to build more packages
as some packages have started to make libseccomp support mandatory.
Is there a good technical reason for this decision? I suppose most of
these packages are not about VM or container hosting?
Besides VM / container programs, SSH and browsers use it also:
https://en.wikipedia.org/wiki/Seccomp
What about checking at runtime for availability of the library, and
disabling VM related functionality if it wasn't possible to load?
That would require changing large number of
upstream projects (including things like Chromium)
to:
* load it dynamically
* handling libseccomp missing
I think much easier would be to patch libseccomp
to build without arch support, and just return
errors to API calls:
https://github.com/seccomp/libseccomp/blob/master/src/arch.c#L100
In the event that kernel support can't be avoided: I suppose there a git
commit for Helge's hppa changes that would help gauge the effort
required for implementing such support?
In general it seems to require:
* libseccomp: arch recognition & syscall
mapping support:
https://github.com/seccomp/libseccomp/blob/master/src/arch-parisc-syscalls.c
* kernel: Adding the new syscall number
* kernel: Calling seccomp on syscall invalidation path
* kernel: Potentially something related to 32-bit & ptrace
Which all seem fairly straightforward, but many of
the projects seem to be using seccomp-bpf, instead
of plain seccomp.
How's m68k BPF support?
- Eero
PS. Not related to seccomp, but Hatari's 030
emulation exception handling has been improved
a lot recently, e.g. exception addresses on auto-
increment instructions should be correct etc.
(I'm still seeing random errors on kernel syscall
interface, but I'm starting to wonder whether it's
related to something else than 030 emulation, as
Linux works fine under the same CPU core code
within WinUAE Amiga emulator.)
Reply to: