Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

grab bag of small UB fixes #2298

Merged
merged 4 commits into from
Mar 12, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion libraries/appbase
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,10 @@

#include <sys/resource.h>

#ifndef __has_feature
#define __has_feature(x) 0
#endif

namespace eosio { namespace chain { namespace eosvmoc {

struct config {
Expand All @@ -20,7 +24,11 @@ struct config {
// libtester disables the limits in all tests, except enforces the limits
// in the tests in unittests/eosvmoc_limits_tests.cpp.
std::optional<rlim_t> cpu_limit {20u};
#if __has_feature(undefined_behavior_sanitizer) || __has_feature(address_sanitizer)
std::optional<rlim_t> vm_limit; // UBSAN & ASAN can add massive virtual memory usage; don't enforce vm limits when either of them are enabled
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't need this for tests to pass: OC in unit tests always has vm_limit disabled now (except for the one modified test case), and python integration tests never use OC. But I'd like to use OC + ASAN/UBSAN with nodeos. Such usage is probably "developer enough" where simply disabling this limit is safe when configured that way; i.e. won't trap unsuspecting users. Alternatively could guard this disablement behind EOSVMOC_ENABLE_DEVELOPER_OPTIONS but ultimately I want to remove that option.

#else
std::optional<rlim_t> vm_limit {512u*1024u*1024u};
#endif
std::optional<uint64_t> stack_size_limit {16u*1024u};
std::optional<size_t> generated_code_size_limit {16u*1024u*1024u};
};
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -122,7 +122,8 @@ void run_compile(wrapped_fd&& response_sock, wrapped_fd&& wasm_code, uint64_t st

if(base_offset + data_segment.data.size() > initial_mem.size())
initial_mem.resize(base_offset + data_segment.data.size(), 0x00);
memcpy(initial_mem.data() + base_offset, data_segment.data.data(), data_segment.data.size());
if(data_segment.data.size())
memcpy(initial_mem.data() + base_offset, data_segment.data.data(), data_segment.data.size());
}

result_message.initdata_prologue_size = prologue.end() - prologue_it;
Expand Down
2 changes: 1 addition & 1 deletion libraries/chain/webassembly/runtimes/eos-vm-oc/memory.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ memory::memory(uint64_t sliced_pages) {
uintptr_t* const intrinsic_jump_table = reinterpret_cast<uintptr_t* const>(zeropage_base - first_intrinsic_offset);
const intrinsic_map_t& intrinsics = get_intrinsic_map();
for(const auto& intrinsic : intrinsics)
intrinsic_jump_table[-intrinsic.second.ordinal] = (uintptr_t)intrinsic.second.function_ptr;
intrinsic_jump_table[-(int)intrinsic.second.ordinal] = (uintptr_t)intrinsic.second.function_ptr;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an interesting one. The error here gets reported somewhat confusingly as addition of unsigned offset to 0x7aca262015f8 overflowed to 0x7aca26201570. I believe what is occurring is that ordinal is a size_t thus uint64_t, and negating it is still a uint64_t: now a really large uint64_t. But pointer arithmetic is defined on integer math; ptrdiff_t is a signed integer for example. So I think this is causing some sort of wrap around on a large signed integer. Casting ordinal to an int before the negation ensures it remains a small value int before pointer arithmetic. I'd be curious on other takes though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this use intptr_t (long int) instead of int?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ordinal is the host function index over in,

return detail::generate_table(
"eosvmoc_internal.unreachable",

so int will always be plenty large enough (we won't have 231 host functions). My initial impression of intptr_t is that its purpose/connotation isn't really for indexes in to an array.

I do wonder if ordinal should just be an int instead; I don't think it'd be too hard to change it.

}

memory::~memory() {
Expand Down
2 changes: 1 addition & 1 deletion libraries/eos-vm
2 changes: 1 addition & 1 deletion libraries/libfc/libraries/bn256
Submodule bn256 updated 1 files
+6 −0 src/CMakeLists.txt
2 changes: 1 addition & 1 deletion tests/abieos
10 changes: 10 additions & 0 deletions unittests/eosvmoc_limits_tests.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -98,6 +98,8 @@ BOOST_AUTO_TEST_CASE( limits_not_enforced ) { try {
limit_not_violated_test(eosvmoc_config);
} FC_LOG_AND_RETHROW() }

// UBSAN & ASAN can add massive virtual memory usage; skip this test when either are enabled
#if !__has_feature(undefined_behavior_sanitizer) && !__has_feature(address_sanitizer)
// test VM limit are checked
BOOST_AUTO_TEST_CASE( vm_limit ) { try {
eosvmoc::config eosvmoc_config = make_eosvmoc_config_without_limits();
Expand All @@ -111,6 +113,14 @@ BOOST_AUTO_TEST_CASE( vm_limit ) { try {
limit_not_violated_test(eosvmoc_config);
} FC_LOG_AND_RETHROW() }

//make sure vm_limit is populated for a default constructed config (what nodeos will use)
BOOST_AUTO_TEST_CASE( check_config_default_vm_limit ) { try {
eosvmoc::config eosvmoc_config;

BOOST_REQUIRE(eosvmoc_config.vm_limit);
} FC_LOG_AND_RETHROW() }
#endif

// test stack size limit is checked
BOOST_AUTO_TEST_CASE( stack_limit ) { try {
eosvmoc::config eosvmoc_config = make_eosvmoc_config_without_limits();
Expand Down
Loading