1. 26 Jun, 2023 2 commits
    • comex's avatar
      re-format · cd4b8f03
      comex authored
      cd4b8f03
    • comex's avatar
      Fix more Windows build errors · ac939f08
      comex authored
      I did test this beforehand, but not on MinGW, and the error that showed
      up on the msvc builder didn't happen for me...
      ac939f08
  2. 25 Jun, 2023 5 commits
    • comex's avatar
      ssl: fix compatibility with OpenSSL 1.1.1 · 42015de4
      comex authored
      Turns out changes were needed after all.
      42015de4
    • comex's avatar
      Fixes: · 4a355699
      comex authored
      - 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).
      4a355699
    • comex's avatar
      ssl: rename argument to avoid false positive codespell warning · 8905142f
      comex authored
      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.
      8905142f
    • comex's avatar
      socket_types: Improve comment · 7cc428dd
      comex authored
      7cc428dd
    • comex's avatar
      Implement SSL service · 8e703e08
      comex authored
      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.
      8e703e08
  3. 18 Jun, 2023 12 commits
  4. 17 Jun, 2023 6 commits
  5. 16 Jun, 2023 15 commits