Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 30 3月, 2016 1 次提交
  3. 24 3月, 2016 1 次提交
  5. 23 3月, 2016 1 次提交
  7. 17 3月, 2016 2 次提交
    • D
      crypto: add support for PBKDF2 algorithm · 37788f25
      由 Daniel P. Berrange 提交于 
      The LUKS data format includes use of PBKDF2 (Password-Based
Key Derivation Function). The Nettle library can provide
an implementation of this, but we don't want code directly
depending on a specific crypto library backend. Introduce
a new include/crypto/pbkdf.h header which defines a QEMU
API for invoking PBKDK2. The initial implementations are
backed by nettle & gcrypt, which are commonly available
with distros shipping GNUTLS.

The test suite data is taken from the cryptsetup codebase
under the LGPLv2.1+ license. This merely aims to verify
that whatever backend we provide for this function in QEMU
will comply with the spec.
Reviewed-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      37788f25
    • D
      crypto: add cryptographic random byte source · b917da4c
      由 Daniel P. Berrange 提交于 
      There are three backend impls provided. The preferred
is gnutls, which is backed by nettle in modern distros.
The gcrypt impl is provided for cases where QEMU build
against gnutls is disabled, but crypto is still desired.
No nettle impl is provided, since it is non-trivial to
use the nettle APIs for random numbers. Users of nettle
should ensure gnutls is enabled for QEMU.
Reviewed-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      b917da4c
  9. 08 3月, 2016 1 次提交
  11. 23 2月, 2016 1 次提交
  13. 11 2月, 2016 1 次提交
  15. 10 2月, 2016 1 次提交
  17. 09 2月, 2016 1 次提交
    • D
      configure: sanity check the glib library that pkg-config finds · 977a82ab
      由 Daniel P. Berrange 提交于 
      Developers on 64-bit machines will often try to perform a
32-bit build of QEMU by running

  ./configure --extra-cflags="-m32"

Unfortunately if PKG_CONFIG_LIBDIR is not set to point to
the location of the 32-bit pkg-config files, then configure
will silently pick up the 64-bit pkg-config files and still
succeed.

This causes a problem for glib because it means QEMU will
be pulling in /usr/lib64/glib-2.0/include/glibconfig.h
instead of /usr/lib/glib-2.0/include/glibconfig.h

This causes problems because the 'gsize' type (defined as
'unsigned long') will no longer be fully compatible with
the 'size_t' type (defined as 'unsigned int'). Although
both are the same size, the compiler refuses to allow
casts from 'unsigned long *' to 'unsigned int *' as they
are different pointer types. This results in non-obvious
compiler errors when building QEMU eg

qga/commands-posix.c: In function ‘qmp_guest_set_user_password’:
qga/commands-posix.c:1912:55: error: passing argument 2 of ‘g_base64_decode’ from incompatible pointer type [-Werror=incompatible-pointer-types]
     rawpasswddata = (char *)g_base64_decode(password, &rawpasswdlen);
                                                            ^
In file included from /usr/include/glib-2.0/glib.h:35:0,
                 from qga/commands-posix.c:14:
/usr/include/glib-2.0/glib/gbase64.h:52:9: note: expected ‘gsize * {aka long unsigned int *}’ but argument is of type ‘size_t * {aka unsigned int *}’
 guchar *g_base64_decode         (const gchar  *text,
         ^
cc1: all warnings being treated as errors

To detect this problem, add a check to configure that
verifies that GLIB_SIZEOF_SIZE_T matches sizeof(size_t).
If this fails print a warning suggesting that the dev
probably needs to set PKG_CONFIG_LIBDIR.

On Fedora x86_64 it passes with any of:

 # ./configure
 # PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig ./configure --extra-cflags="-m32"
 # PKG_CONFIG_LIBDIR=/usr/lib64/pkgconfig ./configure --extra-cflags="-m64"

And fails with a mis-match

 # PKG_CONFIG_LIBDIR=/usr/lib64/pkgconfig ./configure --extra-cflags="-m32"
 # PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig ./configure --extra-cflags="-m64"

ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
       You probably need to set PKG_CONFIG_LIBDIR
       to point to the right pkg-config files for your
       build target
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-Id: <1453885245-15562-1-git-send-email-berrange@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      977a82ab
  19. 03 2月, 2016 2 次提交
  21. 30 1月, 2016 1 次提交
  23. 27 1月, 2016 2 次提交
  25. 11 1月, 2016 1 次提交
  27. 18 12月, 2015 2 次提交
    • P
      configure: Fix shell syntax to placate OpenBSD's pdksh · 18f49881
      由 Peter Maydell 提交于 
      Unfortunately the OpenBSD pdksh does not like brackets inside
the right part of a ${variable+word} parameter expansion:

  $ echo "${a+($b)}"
  ksh: ${a+($b)}": bad substitution

though both bash and dash accept them. In any case this line
was causing odd output in the case where nettle is not present:
  nettle    no ()

(because if nettle is not present then $nettle will be "no",
not a null string or unset).

Rewrite it to just use an if.

This bug was originally introduced in becaeb72 and was present
in the 2.4.0 release.

Fixes: https://bugs.launchpad.net/qemu/+bug/1525682
Reported-by: Dmitrij D. Czarkoff
Cc: qemu-stable@nongnu.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 1450105357-8516-1-git-send-email-peter.maydell@linaro.org
      18f49881
    • D
      io: add QIOChannelSocket class · 559607ea
      由 Daniel P. Berrange 提交于 
      Implement a QIOChannel subclass that supports sockets I/O.
The implementation is able to manage a single socket file
descriptor, whether a TCP/UNIX listener, TCP/UNIX connection,
or a UDP datagram. It provides APIs which can listen and
connect either asynchronously or synchronously. Since there
is no asynchronous DNS lookup API available, it uses the
QIOTask helper for spawning a background thread to ensure
non-blocking operation.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      559607ea
  29. 04 12月, 2015 2 次提交
    • R
      configure: use appropriate code fragment for -fstack-protector checks · fccd35a0
      由 Rodrigo Rebello 提交于 
      The check for stack-protector support consisted in compiling and linking
the test program below (output by function write_c_skeleton()) with the
compiler flag -fstack-protector-strong first and then with
-fstack-protector-all if the first one failed to work:

  int main(void) { return 0; }

This caused false positives when using certain toolchains in which the
compiler accepted -fstack-protector-strong but no support was provided
by the C library, since for this stack-protector variant the compiler
emits canary code only for functions that meet specific conditions
(local arrays, memory references to local variables, etc.) and the code
fragment under test included none of them (hence no stack protection
code generated, no link failure).

This fix changes the test program used for -fstack-protector checks to
include a function that meets conditions which cause the compiler to
generate canary code in all variants.
Signed-off-by: NRodrigo Rebello <rprebello@gmail.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      fccd35a0
    • P
      configure: Diagnose broken linkers directly · 0ef74c74
      由 Peter Maydell 提交于 
      Currently if the user's compiler works for creating .o files but
their linker is broken such that compiling an executable from a
C file does not work, we will report a misleading error message
about the compiler not supporting __thread (since that happens
to be the first test we run which requires a working linker).
Explicitly check that compile_prog works as well as compile_object,
so that people whose toolchain setup is broken get a more helpful
error message.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      0ef74c74
  31. 30 11月, 2015 1 次提交
  33. 19 11月, 2015 1 次提交
  35. 16 11月, 2015 2 次提交
  37. 14 11月, 2015 1 次提交
  39. 13 11月, 2015 1 次提交
  41. 10 11月, 2015 1 次提交
  43. 06 11月, 2015 2 次提交
  45. 05 11月, 2015 1 次提交
    • J
      configure: disable FORTIFY_SOURCE under clang · b553a042
      由 John Snow 提交于 
      Some versions of clang may have difficulty compiling glibc headers when
-D_FORTIFY_SOURCE is used. For example, Clang++ 3.5.0-9.fc22 cannot
compile glibc's stdio headers when -D_FORTIFY_SOURCE=2 is used. This
manifests currently as build failures with clang and any arm target.

According to LLVM dev Richard Smith, clang does not target or support
FORTIFY_SOURCE + glibc, and it should not be relied on.
"It's still an unsupported combination, and while it might compile, some
of the checks are unlikely to work because they require a frontend
inliner to be useful"

See: http://lists.llvm.org/pipermail/cfe-dev/2015-November/045846.html

Conclusion: disable fortify-source if we appear to be using clang instead
of testing for compile success or failure, which may be incidental or not
indicative of proper support of the feature.
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Message-Id: <1446583422-10153-1-git-send-email-jsnow@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      b553a042
  47. 04 11月, 2015 1 次提交
    • J
      configure: disallow ccache during compile tests · 5e4dfd3d
      由 John Snow 提交于 
      If the user is using ccache during the configuration step,
it may interfere with some of the configuration tests,
particularly the "Is ccache interfering with macro analysis" step,
which is a bit of a poetic problem.

1) Disallow ccache from reading from the cache during configure,
   but don't disable it entirely to allow us to see if it causes other
   problems.

2) Force off CCACHE_CPP2 during the ccache test to get a deterministic
   answer over whether or not we need to enable that feature later.
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Message-Id: <1446055000-29150-1-git-send-email-jsnow@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      5e4dfd3d
  49. 03 11月, 2015 1 次提交
    • O
      ui/opengl: Reduce build required libraries for opengl · fb719563
      由 OGAWA Hirofumi 提交于 
      We now use epoxy to load opengl libraries. This means we don't need to
link opengl libraries directly if interfaces handled by epoxy. With
this, we just need epoxy headers and epoxy's *.so to build.

Tested with epoxy-1.3.1.

- sdl2/gtk/console egl stuff doesn't require other than epoxy
- milkymist-tmu2 glx stuff doesn't require other than epoxy

(lm32 test is limited, because can't find mmone-bios.bin, so just test
to load libGL with "./lm32-softmmu/qemu-system-lm32 -M milkymist,accel=qtest")
Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

[ lm32 tested by kraxel ]
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      fb719563
  51. 25 10月, 2015 1 次提交
  53. 23 10月, 2015 2 次提交
    • D
      configure: avoid polluting global CFLAGS with tasn1 flags · 90246037
      由 Daniel P. Berrange 提交于 
      The previous commit

  commit 9a2fd434
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Mon Apr 13 14:01:39 2015 +0100

    crypto: add sanity checking of TLS x509 credentials

defined new variables $TEST_LIBS and $TEST_CFLAGS and
used them in tests/Makefile to augment $LIBS and $CFLAGS.

Unfortunately this overlooks the fact that tests/Makefile
is not executed via recursive-make, it is just pulled into
the top level Makefile via an include statement. So rather
than just augmenting the compiler/linker flags for tests
it polluted the global flags.

This is thought to be behind a reported failure when
building the pixman module as a sub-module, since global
$CFLAGS are passed down to configure in pixman.

This change removes the $TEST_LIBS and $TEST_CFLAGS
replacing them with $TASN1_LIBS and $TASN1_CFLAGS,
setting only against specific objects/executables
that need them.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      90246037
    • D
      crypto: allow use of nettle/gcrypt to be selected explicitly · 91bfcdb0
      由 Daniel P. Berrange 提交于 
      Currently the choice of whether to use nettle or gcrypt is
made based on what gnutls is linked to. There are times
when it is desirable to be able to force build against a
specific library. For example, if testing changes to QEMU's
crypto code all 3 possible backends need to be checked
regardless of what the local gnutls uses.

It is also desirable to be able to enable nettle/gcrypt
for cipher/hash algorithms, without enabling gnutls
for TLS support.

This gives two new configure flags, which allow the
following possibilities

Automatically determine nettle vs gcrypt from what
gnutls links to (recommended to minimize number of
crypto libraries linked to)

 ./configure

Automatically determine nettle vs gcrypt based on
which is installed

 ./configure --disable-gnutls

Force use of nettle

 ./configure --enable-nettle

Force use of gcrypt

 ./configure --enable-gcrypt

Force use of built-in AES & crippled-DES

 ./configure --disable-nettle --disable-gcrypt
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      91bfcdb0
  55. 22 10月, 2015 1 次提交
  57. 20 10月, 2015 1 次提交
    • M
      build: qemu-ga: add 'qemu-ga' build target for w32 · fafcaf1d
      由 Michael Roth 提交于 
      Currently POSIX builds rely on 'qemu-ga' target to do qga-only
distributable build. On w32, as with most standalone binary targets,
we rely on 'qemu-ga.exe' target.

Unlike with POSIX, qemu-ga for w32 has a number of related targets
such as VSS DLL and MSI package. We can do the full distributable
qga-only build on w32 with:

  make qemu-ga.exe

or:

  make msi

To make that work, we tie VSS dependencies onto qemu-ga.exe.
However, in reality the DLL isn't part of the binary, so we use a
filter to pull them out of the LINK recipe, which attempts to link
against prereqs for binary targets. Additionally, it could be argued
that VSS is a separate distributable, and shouldn't be implied by
qemu-ga.exe binary target.

To avoid this, we can tie the VSS dependencies only to the 'msi'
target, but that would make it impossible to do a qga-only build of
the w32 distributable without building the 'msi' package, which was
supported in the past.

An alternative approach is to add a new target to build the whole
distributable. w32 allows us to use the same build target we use
on POSIX, 'qemu-ga', since the current binary-only target on w32
is 'qemu-ga.exe'.

To further simplify the build, we also make 'qemu-ga' build the MSI
package if the appropriate ./configure options are set, making the
full qga-only build the same on both POSIX and w32: `make qemu-ga`

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
      fafcaf1d
  59. 13 10月, 2015 1 次提交
  61. 08 10月, 2015 2 次提交