summaryrefslogtreecommitdiffstats
path: root/src/corelib/plugin/qmachparser.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Mark qtbase/src/corelib/plugin files as security-criticalMagdalena Stojek2025-06-041-0/+1
| | | | | | | | | | | | | | | - quuid.cpp parses the string representation of a UUID - qfactoryloader.cpp parses metadata from loaded plugin - qcoffpeparser.cpp, qelfparser_p.cpp and qmachparser.cpp as they are binary object files parsers - qlibrary.cpp, qlibrary_unix.cpp, qlibrary_win.cpp, qpluginloader.cpp are responsible for finding and loading plugins from untrusted locations. Fixes: QTBUG-135193 Change-Id: Ibbcefeab80e7455225ade620bdba45dbc592c581 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Matthias Rauter <matthias.rauter@qt.io>
* Darwin: Ensure encrypted library is loaded before parsing plugin metadataTor Arne Vestbø2023-02-171-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Application delivered via the macOS or iOS App Store might have their libraries encrypted, in which case we can not read any of the sections of the binary until it has been dlopened. This was causing issues for our plugin loading code, which assumed we could read the .qtmetadata section of a yet to be loaded plugin to determine its suitability, before loading it. We now detect whether a library is encrypted during the Mach-O parsing, and propagate this back to QLibraryPrivate::updatePluginState(), which can handle the case by explicitly loading the library before continuing with metadata validation. We still ensure that the library has a .qtmetadata section, so that we don't need to dlopen any random library in our path. This does mean that we will potentially load more plugins than we need, and since the Qt version validation happens as part of meta data validation, we might dlopen() incompatible plugins, but it's expected that in an App Store deployment scenario you control both the versioning and set of shipped plugins, so this should not be an issue in practice. As encrypted libraries are only produced for apps that are fully published to the App Store, and then deployed via MDM, VPP, or Apple Configurator 2, we don't have an easy way to test this, but the existing code paths should be unaffected, and hopefully this patch improves the situation for the encrypted library case. Pick-to: 6.5 6.4 6.2 5.15 Change-Id: Iff733505f7067ce5571854ea978bc95e8376e347 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-38/+2
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* QtCore: replace QLatin1String/QLatin1Char with _L1/u'' where applicableSona Kurazyan2022-03-251-1/+4
| | | | | | | | | | | As a drive-by, did also minor refactorings/improvements. Task-number: QTBUG-98434 Change-Id: I81964176ae2f07ea63674c96f47f9c6aa046854f Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
* Q{CoffPe,Elf,MachO}Parser: check that the magic string is presentThiago Macieira2021-11-191-1/+12
| | | | | | | | | | Commit 2549a88ba2a48fa2bedce97dd71a2974c6f8840a changed the ELF and Mach-O parsers to return an offset to the actual data header, not the magic string, which we stopped searching for anyway. This commit brings such a validity check back and adds it to the new COFF PE parser. Change-Id: Iccb47e5527544b6fbd75fffd16b8b2252a76f179 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* CMake: reorganize the QT_FEATURE_library portion of CMakeLists.txtThiago Macieira2021-11-191-4/+0
| | | | | | | | No need to attempt to compile both qelfparser and qmachoparser in all systems. Change-Id: Iccb47e5527544b6fbd75fffd16b7ee5a1555a7a8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* QPlugin: pass the direct header to qJsonFromRawLibraryMetaData()Thiago Macieira2021-10-041-1/+5
| | | | | | | | This is done in preparation for storing the metadata without the magic string in static plugins and in ELF notes. Change-Id: I3eb1bd30e0124f89a052fffd16a820454dd56d3e Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QPlugin: simplify handling of exact results from Q{Elf,Mach}ParserThiago Macieira2021-10-041-2/+1
| | | | | | | | | | Those two scanners always return exact results, if the metadata is present, so we don't need to re-scan (haven't needed since Qt 5.0). Especially since we scan from the end, we were spending cycles doing unnecessary work. Change-Id: I42eb903a916645db9900fffd16a4ccfdc7342278 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Q{Elf,Mach}Parser: harmonize the arguments passedThiago Macieira2021-10-041-19/+18
| | | | | | | | | | | | | | Both functions took a QString for the input file name, but while the ELF parser had an optional QLibrary pointer (which was never null) where to store the error string, the Mach-O parser received a pointer to a QString. So make both of them take a single in/out QString pointer, which has the file name on input and is cheap for us because of COW. Drive-by fix the name of the static function in qmachparser.cpp from "ns" (which stood for "not suitable") to "notfound". Change-Id: I3eb1bd30e0124f89a052fffd16a8182f4f8541c3 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Q{Elf,Mach}Parser: simplify the return codesThiago Macieira2021-09-241-12/+8
| | | | | | | | | | | | | | | | | The multi-state return code was a legacy of how Arvid wrote the ELF parser code back in the day, the fact that it scanned for two different types of plugins in Qt 4 and that the metadata could exist in different places. None of that matters nowadays: who cares if the file is a corrupt binary, not a valid binary, does not have the right architecture, or has no suitable section? It's not a plugin, period. The Qt 4 plugin mechanism was removed for Qt 5.0 in commit 7443895857fdaee132c8efc643e471f02b3d0fa4 ("Remove support for Qt 4 style plugins"). Change-Id: I42eb903a916645db9900fffd16a442d800399b98 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* Another round of replacing 0 with nullptrAllan Sandfeld Jensen2020-10-071-1/+1
| | | | | | | | | This time based on grepping to also include documentation, tests and examples previously missed by the automatic tool. Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* QPluginLoader: limit the amount of memory used when scanning pluginsThiago Macieira2018-07-141-1/+1
| | | | | | | | | | | | | | | | | | | When using actual memory allocation, limit to 64 MB, not the full file size. On most systems, the memory map technique will work, so this won't even be tried. In any case, we don't need the fix for the OOM situation that was applied in commit e211ab76d766878b4dbe88901b9a7a4a70ce7332. As for the memory mapping technique, this commit limits the allocation to reasonable values given the virtual memory addressing space. Half a gigabyte is probably acceptable on 32-bit systems, where there should be a contiguous space for the OS to allocate the file in. This commit also fixes an overflow when converting from qint64 of the file size to ulong (32-bit on 32-bit platforms and on Windows). For 64-bit systems, we currently limit to 1 TB. Change-Id: I117816bf0f5e469b8d34fffd153dc1705a8eedc4 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Use QT_CONFIG(library) instead of QT_NO_LIBRARYUlf Hermann2017-03-061-1/+1
| | | | | | | | | | | | | For the windows file system engine, we add an extra macro to use library loading if configured to do so, but avoid it on WinRT, as none of the symbols would be found. We also QT_REQUIRE_CONFIG(library) in the library headers and exclude the sources from the build if library loading is disabled. This, in turn, makes it necessary to clean up some header inclusions. Change-Id: I2b152cb5b47a2658996b6f4702b038536a5704ec Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* Fix unimplemented Mach-O parsing for ARM64 platforms in QPluginLoader.Jake Petroules2016-05-301-0/+3
| | | | | Change-Id: I4853b5ce1691bd84578ebe46af9f73270598387a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Update the Intel copyright yearThiago Macieira2016-01-211-1/+1
| | | | | | | | | Not that we require it, but since The Qt Company did it for all files they have copyright, even if they haven't touched the file in years (especially not in 2016), I'm doing the same. Change-Id: I7a9e11d7b64a4cc78e24ffff142b4c9d53039846 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Updated license headersJani Heikkinen2016-01-151-13/+19
| | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new LGPL header instead of LGPL21 one (in those files which will be under LGPL v3) Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Update copyright headersJani Heikkinen2015-02-111-6/+6
| | | | | | | | | | | | | | | | | | Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Outdated header.LGPL removed (use header.LGPL21 instead) Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing combination. New header.LGPL-COMM taken in the use file which were using old header.LGPL3 (src/plugins/platforms/android/extract.cpp) Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license combination Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
* Update license headers and add new license filesMatti Paaso2014-09-241-18/+10
| | | | | | | | | - Renamed LICENSE.LGPL to LICENSE.LGPLv21 - Added LICENSE.LGPLv3 - Removed LICENSE.GPL Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2 Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
* Make the Mach-O size checking a little more robustThiago Macieira2013-07-201-20/+25
| | | | | | | | | | | | | | | | | It's not necessary to check at every point if we know the minimum file size: it must contain at least the header, one segment (__TEXT) and one section (qtmetadata). Most files have more than one segment and more than one loader command, so this check does not mean we can eliminate the checks further down. Also be more resilient against corruptions in the header data: check not only the additions, but the values themselves. For example, an offset + size addition could be smaller than the file size when the addition overflows in 32-bit. Another thing is that the cmdsize fields could be corrupt too. Change-Id: I7968a769c1cbe9150270c91823cafc4f8f833876 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Add a Mach-O decoder to the QPluginLoaderThiago Macieira2013-07-201-0/+213
We already had an ELF decoder, which helped us greatly to find the metadata and that catches most Unix systems (Solaris, QNX, HP-UXi, and all of the free Unixes). On other Unix systems, aside from Mac OS X, we simply scanned the entire file for the signature. On Windows, even without a COFF-PE decoder, we use a LoadLibrary trick to load the plugin without loading the dependent libraries. In most cases, that works. Unfortunately, on Mac OS X we didn't have a decoder and nor could we do the file scan: because Mac OS X binaries could be fat binaries, we wouldn't know which architecture's signature we had found. No more. This adds a full Mach-O decoder to QtCore. It is also capable of finding the boundaries of the architecture's binary, but that functionality is disabled since all Qt 5 plugins have plugin metadata sections. Change-Id: I2d5c04c5ecf024864b8a43f31ab6b7e6c5eae9ce Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>