Commit graph

431 commits

Author SHA1 Message Date
Alexandre Bouvier
c74b5f9ee6 cmake: use vulkan-headers config file 2024-02-02 04:38:56 +01:00
Alexandre Bouvier
73e7a259fd cmake: prefer system oaknut library 2024-01-30 02:57:50 +01:00
Mike Lothian
f854ffd015 Add Vulkan-Utility-Libraries dependency 2024-01-22 01:30:44 +00:00
Jan Beich
ecfba79d98 externals: update Vulkan-Headers to v1.3.274 2023-12-20 01:13:09 +01:00
Liam
7239547ead android: add oboe audio sink 2023-12-17 01:42:59 -05:00
Alexandre Bouvier
d2bb9e9729 cmake: prefer system gamemode library 2023-11-30 16:54:00 +01:00
liamwhite
57a391e71d
Merge pull request from GPUCode/yuwu-on-the-metal
Implement Native Code Execution (NCE)
2023-11-30 09:20:55 -05:00
amazingfate
a76a8fb5fe qt: add cpu_backend configuration 2023-11-26 20:44:07 -05:00
Alexandre Bouvier
fe3702223f cmake: prefer system simpleini library 2023-11-26 03:45:10 +01:00
t895
da14c7b8e4 config: Unify config handling under frontend_common
Replaces every way of handling config for each frontend with SimpleIni. frontend_common's Config class is at the center where it saves and loads all of the cross-platform settings and provides a set of pure virtual functions for platform specific settings.

As a result of making config handling platform specific, several parts had to be moved to each platform's own config class or to other parts. Default keys were put in platform specific config classes and translatable strings for Qt were moved to shared_translation. Default hotkeys, default_theme, window geometry, and qt metatypes were moved to uisettings. Additionally, to reduce dependence on Qt, QStrings were converted to std::strings where applicable.
2023-11-21 01:58:13 -05:00
liamwhite
eec3d356b6
Merge pull request from liamwhite/breakpad
qt: implement automatic crash dump support
2023-10-29 23:41:13 -04:00
Alexandre Bouvier
79ba5d9c26 cmake: prefer system stb headers 2023-10-25 21:47:32 +02:00
Nguyen Marc
b1a7bbd458
qt: add network components when using discord 2023-10-14 01:01:02 +02:00
Charles Lombardo
3aa6d4d8ce android: Allow ANDROID_STL 2023-10-13 12:55:41 -04:00
Charles Lombardo
2c3281c66b externals: Update LLVM to 17.0.2
Matches android ndk
2023-10-13 12:55:41 -04:00
Charles Lombardo
1591923f91 android: Update ndk to 26.1.10909125
The new ndk uses LLVM 17.0.2 so we can remove the LLVM download and libc++ options for the android builds
2023-10-13 12:55:41 -04:00
Liam
d3997bad9b qt: implement automatic crash dump support 2023-10-08 11:35:53 -04:00
Alexandre Bouvier
f93f31f4ae cmake: prefer system renderdoc header 2023-09-18 18:35:20 +02:00
liamwhite
ce5320c49f
Merge pull request from xcfrg/portable-compile-out
common: add a compile time option to allow disabling portable mode
2023-09-12 09:17:50 -04:00
GPUCode
254b2bd9df cmake: Add option to fetch validation layer binary on android 2023-09-08 23:13:52 +03:00
xcfrg
a02d641042
add a compile time option to allow disabling portable mode 2023-09-06 18:53:39 -04:00
german77
4077ff6851 externals: Update SDL to 2.28.2 2023-08-27 21:08:28 -06:00
Feng Chen
87022a4833 Add macos moltenvk bundle, Add copy moltevk dylib script 2023-08-22 10:22:28 +08:00
lat9nq
43920aa1a0 cmake: Download nasm from our external repo
This package download has intermittent failures due to host Internet
issues (presumably), so download it ourselves from our own hosting.
2023-07-25 15:47:44 -04:00
lat9nq
c1e57ad358 CMake: Require LLVM 17 or later
API changes necessitate an update here.
2023-07-18 22:39:13 -04:00
liamwhite
5593bed08a
Merge pull request from abouvier/cmake-vma
cmake: allow using system VMA library
2023-07-17 10:42:41 -04:00
liamwhite
2461c78e3f
Merge pull request from comex/ssl
Implement SSL service
2023-07-16 16:56:47 -04:00
Alexandre Bouvier
c3050c1b48 cmake: allow using system VMA library 2023-07-12 04:51:45 +02:00
Morph
e3937fe8ad general: Update VulkanSDK and Vulkan-Headers
Latest as of this commit
2023-07-07 02:04:13 -04:00
ChaseKnowlden
0792139a5f externals: Update sdl2 to 2.28.1 2023-07-04 16:10:49 -04:00
comex
0e191c2711 Updates:
- Address PR feedback.
- Add SecureTransport backend for macOS.
2023-07-01 17:27:35 -07:00
comex
98685d48e3 Merge remote-tracking branch 'origin/master' into ssl 2023-07-01 15:01:11 -07:00
comex
8b9c077826 Disable OpenSSL on Android.
Apparently Android uses BoringSSL, but doesn't actually expose headers
for it in the NDK.
2023-06-25 17:36:51 -07:00
comex
4a35569921 Fixes:
- Add missing virtual destructor on `SSLBackend`.

- On Windows, filter out `POLLWRBAND` (one of the new flags added) when
  calling `WSAPoll`, because despite the constant being defined on
  Windows, passing it calls `WSAPoll` to yield `EINVAL`.

- Reduce OpenSSL version requirement to satisfy CI; I haven't tested
  whether it actually builds (or runs) against 1.1.1, but if not, I'll
  figure it out.

- Change an instance of memcpy to memmove, even though the arguments
  cannot overlap, to avoid a [strange GCC
  error](https://github.com/yuzu-emu/yuzu/pull/10912#issuecomment-1606283351).
2023-06-25 15:06:52 -07:00
comex
8e703e08df Implement SSL service
This implements some missing network APIs including a large chunk of the SSL
service, enough for Mario Maker (with an appropriate mod applied) to connect to
the fan server [Open Course World](https://opencourse.world/).

Connecting to first-party servers is out of scope of this PR and is a
minefield I'd rather not step into.

 ## TLS

TLS is implemented with multiple backends depending on the system's 'native'
TLS library.  Currently there are two backends: Schannel for Windows, and
OpenSSL for Linux.  (In reality Linux is a bit of a free-for-all where there's
no one 'native' library, but OpenSSL is the closest it gets.)  On macOS the
'native' library is SecureTransport but that isn't implemented in this PR.
(Instead, all non-Windows OSes will use OpenSSL unless disabled with
`-DENABLE_OPENSSL=OFF`.)

Why have multiple backends instead of just using a single library, especially
given that Yuzu already embeds mbedtls for cryptographic algorithms?  Well, I
tried implementing this on mbedtls first, but the problem is TLS policies -
mainly trusted certificate policies, and to a lesser extent trusted algorithms,
SSL versions, etc.

...In practice, the chance that someone is going to conduct a man-in-the-middle
attack on a third-party game server is pretty low, but I'm a security nerd so I
like to do the right security things.

My base assumption is that we want to use the host system's TLS policies.  An
alternative would be to more closely emulate the Switch's TLS implementation
(which is based on NSS).  But for one thing, I don't feel like reverse
engineering it.  And I'd argue that for third-party servers such as Open Course
World, it's theoretically preferable to use the system's policies rather than
the Switch's, for two reasons

1. Someday the Switch will stop being updated, and the trusted cert list,
   algorithms, etc. will start to go stale, but users will still want to
   connect to third-party servers, and there's no reason they shouldn't have
   up-to-date security when doing so.  At that point, homebrew users on actual
   hardware may patch the TLS implementation, but for emulators it's simpler to
   just use the host's stack.

2. Also, it's good to respect any custom certificate policies the user may have
   added systemwide.  For example, they may have added custom trusted CAs in
   order to use TLS debugging tools or pass through corporate MitM middleboxes.
   Or they may have removed some CAs that are normally trusted out of paranoia.

Note that this policy wouldn't work as-is for connecting to first-party
servers, because some of them serve certificates based on Nintendo's own CA
rather than a publicly trusted one.  However, this could probably be solved
easily by using appropriate APIs to adding Nintendo's CA as an alternate
trusted cert for Yuzu's connections.  That is not implemented in this PR
because, again, first-party servers are out of scope.

(If anything I'd rather have an option to _block_ connections to Nintendo
servers, but that's not implemented here.)

To use the host's TLS policies, there are three theoretical options:

a) Import the host's trusted certificate list into a cross-platform TLS
   library (presumably mbedtls).

b) Use the native TLS library to verify certificates but use a cross-platform
   TLS library for everything else.

c) Use the native TLS library for everything.

Two problems with option a).  First, importing the trusted certificate list at
minimum requires a bunch of platform-specific code, which mbedtls does not have
built in.  Interestingly, OpenSSL recently gained the ability to import the
Windows certificate trust store... but that leads to the second problem, which
is that a list of trusted certificates is [not expressive
enough](https://bugs.archlinux.org/task/41909) to express a modern certificate
trust policy.  For example, Windows has the concept of [explicitly distrusted
certificates](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn265983(v=ws.11)),
and macOS requires Certificate Transparency validation for some certificates
with complex rules for when it's required.

Option b) (using native library just to verify certs) is probably feasible, but
it would miss aspects of TLS policy other than trusted certs (like allowed
algorithms), and in any case it might well require writing more code, not less,
compared to using the native library for everything.

So I ended up at option c), using the native library for everything.

What I'd *really* prefer would be to use a third-party library that does option
c) for me.  Rust has a good library for this,
[native-tls](https://docs.rs/native-tls/latest/native_tls/).  I did search, but
I couldn't find a good option in the C or C++ ecosystem, at least not any that
wasn't part of some much larger framework.  I was surprised - isn't this a
pretty common use case?  Well, many applications only need TLS for HTTPS, and they can
use libcurl, which has a TLS abstraction layer internally but doesn't expose
it.  Other applications only support a single TLS library, or use one of the
aforementioned larger frameworks, or are platform-specific to begin with, or of
course are written in a non-C/C++ language, most of which have some canonical
choice for TLS.  But there are also many applications that have a set of TLS
backends just like this; it's just that nobody has gone ahead and abstracted
the pattern into a library, at least not a widespread one.

Amusingly, there is one TLS abstraction layer that Yuzu already bundles: the
one in ffmpeg.  But it is missing some features that would be needed to use it
here (like reusing an existing socket rather than managing the socket itself).
Though, that does mean that the wiki's build instructions for Linux (and macOS
for some reason?) already recommend installing OpenSSL, so no need to update
those.

 ## Other APIs implemented

- Sockets:
    - GetSockOpt(`SO_ERROR`)
    - SetSockOpt(`SO_NOSIGPIPE`) (stub, I have no idea what this does on Switch)
    - `DuplicateSocket` (because the SSL sysmodule calls it internally)
    - More `PollEvents` values

- NSD:
    - `Resolve` and `ResolveEx` (stub, good enough for Open Course World and
      probably most third-party servers, but not first-party)

- SFDNSRES:
    - `GetHostByNameRequest` and `GetHostByNameRequestWithOptions`
    - `ResolverSetOptionRequest` (stub)

 ## Fixes

- Parts of the socket code were previously allocating a `sockaddr` object on
  the stack when calling functions that take a `sockaddr*` (e.g. `accept`).
  This might seem like the right thing to do to avoid illegal aliasing, but in
  fact `sockaddr` is not guaranteed to be large enough to hold any particular
  type of address, only the header.  This worked in practice because in
  practice `sockaddr` is the same size as `sockaddr_in`, but it's not how the
  API is meant to be used.  I changed this to allocate an `sockaddr_in` on the
  stack and `reinterpret_cast` it.  I could try to do something cleverer with
  `aligned_storage`, but casting is the idiomatic way to use these particular
  APIs, so it's really the system's responsibility to avoid any aliasing
  issues.

- I rewrote most of the `GetAddrInfoRequest[WithOptions]` implementation.  The
  old implementation invoked the host's getaddrinfo directly from sfdnsres.cpp,
  and directly passed through the host's socket type, protocol, etc. values
  rather than looking up the corresponding constants on the Switch.  To be
  fair, these constants don't tend to actually vary across systems, but
  still... I added a wrapper for `getaddrinfo` in
  `internal_network/network.cpp` similar to the ones for other socket APIs, and
  changed the `GetAddrInfoRequest` implementation to use it.  While I was at
  it, I rewrote the serialization to use the same approach I used to implement
  `GetHostByNameRequest`, because it reduces the number of size calculations.
  While doing so I removed `AF_INET6` support because the Switch doesn't
  support IPv6; it might be nice to support IPv6 anyway, but that would have to
  apply to all of the socket APIs.

  I also corrected the IPC wrappers for `GetAddrInfoRequest` and
  `GetAddrInfoRequestWithOptions` based on reverse engineering and hardware
  testing.  Every call to `GetAddrInfoRequestWithOptions` returns *four*
  different error codes (IPC status, getaddrinfo error code, netdb error code,
  and errno), and `GetAddrInfoRequest` returns three of those but in a
  different order, and it doesn't really matter but the existing implementation
  was a bit off, as I discovered while testing `GetHostByNameRequest`.

  - The new serialization code is based on two simple helper functions:

    ```cpp
    template <typename T> static void Append(std::vector<u8>& vec, T t);
    void AppendNulTerminated(std::vector<u8>& vec, std::string_view str);
    ```

    I was thinking there must be existing functions somewhere that assist with
    serialization/deserialization of binary data, but all I could find was the
    helper methods in `IOFile` and `HLERequestContext`, not anything that could
    be used with a generic byte buffer.  If I'm not missing something, then
    maybe I should move the above functions to a new header in `common`...
    right now they're just sitting in `sfdnsres.cpp` where they're used.

- Not a fix, but `SocketBase::Recv`/`Send` is changed to use `std::span<u8>`
  rather than `std::vector<u8>&` to avoid needing to copy the data to/from a
  vector when those methods are called from the TLS implementation.
2023-06-25 12:53:31 -07:00
Narr the Reg
106b61b1e0 externals: Update sdl to 2.28.0 2023-06-21 17:11:14 -06:00
lat9nq
e9701a3cda cmake: Add option to always download time zone data 2023-06-16 04:32:31 -04:00
Morph
f62f43c0da CMakeLists: Force C++20 on MSVC due to conflicts with C++23 modules
The latest version of MSVC STL brings C++23 standard library modules, which conflict with precompiled headers.
Disabling with /experimental:module- has no effect, so force C++20 in the meantime while we wait for module support in other compilers.
2023-06-06 20:20:09 -04:00
bunnei
296ccb698d android: cmake: Use cmake_dependent_option as appropriate. 2023-06-03 00:14:33 -07:00
Liam
616cf70a80 build: only enable adrenotools on arm64 2023-06-03 00:05:43 -07:00
liushuyu
19eec22b38 CMake: fix pkg-config behavior when building for Android 2023-06-03 00:05:33 -07:00
bunnei
5de8ee7bba cmake: Integrate submoduled LLVM & fixes for Android. 2023-06-03 00:05:26 -07:00
Danila Malyutin
7701a00a02 Add support for deinterlaced videos playback
This is a follow up to  to improve the playback of cut scenes in Layton's Mystery Journey.
It uses ffmpeg's yadif filter for deinterlacing.
2023-05-22 01:43:44 +04:00
Jan Beich
083d913eab externals: update Vulkan-Headers to v1.3.246 2023-04-01 05:38:54 +00:00
Morph
c4f5615c6b CMakeLists: Require a minimum of boost 1.79.0 2023-03-25 23:03:28 -04:00
Morph
877e8991c7 CMakeLists: Update boost to 1.81.0 2023-03-23 20:53:39 -04:00
Liam
600f325d87 general: fix spelling mistakes 2023-03-12 11:33:01 -04:00
Morph
3453beb1e0 general: Target Windows 10 SDK
We no longer support operating systems below Windows 10.
2023-03-05 02:36:31 -05:00
liamwhite
1346b14bef
Merge pull request from abouvier/cmake-boost
cmake: use correct boost imported targets
2023-02-28 18:40:44 -05:00
Alexandre Bouvier
57fd8b1f45 cmake: use correct boost imported targets 2023-02-28 17:56:01 +01:00