The NEON SIMD fast path in the bundled llhttp calls
__builtin_ctzll(match_mask) without checking if match_mask is zero.
When all 16 bytes in a NEON register are valid header value characters,
match_mask is 0. Calling __builtin_ctzll(0) is undefined behavior.
GCC at -O2 exploits this by optimizing "if (match_len != 16)" to
always-true, causing HTTP 400 Bad Request for any header value longer
than 16 characters on ARM targets with NEON enabled.
Fix by explicitly checking for match_mask == 0 and setting
match_len = 16. This bug affects both aarch64 and armv7 NEON targets.
The code this patch modifies is generated, so the patch itself isn't
suitable for upstream submission, as the root cause of the error is
in the generator itself. The fix has been merged upstream[1] in
llparse 7.3.1 and is included in llhttp 9.3.1. This patch can be
dropped when nodejs updates its bundled llhttp to >= 9.3.1.
[1]: https://github.com/nodejs/llparse/pull/83
Signed-off-by: Telukula Jeevan Kumar Sahu <j-sahu@ti.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The llhttp vendored dependency of nodejs takes advantage of Arm NEON
instructions when they are available, however they are detected by
checking for an outdated CPU feature macro: it checks for __ARM_NEON__,
however it is not defined by new compilers for aarch64, rather they
set __ARM_NEON. The Arm C extension guide[1] refers to __ARM_NEON macro
aswell.
This patch changes the detection to check for both macros when detecting
the availability of NEON instructions.
The code this patch modifies is generated, so the patch itself isn't
suitable for upstream submission, as the root cause of the error is
in the generator itself. A PR has been submitted[2] to the generator
project to rectify this issue.
[1]: https://developer.arm.com/documentation/ihi0053/d/ - pdf, section 6.9
[2]: https://github.com/nodejs/llparse/pull/84
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The llhttp dependency of nodejs uses NEON intrinsics when they
are available, however some of these calls are incorrect: they
the call they use don't match the parameters passed, and so
the compilation fail (unless the error is suppressed):
| ../deps/llhttp/src/llhttp.c: In function 'llhttp__internal__run':
| ../deps/llhttp/src/llhttp.c:2645:9: note: use '-flax-vector-conversions' to permit conversions between vectors with differing element types or numbers of subparts
| 2645 | );
| | ^
| ../deps/llhttp/src/llhttp.c:2643:11: error: incompatible type for argument 1 of 'vandq_u16'
| 2643 | vcgeq_u8(input, vdupq_n_u8(' ')),
There is a patch upstream that fixes it (though it is not merged
yet). This patch is a port of that fix.
This allows us to remove the extra CFLAGS also from the recipe that
suppressed this error.
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This patch isn't intended to introduce new behavior, rather it
changes the order of some existing LDFLAGS to fix a workaround that
stopped working at some point in the past.
LDFLAGS:x86 contains libatomic, because linking with this library
is required for this platform.
However when gyp links, it invokes the following (pseudo-)command:
$LD $LDFLAGS $RESOURCES_TO_LINK $EXTRA_LIBS $EXTRA_LDFLAGS
The EXTRA* arguments are coming from the gyp config. Since
LDFLAGS appears very early in the command, libatomic also
appears early amongst the resources, and the linker couldn't
find the relevant symbols when compiled for x86 platform (as
it was processed the very last):
| [...] undefined reference to `__atomic_compare_exchange'
Using this patch the library appears at the end, along with
the other EXTRA_LIBS, after the list of linked resources,
allowing linking to succeed.
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
When clang is used as cross compiler, it confuses gyp
system to enable -m64 option for host pieces of build
and the reason is that it assumes clang to be biarch
by default for all architectures but that maybe true for
x86/x86_64 combo but not true for arm/aarch64 systems
This is a backport from node 24
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Brotli can crash nodejs (on ARM), because the memory allocated for
brotli wasn't properly aligned.
https://github.com/google/brotli/issues/1159dc035bbc9b
Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This moves us from the previous Long Term Support version codenamed 'Iron' to the newly
released Long Term Support version 22.11.0 Codename 'Jod'
Changelog: https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V22.md#22.11.0
License-Update:
Add amaro dependency under MIT License.
Add swc dependency under Aapche License Version 2.0.
Add simdjson dependency under Apache License Version 2.0.
Add on-exit-leak-free under MIT License.
Remove ESLint.
Remove base64 dependency.
Removed patchs:
182d9c05e78.patch - This was a backport to 20.x it is now integrated in 22.x
Added patches:
Two small patches here to use Bourne Shell instad of BASH.
0001-custom-env.patch
0001-positional-args.patch
This patch from https://github.com/nodejs/node/commit/686da19abb that addressed CVE-2024-22017
0001-deps-disable-io_uring-support-in-libuv.patch
Other patches were refreshed.
Signed-off-by: Jason Schonberg <schonm@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Drop two patches which haven't been referenced by the nodejs recipe since the
20.11.0 version checkin.
0001-build-fix-build-with-Python-3.12.patch
0001-gyp-resolve-python-3.12-issues.patch
Signed-off-by: Jason Schonberg <schonm@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
As noted in the libc++ 19 release notes [1], std::char_traits<> is now
only provided for char, char8_t, char16_t, char32_t and wchar_t, and any
instantiation for other types will fail.
This causes nodejs-20 to fail to compile with clang 19 and libc++ 19,
resulting in errors similar to:
/usr/include/c++/v1/string:820:42: error: implicit instantiation of undefined template 'std::char_traits<unsigned short>'
820 | static_assert(is_same<_CharT, typename traits_type::char_type>::value,
| ^
../deps/v8/src/inspector/string-16.h:114:28: note: in instantiation of template class 'std::basic_string<unsigned short>' requested here
114 | std::basic_string<UChar> m_impl;
| ^
/usr/include/c++/v1/__fwd/string.h:23:29: note: template is declared here
23 | struct _LIBCPP_TEMPLATE_VIS char_traits;
| ^
Upstream v8 has fixed this in commit 182d9c05e78 [2], so add it as a
backported patch, until the next version of node is released.
[1] https://libcxx.llvm.org/ReleaseNotes/19.html#deprecations-and-removals
[2] https://chromium.googlesource.com/v8/v8.git/+/182d9c05e78
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Due to the scope of supported BSPs by qemu-user is limited, such
as a segment fault on armv9 after qemu apply commit [target/arm:
Convert LDAPR/STLR (imm) to decodetree][1]
```
|tmp-glibc/work/neoversen2-crypto-wrs-linux/nodejs/20.5.1/node-v20.5.1/out/
Release/v8-qemu-wrapper.sh: line 7: 3179613 Segmentation fault (core dumped)
PSEUDO_UNLOAD=1 qemu-aarch64 -r 5.15 -L tmp-glibc/work/neoversen2-crypto-wrs-linux/
nodejs/20.5.1/recipe-sysroot -E LD_LIBRARY_PATH=tmp-glibc/work/neoversen2-crypto-wrs-linux/
nodejs/20.5.1/recipe-sysroot/usr/lib64:tmp-glibc/work/neoversen2-crypto-wrs-linux/
nodejs/20.5.1/recipe-sysroot/usr/lib64 "$@"
```
Upstream nodejs have cross compile support, but it needs host and target
have same bit width (e.g. a x86_64 host targeting arrch64 to produce a
64-bit binary). So:
1. If host and target have different bit width, build with QEMU user as usual;
2. If host and target have same bit width, enable notejs cross compile support:
- The build tools of nodejs is GYP[2], set CC_host, CFLAGS_host,
CXX_host, CXXFLAGS_host, LDFLAGS_host, AR_host for host build
which is separated with target build [3]
- Satisfy layer compatibility, set GYP variables in prefuncs of do_configure,
do_compile and do_install other than in recipe parsing
- Add missing native packages to fix library missing on host build
- Rework libatomic.patch, explicitly link to libatomic for clang
conditionally
[1] 2521b6073b
[2] https://github.com/nodejs/node-gyp
[3] https://github.com/nodejs/node-gyp/blob/main/gyp/docs/UserDocumentation.md#cross-compiling
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The original idea was always disable io_uring to avoid follwing failure
even when UV_USE_IO_URING is set to true, refer [1][2]:
0608: try:
*** 0609: update_hash(" %10s" % pwd.getpwuid(s.st_uid).pw_name)
0610: update_hash(" %10s" % grp.getgrgid(s.st_gid).gr_name)
0611: except KeyError as e:
0612: msg = ("KeyError: %s\nPath %s is owned by uid %d, gid %d, which doesn't match "
0613: "any user/group on target. This may be due to host contamination." %
Exception: Exception: KeyError: 'getpwuid(): uid not found: 20561'
But since 20.11.1, for fix CVE-2024-22017, io_uring is disabled by
default, refer [3]. So maybe patch
0001-deps-disable-io_uring-support-in-libuv.patch is not needed.
For case UV_USE_IO_URING is set to true, user can fix above failure
by "chown root:root -R ${D}" in do_install.
[1] https://lists.openembedded.org/g/openembedded-devel/message/105583
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15244
[3] 686da19abb
[4] https://nvd.nist.gov/vuln/detail/CVE-2024-22017
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Drop patches for revert io_uring support in libuv:
0001-Revert-io_uring-changes-from-libuv-1.46.0.patch
0002-Revert-io_uring-changes-from-libuv-1.45.0.patch
Change to just always disable io_uring in libuv, in this way, we don't have to
pick out io_uring related changes and revert them when internal libuv
upgraded.
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
* Pseudo fails to intercept some of the syscalls used by the
new version as documented in:
https://github.com/shr-project/com.webos.app.minimal/tree/recipes
Now we have 3 options:
1) every use of nodejs-native where io_uring might be used (like in webpack)
needs to export UV_USE_IO_URING=0 before using node, but be aware that
the PR says it's only temporary and this variable might be removed in future.
Unfortunately many people are lucky enough not to know what pseudo even is,
so they might not realize that host-user-contamination QA issues or
"KeyError: 'getpwuid(): uid not found" might be related to this (and they
probably won't find this e-mail as well:
https://lists.openembedded.org/g/openembedded-devel/message/105583
2) revert the io_uring changes from bundled libuv, to make sure it stays disabled.
The changes are massive and it will be PIA to update them for every nodejs release
I've already separated them for nodejs-20.3.0 where I've initialy tested this
on top of libuv-1.45.0 and for 20.4.0 this need another patch for changes
from libuv-1.46.0.
Patch for keeping UV_USE_IO_URING support after it's removed from upstream libuv
will be much smaller, but PIA to use UV_USE_IO_URING whenever using nodejs-native
during build.
3) fix pseudo to correctly work with io_uring calls, definitely best long-term solution
as more and more tools will now switch to io_uring, but without active maintainer
of pseudo it might be _very_ difficult to implement this and there aren't many
people willing to touch this beast.
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Update to latest release of latest LTS 20 release
* node v20 introduces several new features and fixes many bugs and CVEs as shown in [1]
* Refresh 0001-liftoff-Correct-function-signatures.patch against 20.5.1
* License-Update:
- Change zlib version 1.2.13, October 13th, 2022 to version 1.2.13.1, October xxth, 2022 [2]
- Change Copyright 2023 from Ada authors to Yagiz Nizipli and Daniel Lemire [4]
* Remove big-endian.patch as it is merged in v20.x [5] [6]
* Remove below list of patches since mips32 is deleted from v8 as part of update V8 to 10.7.193.13 [7] [8]
- mips-less-memory.patch
- 0001-mips-Use-32bit-cast-for-operand-on-mips32.patch
* Update Using-native-binaries.patch for node_js2c, it resolved below do_compile error [9]
Error:
/bin/sh: line 1: build/tmp/work/core2-64-poky-linux/nodejs/20.5.1/node-v20.5.1/out/Release/node_js2c: No such file or directory
* Remove obsolete dtrace & etw configure options (we had: --without-<feature>) from the recipe [10]
https://github.com/nodejs/node/releases/tag/v20.5.1
[1] https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V20.md
[2] f100732575
[3] 900ae1bda7
[4] d246536924
[5] 3cea5d5425
[6] f226350fcb
[7] a26ca5ed14
[8] 6bd756d7c6
[9] 4da7bc915c
[10] aa3a572e6b
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
There is new patch-status QA check in oe-core:
https://git.openembedded.org/openembedded-core/commit/?id=76a685bfcf927593eac67157762a53259089ea8a
This is temporary work around just to hide _many_ warnings from
optional patch-status (if you add it to WARN_QA).
This just added
Upstream-Status: Pending
everywhere without actually investigating what's the proper status.
This is just to hide current QA warnings and to catch new .patch files being
added without Upstream-Status, but the number of Pending patches is now terrible:
5 (26%) meta-xfce
6 (50%) meta-perl
15 (42%) meta-webserver
21 (36%) meta-gnome
25 (57%) meta-filesystems
26 (43%) meta-initramfs
45 (45%) meta-python
47 (55%) meta-multimedia
312 (63%) meta-networking
756 (61%) meta-oe
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
ptest-runner is not available for Nodejs on target hence added run-ptest script
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
* unfortunately all 3 have very long unclear history, I've tried to at least partially
document in commit message
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Node-18 is the current LTS release, node-19 is a development release and
node-20 is scheduled to be released until 2023-04-18 which is too late for YP-4.2
https://github.com/nodejs/release
* Refresh below two patches
- 0001-Using-native-binaries.patch
- 0001-liftoff-Correct-function-signatures.patch
* Copy openssl.cnf from sysroot_native to nodejs-openssl.cnf
otherwise do_compile failed:
make[1]: *** No rule to make target '../deps/openssl/nodejs-openssl.cnf',
needed by 'Release/obj.target/deps/openssl/openssl.cnf'. Stop.
* Add initial ptest support using ctest only, it covered 20% of the nodejs tests.
There are some more tests exist to add but will require additional work.
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
* Drop Openssl legacy provider patch and install both binaries patch
which are already available in 16.x
* Refresh native binaries patch against 16.x base
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Current nodejs version v16 does not fully support new OpenSSL, so add option
to use legacy provider.
| opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
| library: 'digital envelope routines',
| reason: 'unsupported',
| code: 'ERR_OSSL_EVP_UNSUPPORTED'
It was blindly removed by upgrade to 16.14.0 version
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Current nodejs version does not fully support new OpenSSL, so add option
to use legacy provider.
| opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
| library: 'digital envelope routines',
| reason: 'unsupported',
| code: 'ERR_OSSL_EVP_UNSUPPORTED'
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
* This is new LTS release
* Add patch to fix build on mips/mips64
* Add patch to build with new c-ares 2.17+
* Enhance native binaries patch to include additional native torque use
* Drop mips-warnings.patch and python 3.10 support patch which is
already available in 16.x
* Refresh rest of patches against 16.x base
Signed-off-by: Khem Raj <raj.khem@gmail.com>
2G is too much for qemu-mips and perhaps also for real mips devices
as we use qemu-usermode during build to run host pieces like mksnapshot
they fail, reducing the allocation range helps
Fixes
| LD_LIBRARY_PATH=/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/nodejs/14.16.1-r0/node-v14.16.1/out/Release/lib.host:/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/nodejs/14.16.1-r0/node-v14.16.1
/out/Release/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../tools/v8_gypfiles; mkdir -p /mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/nodejs/14.16.1-r0/node-v14.16.1/out/Release/obj.target/v
8_snapshot/geni; "/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/nodejs/14.16.1-r0/node-v14.16.1/out/Release/v8-qemu-wrapper.sh" "/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/nodejs/14.16.1-r0/nod
e-v14.16.1/out/Release/mksnapshot" --turbo_instruction_scheduling "--target_os=linux" "--target_arch=mips" --startup_src "/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/nodejs/14.16.1-r0/node-v14.16.1/ou
t/Release/obj.target/v8_snapshot/geni/snapshot.cc" --embedded_variant Default --embedded_src "/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/nodejs/14.16.1-r0/node-v14.16.1/out/Release/obj.target/v8_snap
shot/geni/embedded.S" --no-native-code-counters
|
| #
| # Fatal process OOM in CodeRange setup: allocate virtual memory
| #
|
| /mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/nodejs/14.16.1-r0/node-v14.16.1/out/Release/v8-qemu-wrapper.sh: line 7: 2292880 Trace/breakpoint trap (core dumped) PSEUDO_UNLOAD=1 qemu-mips -r 3.2.0 -
Signed-off-by: Khem Raj <raj.khem@gmail.com>
So far, we have been trying to build nodejs-native and use the native
host binaries from there, which has worked out ok but always changes
when major upgrade is done, since more binaries or places are required
to be captured. This patch changes this approach to use qemu-user to run
these binaries under during cross build. This lets them run closer to
upstream build process and also removes dependency on nodejs-native
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This is latest maintained LTS release
Forward patches and drop backported patch
License-Update: Update copyright year and drop license of
deps/http_parser as this component is removed in this version
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Backport a patch from upstream to take care of build failure e.g.
| ../deps/v8/src/codegen/arm/cpu-arm.cc:38:16: error: write to reserved register 'R7'
| asm volatile("svc 0\n"
| ^
| 1 error generated.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Use system brotli via PACKAGECONFIG by default. So far,
nodejs had been built using its embedded copy of brotli,
which we generally try to avoid, for the known reasons
(independent updates, cve & license checks, etc).
The nodejs patches to enable this have been submitted.
brotli is in meta-oe, so enabling this by default should
not be a problem.
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
