Commit graph

809 commits

Author SHA1 Message Date
Narr the Reg
1f0a03d1e0 service: hid: Implement NpadResource and NpadData 2024-01-03 20:21:14 -06:00
liamwhite
5ff67edd66 Merge pull request #12536 from german77/npad_interface
service: hid: Use applet resource to get latest shared memory handle
2024-01-01 15:02:13 -05:00
Narr the Reg
5dbd02ebb1 Merge pull request #12466 from liamwhite/sh2
core: track separate heap allocation for linux
2024-01-01 13:56:16 -06:00
Narr the Reg
37bb42e1ec service: hid: Use applet resource to get latest shared memory handle 2023-12-31 10:51:01 -06:00
Liam
208438868e jit: use code memory handles correctly 2023-12-29 01:07:47 -05:00
Liam
c366d8e8d9 core: track separate heap allocation for linux 2023-12-25 23:30:56 -05:00
liamwhite
a871e2fd99 Merge pull request #12184 from Kelebek1/system_settings
Make system settings persistent across boots
2023-12-16 11:47:52 -05:00
liamwhite
21512172f3 Merge pull request #12237 from liamwhite/nce-sigtrap
nce: implement instruction emulation for misaligned memory accesses
2023-12-16 11:47:35 -05:00
Kelebek1
9dc9e91e2a Make system settings persistent across boots 2023-12-16 06:01:54 +00:00
Narr the Reg
6de39c8398 service: hid: Allow to create multiple instances of shared memory 2023-12-13 23:24:28 -06:00
Liam
ecb3d74dcd nce: implement instruction emulation for misaligned memory accesses 2023-12-10 18:23:42 -05:00
liamwhite
7d3fe08d79 Merge pull request #12321 from liamwhite/ro2
ro: add separate ro service
2023-12-10 18:16:50 -05:00
liamwhite
81602e8ba5 Merge pull request #12299 from liamwhite/light-ipc
kernel: implement light IPC
2023-12-09 19:03:50 -05:00
Liam
88c44ff95d ro: add separate ro service 2023-12-09 15:50:34 -05:00
liamwhite
c673c3d019 Merge pull request #12289 from german77/aruid
service: hid: Introduce proper AppletResource emulation
2023-12-09 13:41:06 -05:00
Liam
f486fe3971 kernel: implement light IPC 2023-12-07 09:13:43 -05:00
Narr the Reg
7fa71afe9e service: hid: Introduce proper AppletResource emulation 2023-12-06 20:24:04 -06:00
Liam
3d5c6a73cb core: refactor emulated cpu core activation 2023-12-04 10:37:16 -05:00
GPUCode
e6e15d2d10 core: Rename patcher file 2023-11-29 23:49:16 +02:00
amazingfate
c95a560bc3 qt: add cpu_backend configuration 2023-11-26 20:44:07 -05:00
GPUCode
3930e3d7fd core: Define HAS_NCE macro 2023-11-25 00:47:36 -05:00
Liam
19619b1b14 arm: Implement native code execution backend 2023-11-25 00:46:47 -05:00
Narr the Reg
5f6b4418df service: hid: Create appropriate hid resources 2023-11-20 17:19:17 -06:00
liamwhite
8a84cfff20 Merge pull request #11912 from liamwhite/nv-graphic-buffer
nvnflinger: use graphic buffer lifetime for map handle
2023-11-17 20:41:34 -05:00
Narr the Reg
cd8dcc1250 service: hid: Introduce firmware settings and update activate controller calls 2023-11-16 18:51:14 -06:00
Narr the Reg
174c52d27b service: hid: Split hid.cpp into individual interfaces 2023-11-15 09:59:54 -06:00
Liam
713f292a25 kernel: add KPageTableBase
Co-authored-by: Kelebek1 <eeeedddccc@hotmail.co.uk>
2023-11-10 12:01:35 -05:00
Liam
2e8b7e4a40 nvnflinger: use graphic buffer lifetime for map handle 2023-10-29 22:12:16 -04:00
Narr the Reg
ab5db1da9f service: caps: Implement album manager and reorganize service 2023-10-07 20:57:20 -06:00
Narr the Reg
9567f9aaed service: nvnflinger: Implement shared buffer
Co-authored-by: Liam <byteslice@airmail.cc>
2023-10-01 11:38:30 -06:00
liamwhite
253a6aeb54 Merge pull request #11526 from german77/mii_service_v2
service: mii: Update implementation Part2 - Mii database support
2023-09-19 09:24:49 -04:00
Alexandre Bouvier
6c2231980f cmake: prefer system renderdoc header 2023-09-18 18:35:20 +02:00
german77
854dbcc479 service: mii: Implement database manager 2023-09-17 16:06:25 -06:00
german77
89da19cd99 service: mii: Implement figurine database 2023-09-17 16:06:25 -06:00
Kelebek1
07b63b15ad Reimplement HardwareOpus 2023-09-16 11:56:25 -04:00
GPUCode
cc2c6d8805 debug: Add renderdoc capture hotkey 2023-09-14 16:37:41 +03:00
Liam
08191b07e3 ngc: implement service 2023-09-14 09:14:08 -04:00
german77
e51d54de30 service: mii: separate mii types into their own file 2023-09-10 22:18:25 -06:00
german77
e05834e9c4 service: mii: Add mii util and result 2023-09-10 20:43:26 -06:00
Liam
5e3139e7c6 vfs: expand support for NCA reading 2023-08-15 17:47:25 -04:00
Morph
0263d2fb05 ssl: Link with crypt32 for secure channel backend 2023-07-17 15:46:24 -04:00
liamwhite
b05ad55c4c Merge pull request #10912 from comex/ssl
Implement SSL service
2023-07-16 16:56:47 -04:00
Liam
ac90cfb927 k_server_session: translate special header for non-HLE requests 2023-07-08 01:01:49 -04:00
comex
f4b39f722d Updates:
- Address PR feedback.
- Add SecureTransport backend for macOS.
2023-07-01 17:27:35 -07:00
comex
3b997a6083 Merge remote-tracking branch 'origin/master' into ssl 2023-07-01 15:01:11 -07:00
comex
742d780d77 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
6f8d5f068f 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
bunnei
72a469b967 Merge pull request #10086 from Morph1984/coretiming-ng-1
core_timing: Use CNTPCT as the guest CPU tick
2023-06-21 21:12:46 -07:00
bunnei
4abd6e552c Merge pull request #10603 from lat9nq/tz-more-complete
core,common: Implement missing time zone data/computations
2023-06-13 13:28:45 -07:00
Liam
5b858c8306 core: decouple ARM interface from Dynarmic 2023-06-12 22:11:51 -04:00