Commit graph

24715 commits

Author SHA1 Message Date
liamwhite
02882d9251
Merge pull request #10925 from t895/fs-agony
android: Fix size check for content uris
2023-06-26 23:33:51 -04:00
Charles Lombardo
9074a70b01 android: Fix size check for content uris
Fix for checking file size for android content uris
2023-06-26 22:24:18 -04:00
liamwhite
2ed8b3cbb9
Merge pull request #10908 from kiri11/clarify-ring-ui
Clarify Ring-Con configuration message in UI
2023-06-26 14:31:30 -04:00
liamwhite
b82c649b0f
Merge pull request #10903 from german77/nfc_state
input_common: Improve nfc state handling and 3rd party support
2023-06-26 14:31:23 -04:00
liamwhite
ce990adae5
Merge pull request #10901 from german77/sdl_fix
input_common: Make use of new SDL features
2023-06-26 14:31:14 -04:00
liamwhite
c280a2fe1c
Merge pull request #10894 from lat9nq/bsd-tzdb
nx_tzdb: Update tzdb_to_nx
2023-06-26 14:31:07 -04:00
liamwhite
28df6ac0aa
Merge pull request #10888 from 8bitDream/native
android: (native) Parameter types from Android Studio
2023-06-26 14:31:00 -04:00
liamwhite
0030fa9721
Merge pull request #10865 from t895/extension-meme
android: Clean up file extension checks
2023-06-26 14:30:49 -04:00
Charles Lombardo
0f31039831 android: Clean up file extension checks 2023-06-26 13:25:56 -04:00
GPUCode
b6c6dcc576 externals: Use cmake subdirectory 2023-06-26 18:59:24 +03:00
Kelebek1
ffbaf574ca Use safe reads in DMA engine 2023-06-26 11:34:02 +01:00
comex
d885dd5b64 PR feedback + constification 2023-06-25 19:24:49 -07:00
comex
b9f9d0a642 network.cpp: include expected.h 2023-06-25 18:51:39 -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
cd4b8f037c re-format 2023-06-25 17:09:54 -07:00
comex
ac939f08a4 Fix more Windows build errors
I did test this beforehand, but not on MinGW, and the error that showed
up on the msvc builder didn't happen for me...
2023-06-25 17:06:57 -07:00
comex
42015de49b ssl: fix compatibility with OpenSSL 1.1.1
Turns out changes were needed after all.
2023-06-25 16:09:16 -07:00
ameerj
4f160633d3 OpenGL: Limit lmem warmup to NVIDIA
🐸
2023-06-25 19:06:51 -04:00
ameerj
405eae3734 shaders: Track local memory usage 2023-06-25 18:59:33 -04:00
ameerj
b198339580 emit_glasm: Fix lmem size computation 2023-06-25 18:43:52 -04:00
ameerj
82107b33a2 OpenGL: Add Local Memory warmup shader 2023-06-25 18:43:23 -04: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
lat9nq
f5569bfed9 nx_tzdb: Update tzdb_to_nx to 212afa2
Moves build data to a separate directory so the build happens out of the source
tree.
2023-06-25 17:20:18 -04:00
comex
8905142f43 ssl: rename argument to avoid false positive codespell warning
The original name `larg` was copied from the OpenSSL documentation and
is not a typo of 'large' but rather an abbreviation of '`long`
argument'.  But whatever, no harm in adding an underscore.
2023-06-25 13:10:41 -07:00
comex
7cc428ddf6 socket_types: Improve comment 2023-06-25 13:10:15 -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
Kirill Ignatev
b6e89bdf2c
Hyphenate Joy-Con and clarify further 2023-06-25 12:51:16 -04:00
Kirill Ignatev
b6025cf62f
Clarify Ring-Con configuration message in UI
Not obvious how left controller should be set up
Mention that it should be left physical dual emulated
2023-06-25 11:52:15 -04:00
german77
bf641e2964 core: hid: Allow to read bin files while switch controller is available 2023-06-24 18:59:55 -06:00
german77
5aa208e264 input_common: Dont try to read/write data from 3rd party controllers 2023-06-24 18:59:55 -06:00
german77
ec9a71b12a externals: Include player led fix on SDL 2023-06-24 17:43:08 -06:00
german77
474fa13a1a input_common: Make use of new SDL features 2023-06-24 17:42:56 -06:00
zeltermann
482fbded9b Only use SDL wakelock on Linux
SDL has internally fixed shenanigans related to wakelocking through DBus
from inside sandboxes from around August 2022, so we can now remove the
workaround we used since 2021.
2023-06-24 14:51:41 +07:00
lat9nq
e5769e9467 nx_tzdb: Update tzdb_to_nx
Includes fixes for other BSD's, and axes shell scripts for pure CMake.
2023-06-23 19:07:26 -04:00
Morph
3a991f3aef
Merge pull request #10891 from german77/sdl28v2
externals: Include post release SDL fixes
2023-06-23 17:41:54 -04:00
Narr the Reg
142c1b72f9 externals: Include post release SDL fixes 2023-06-23 12:25:47 -06:00
Abandoned Cart
b53945a99f android: define [[maybe_unused]] (const) auto 2023-06-23 14:05:14 -04:00
Abandoned Cart
a58a1403ba android: Parameter types from Android Studio
Android Studio marked these parameters as errors because it is an instance, not a class, that is being passed from Java.
2023-06-23 10:36:30 -04:00
liamwhite
5ab4aa1edb
Merge pull request #10811 from 8bitDream/pip_mute
android: Add a PiP interface to mute / unmute
2023-06-23 09:27:28 -04:00
liamwhite
a674022434
Merge pull request #10859 from liamwhite/no-more-atomic-wait
general: remove atomic signal and wait
2023-06-23 09:27:14 -04:00
liamwhite
87b9b5d10f
Merge pull request #10842 from german77/native_mifare
input_common: Implement native mifare/skylander support for joycons/pro controller
2023-06-23 09:27:00 -04:00
liamwhite
575d467d95
Merge pull request #10884 from liamwhite/spaghetti-vfs
vfs_real: lock concurrent accesses
2023-06-23 09:26:48 -04:00
Liam
1dd166f766 vfs_real: lock concurrent accesses 2023-06-23 00:57:24 -04:00
bunnei
2fc5dedf69
Merge pull request #10457 from Kelebek1/optimise
Remove memory allocations in some hot paths
2023-06-22 21:53:07 -07:00
bunnei
3f3e4efb30
Merge pull request #10806 from liamwhite/worst-fs-implementation-ever
vfs_real: misc optimizations
2023-06-22 21:46:50 -07:00
bunnei
5558fc4aa5
Merge pull request #10794 from 8bitDream/multiples
android: Add support for multiple installs
2023-06-22 14:26:24 -07:00
Morph
7f12c6159f
Merge pull request #10878 from GPUCode/log-droid
android: Log settings
2023-06-22 16:16:20 -04:00
bunnei
8e9c6429b0
Merge pull request #10873 from german77/sdl
externals: Update sdl to 2.28.0
2023-06-22 10:27:01 -07:00
bunnei
dfa0e9479d
Merge pull request #10869 from 8bitDream/memory
android: Add a notice when RAM inadequate
2023-06-22 10:26:32 -07:00
GPUCode
c133509368 android: Log settings 2023-06-22 20:17:52 +03:00