[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] seccomp: Whitelist cacheflush since 2.2.0 n

From: Andrew Jones
Subject: Re: [Qemu-devel] [PATCH 1/2] seccomp: Whitelist cacheflush since 2.2.0 not 2.2.3
Date: Fri, 8 Apr 2016 14:39:32 +0200
User-agent: Mutt/ (2014-03-12)

On Fri, Apr 08, 2016 at 12:54:54PM +0100, Peter Maydell wrote:
> On 8 April 2016 at 12:45, Andrew Jones <address@hidden> wrote:
> > On Mon, Apr 04, 2016 at 09:29:15AM +0100, James Hogan wrote:
> >> The cacheflush system call (found on MIPS and ARM) has been included in
> >> the libseccomp header since 2.2.0, so include include it back to that
> >> version. Previously it was only enabled since 2.2.3 since that is when
> >> it was enabled properly for ARM.
> >>
> >> This will allow seccomp support to be enabled for MIPS back to
> >> libseccomp 2.2.0.
> >>
> >> Signed-off-by: James Hogan <address@hidden>
> >> Cc: Eduardo Otubo <address@hidden>
> >> Cc: Aurelien Jarno <address@hidden>
> >> ---
> >>  qemu-seccomp.c | 4 +---
> >>  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > Reviewed-By: Andrew Jones <address@hidden>
> Andrew: when we originally put this ifdeffery in you said
> "libseccomp didn't know about cacheflush until 2.2.1, and we
>  require 2.2.3 for other reasons"
> (https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg07258.html)

In that message I was referring to arm/aarch64 (the only arch at the
time that cared about cacheflush). 2.2.0 was the first version arm got
any cacheflush support (same version as x86 an mips), but it was
completely wrong until 2.2.1. Additional problems were then fixed for
2.2.3. x86 doesn't use cacheflush and mips didn't have any problems
(I guess), so they've been fine since 2.2.0.

As long as the configure script still requires a libseccomp_minver of
2.2.3 for arm/aarch64, then it doesn't matter if the HAVE_CACHEFLUSH
minimum version in qemu-seccomp.c is relaxed for the other
architectures that work.

> Has something changed, were you just wrong back then, or have
> you forgotten something this time around? (Do you remember what
> the "other reasons" were?)

One reason was that the syscalls for ARM were assuming only a
__NR_ prefix instead of __ARM_NR_. And I think there was yet
another issue too, but I can't recall that one now.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]