I'm trying to write a simple socket filter eBPF program that can access the socket buffer data.
#include <linux/bpf.h>
#include <linux/if_ether.h>
#define SEC(NAME) __attribute__((section(NAME), used))
SEC("socket_filter")
int myprog(struct __sk_buff *skb) {
void *data = (void *)(long)skb->data;
void *data_end = (void *)(long)skb->data_end;
struct ethhdr *eth = data;
if ((void*)eth + sizeof(*eth) > data_end)
return 0;
return 1;
}
And I'm compiling using clang:
clang -I./ -I/usr/include/x86_64-linux-gnu/asm \
-I/usr/include/x86_64-linux-gnu/ -O2 -target bpf -c test.c -o test.elf
However when I try to load the program I get the following verifier error:
invalid bpf_context access off=80 size=4
My understanding of this error is that it should be thrown when you try to access context data that hasn't been checked to be within data_end, however my code does do that:
Here is the instructions for my program
0000000000000000 packet_counter:
0: 61 12 50 00 00 00 00 00 r2 = *(u32 *)(r1 + 80)
1: 61 11 4c 00 00 00 00 00 r1 = *(u32 *)(r1 + 76)
2: 07 01 00 00 0e 00 00 00 r1 += 14
3: b7 00 00 00 01 00 00 00 r0 = 1
4: 3d 12 01 00 00 00 00 00 if r2 >= r1 goto +1 <LBB0_2>
5: b7 00 00 00 00 00 00 00 r0 = 0
which would imply that the error is being caused by reading the pointer to data_end? However it only happens if I don't try to check the bounds later.
This is because your BPF program is a “socket filter”, and that such programs are not allowed to do direct packet access (see sk_filter_is_valid_access(), where we return false on trying to read skb->data or skb->data_end for example). I do not know the specific reason why it is not available, although I suspect this would be a security precaution as socket filter programs may be available to unprivileged users.
Your program loads just fine as a TC classifier, for example (bpftool prog load foo.o /sys/fs/bpf/foo type classifier -- By the way thanks for the standalone working reproducer, much appreciated!).
If you want to access data for a socket filter, you can still use the bpf_skb_load_bytes() (or bpf_skb_store_bytes()) helper, which automatically does the check on length. Something like this:
#include <linux/bpf.h>
#define SEC(NAME) __attribute__((section(NAME), used))
static void *(*bpf_skb_load_bytes)(const struct __sk_buff *, __u32,
void *, __u32) =
(void *) BPF_FUNC_skb_load_bytes;
SEC("socket_filter")
int myprog(struct __sk_buff *skb)
{
__u32 foo;
if (bpf_skb_load_bytes(skb, 0, &foo, sizeof(foo)))
return 0;
if (foo == 3)
return 0;
return 1;
}
Regarding your last comment:
However it only happens if I don't try to check the bounds later.
I suspect clang compiles out the assignments for data and data_end if you do not use them in your code, so they are no longer present and no longer a problem for the verifier.
I'm having a bit of a hard time with using the v8::EmbedderHeapTracer API with V8 version 6.3.
My issue is the following sequence of events happening in the following order:
V8 will call TracePrologue.
V8 will register a V8 reference for embedder field pointer with RegisterV8References.
Optional: I have tried both calling and not calling RegisterExternalReference on the object the embedder field is stored in here. Intuitively, I would expect this to be redundant information, as V8 has already detected it as reachable, but I have tried calling it out of paranoia.
I will add pointer to my frontier (e.g. the stack for DFS traversal of the embedder heap).
V8 will then run the SetWeak callback on the v8::Persistent<v8::Object> that it just registered before. This will cause me to delete the object.
Note that neither EnterFinalPause nor TraceEpilogue have been called yet.
pointer is removed from the frontier, and I attempt to expand it. This results in a heap use after free (detected by ASan).
Is objects that are determined to be reachable being deleted within the same GC cycle something that I should have to be worried about? I would have thought that anything that has RegisterExternalReference called on it would be kept alive until at least the next GC cycle.
Additional information:
ASan dump:
=================================================================
==184290==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c0001687c0 at pc 0x0000053ad97e bp 0x7f36d0676f30 sp 0x7f36d0676f28
READ of size 8 at 0x60c0001687c0 thread T30 (MainWebModule)
#0 0x53ad97d in cobalt::script::v8c::V8cHeapTracer::AdvanceTracing(double, v8::EmbedderHeapTracer::AdvanceTracingActions) out/linux-x64x11-v8_debug/../../cobalt/script/v8c/v8c_heap_tracer.cc:76:16
#1 0x675d8e2 in v8::internal::LocalEmbedderHeapTracer::Trace(double, v8::EmbedderHeapTracer::AdvanceTracingActions) out/linux-x64x11-v8_debug/../../v8/src/heap/embedder-tracing.cc:45:26
#2 0x67975e7 in v8::internal::MarkCompactCollector::ProcessEphemeralMarking(bool) out/linux-x64x11-v8_debug/../../v8/src/heap/mark-compact.cc:1847:46
#3 0x678ed88 in v8::internal::MarkCompactCollector::MarkLiveObjects() out/linux-x64x11-v8_debug/../../v8/src/heap/mark-compact.cc:2558:7
#4 0x678d983 in v8::internal::MarkCompactCollector::CollectGarbage() out/linux-x64x11-v8_debug/../../v8/src/heap/mark-compact.cc:525:3
#5 0x66ab63d in v8::internal::Heap::MarkCompact() out/linux-x64x11-v8_debug/../../v8/src/heap/heap.cc:1684:29
#6 0x66a835f in v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) out/linux-x64x11-v8_debug/../../v8/src/heap/heap.cc:1557:9
#7 0x66a6c48 in v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) out/linux-x64x11-v8_debug/../../v8/src/heap/heap.cc:1216:11
#8 0x66a4b78 in v8::internal::Heap::CollectAllGarbage(int, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) out/linux-x64x11-v8_debug/../../v8/src/heap/heap.cc:1069:3
#9 0x66a4725 in v8::internal::Heap::HandleGCRequest() out/linux-x64x11-v8_debug/../../v8/src/heap/heap.cc:993:5
#10 0x659cb9a in v8::internal::StackGuard::HandleInterrupts() out/linux-x64x11-v8_debug/../../v8/src/execution.cc:480:23
#11 0x710ac22 in v8::internal::__RT_impl_Runtime_StackGuard(v8::internal::Arguments, v8::internal::Isolate*) out/linux-x64x11-v8_debug/../../v8/src/runtime/runtime-internal.cc:306:34
#12 0x710a4f3 in v8::internal::Runtime_StackGuard(int, v8::internal::Object**, v8::internal::Isolate*) out/linux-x64x11-v8_debug/../../v8/src/runtime/runtime-internal.cc:296:1
#13 0x7f36af5047a3 (<unknown module>)
0x60c0001687c0 is located 0 bytes inside of 120-byte region [0x60c0001687c0,0x60c000168838)
freed by thread T30 (MainWebModule) here:
#0 0x2308fd2 in operator delete(void*) (out/linux-x64x11-v8_debug/cobalt+0x2308fd2)
#1 0x3b532d1 in cobalt::dom::KeyboardEvent::~KeyboardEvent() out/linux-x64x11-v8_debug/../../cobalt/dom/keyboard_event.h:99:29
#2 0x238f94c in base::RefCounted<cobalt::script::Wrappable>::Release() const out/linux-x64x11-v8_debug/../../base/memory/ref_counted.h:91:7
#3 0x24ced4f in scoped_refptr<cobalt::script::Wrappable>::~scoped_refptr() out/linux-x64x11-v8_debug/../../base/memory/ref_counted.h:249:13
#4 0xb928ca2 in cobalt::script::v8c::WrapperPrivate::~WrapperPrivate() out/linux-x64x11-v8_debug/../../cobalt/script/v8c/wrapper_private.h:86:3
#5 0xb9285ba in cobalt::script::v8c::WrapperPrivate::Callback(v8::WeakCallbackInfo<cobalt::script::v8c::WrapperPrivate> const&) out/linux-x64x11-v8_debug/../../cobalt/script/v8c/wrapper_private.h:38:5
#6 0x667f45c in v8::internal::GlobalHandles::PendingPhantomCallback::Invoke(v8::internal::Isolate*) out/linux-x64x11-v8_debug/../../v8/src/global-handles.cc:848:3
#7 0x6680408 in v8::internal::GlobalHandles::DispatchPendingPhantomCallbacks(bool) out/linux-x64x11-v8_debug/../../v8/src/global-handles.cc:813:16
#8 0x668084b in v8::internal::GlobalHandles::PostGarbageCollectionProcessing(v8::internal::GarbageCollector, v8::GCCallbackFlags) out/linux-x64x11-v8_debug/../../v8/src/global-handles.cc:869:18
#9 0x66a8a7b in v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) out/linux-x64x11-v8_debug/../../v8/src/heap/heap.cc:1601:37
#10 0x66a6c48 in v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) out/linux-x64x11-v8_debug/../../v8/src/heap/heap.cc:1216:11
#11 0x65bdfc9 in v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) out/linux-x64x11-v8_debug/../../v8/src/factory.cc:91:3
#12 0x710c27d in v8::internal::__RT_impl_Runtime_AllocateInNewSpace(v8::internal::Arguments, v8::internal::Isolate*) out/linux-x64x11-v8_debug/../../v8/src/runtime/runtime-internal.cc:322:31
#13 0x710b9c3 in v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) out/linux-x64x11-v8_debug/../../v8/src/runtime/runtime-internal.cc:315:1
#14 0x7f36af5047a3 (<unknown module>)
#15 0x7f36af5513fb (<unknown module>)
#16 0x7f36af5be594 (<unknown module>)
#17 0x7f36af5b583e (<unknown module>)
#18 0x7f36af5be594 (<unknown module>)
#19 0x7f36af5b583e (<unknown module>)
#20 0x7f36af5be594 (<unknown module>)
#21 0x7f36af5bb818 (<unknown module>)
#22 0x7f36af5040fe (<unknown module>)
#23 0x6599b9a in v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, bool, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, v8::internal::Handle<v8::internal::Object>, v8::internal::Execution::MessageHandling) out/linux-x64x11-v8_debug/../../v8/src/execution.cc:146:13
#24 0x6598454 in v8::internal::(anonymous namespace)::CallInternal(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, v8::internal::Execution::MessageHandling) out/linux-x64x11-v8_debug/../../v8/src/execution.cc:182:10
#25 0x6597dd6 in v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) out/linux-x64x11-v8_debug/../../v8/src/execution.cc:192:10
#26 0x54a5627 in v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) out/linux-x64x11-v8_debug/../../v8/src/api.cc:5449:7
#27 0xb96677e in cobalt::dom::V8cEventListener::HandleEvent(scoped_refptr<cobalt::script::Wrappable> const&, scoped_refptr<cobalt::dom::Event> const&, bool*) const out/linux-x64x11-v8_debug/gen/bindings/browser/source/cobalt/dom/v8c_event_listener.cc:90:20
#28 0x3a2962b in cobalt::dom::EventListener::HandleEvent(scoped_refptr<cobalt::dom::Event> const&, cobalt::dom::EventListener::Type) const out/linux-x64x11-v8_debug/../../cobalt/dom/event_listener.cc:95:7
#29 0x3a1e705 in cobalt::dom::EventTarget::FireEventOnListeners(scoped_refptr<cobalt::dom::Event> const&) out/linux-x64x11-v8_debug/../../cobalt/dom/event_target.cc:200:31
previously allocated by thread T30 (MainWebModule) here:
#0 0x23083d2 in operator new(unsigned long) (out/linux-x64x11-v8_debug/cobalt+0x23083d2)
#1 0x24b530b in cobalt::browser::WebModule::Impl::InjectKeyboardEvent(scoped_refptr<cobalt::dom::Element>, base::Token, cobalt::dom::KeyboardEventInit const&) out/linux-x64x11-v8_debug/../../cobalt/browser/web_module.cc:791:7
#2 0x253ca5e in base::internal::RunnableAdapter<void (cobalt::browser::WebModule::Impl::*)(scoped_refptr<cobalt::dom::Element>, base::Token, cobalt::dom::KeyboardEventInit const&)>::Run(cobalt::browser::WebModule::Impl*, scoped_refptr<cobalt::dom::Element> const&, base::Token const&, cobalt::dom::KeyboardEventInit const&) out/linux-x64x11-v8_debug/../../base/bind_internal.h:317:12
#3 0x2556929 in base::internal::InvokeHelper<false, void, base::internal::RunnableAdapter<void (cobalt::browser::WebModule::Impl::*)(scoped_refptr<cobalt::dom::Element>, base::Token, cobalt::dom::KeyboardEventInit const&)>, void (cobalt::browser::WebModule::Impl*, cobalt::dom::Element*, base::Token const&, cobalt::dom::KeyboardEventInit const&)>::MakeItSo(base::internal::RunnableAdapter<void (cobalt::browser::WebModule::Impl::*)(scoped_refptr<cobalt::dom::Element>, base::Token, cobalt::dom::KeyboardEventInit const&)>, cobalt::browser::WebModule::Impl*, cobalt::dom::Element*, base::Token const&, cobalt::dom::KeyboardEventInit const&) out/linux-x64x11-v8_debug/../../base/bind_internal.h:966:14
#4 0x25565d6 in base::internal::Invoker<4, base::internal::BindState<base::internal::RunnableAdapter<void (cobalt::browser::WebModule::Impl::*)(scoped_refptr<cobalt::dom::Element>, base::Token, cobalt::dom::KeyboardEventInit const&)>, void (cobalt::browser::WebModule::Impl*, scoped_refptr<cobalt::dom::Element>, base::Token, cobalt::dom::KeyboardEventInit const&), void (base::internal::UnretainedWrapper<cobalt::browser::WebModule::Impl>, scoped_refptr<cobalt::dom::Element>, base::Token, cobalt::dom::KeyboardEventInit)>, void (cobalt::browser::WebModule::Impl*, scoped_refptr<cobalt::dom::Element>, base::Token, cobalt::dom::KeyboardEventInit const&)>::Run(base::internal::BindStateBase*) out/linux-x64x11-v8_debug/../../base/bind_internal.h:1571:12
#5 0x2322063 in base::Callback<void ()>::Run() const out/linux-x64x11-v8_debug/../../base/callback.h:412:12
#6 0x25d3932 in MessageLoop::RunTask(base::PendingTask const&) out/linux-x64x11-v8_debug/../../base/message_loop.cc:548:21
#7 0x25d41f9 in MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) out/linux-x64x11-v8_debug/../../base/message_loop.cc:560:5
#8 0x25d451e in MessageLoop::DoWork() out/linux-x64x11-v8_debug/../../base/message_loop.cc:744:13
#9 0x25f1e1b in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) out/linux-x64x11-v8_debug/../../base/message_pump_default.cc:31:31
#10 0x25d2648 in MessageLoop::RunInternal() out/linux-x64x11-v8_debug/../../base/message_loop.cc:491:10
#11 0x25d23f4 in MessageLoop::RunHandler() out/linux-x64x11-v8_debug/../../base/message_loop.cc:463:3
#12 0x265e81f in base::RunLoop::Run() out/linux-x64x11-v8_debug/../../base/run_loop.cc:47:10
#13 0x25d0cbc in MessageLoop::Run() out/linux-x64x11-v8_debug/../../base/message_loop.cc:363:12
#14 0x26f2398 in base::Thread::Run(MessageLoop*) out/linux-x64x11-v8_debug/../../base/threading/thread.cc:159:17
#15 0x26f28a3 in base::Thread::ThreadMain() out/linux-x64x11-v8_debug/../../base/threading/thread.cc:212:5
#16 0x26e58bc in base::(anonymous namespace)::ThreadFunc(void*) out/linux-x64x11-v8_debug/../../base/threading/platform_thread_starboard.cc:44:13
#17 0x2d1f982 in (anonymous namespace)::ThreadFunc(void*) out/linux-x64x11-v8_debug/../../starboard/shared/pthread/thread_create.cc:73:10
#18 0x7f37370ab183 in start_thread /build/eglibc-ripdx6/eglibc-2.19/nptl/pthread_create.c:312
Thread T30 (MainWebModule) created by T0 here:
#0 0x22c381d in __interceptor_pthread_create (out/linux-x64x11-v8_debug/cobalt+0x22c381d)
#1 0x2d1f489 in SbThreadCreate out/linux-x64x11-v8_debug/../../starboard/shared/pthread/thread_create.cc:124:12
#2 0x26e5504 in base::(anonymous namespace)::CreateThread(unsigned long, SbThreadPriority, int, bool, char const*, base::PlatformThread::Delegate*, unsigned long*) out/linux-x64x11-v8_debug/../../base/threading/platform_thread_starboard.cc:59:21
#3 0x26e5787 in base::PlatformThread::CreateWithOptions(base::PlatformThread::PlatformThreadOptions const&, base::PlatformThread::Delegate*, unsigned long*) out/linux-x64x11-v8_debug/../../base/threading/platform_thread_starboard.cc:142:10
#4 0x26f195e in base::Thread::StartWithOptions(base::Thread::Options const&) out/linux-x64x11-v8_debug/../../base/threading/thread.cc:96:8
#5 0x24bb450 in cobalt::browser::WebModule::WebModule(GURL const&, base::ApplicationState, base::Callback<void (cobalt::layout::LayoutManager::LayoutResults const&)> const&, base::Callback<void (GURL const&, std::string const&)> const&, base::Callback<void (base::TimeDelta)> const&, base::Callback<void ()> const&, cobalt::media::CanPlayTypeHandler*, cobalt::media::WebMediaPlayerFactory*, cobalt::network::NetworkModule*, cobalt::math::Size const&, float, cobalt::render_tree::ResourceProvider*, float, cobalt::browser::WebModule::Options const&) out/linux-x64x11-v8_debug/../../cobalt/browser/web_module.cc:1226:11
#6 0x23495ab in cobalt::browser::BrowserModule::Navigate(GURL const&) out/linux-x64x11-v8_debug/../../cobalt/browser/browser_module.cc:519:25
#7 0x2343f7c in cobalt::browser::BrowserModule::BrowserModule(GURL const&, base::ApplicationState, base::EventDispatcher*, cobalt::account::AccountManager*, cobalt::browser::BrowserModule::Options const&) out/linux-x64x11-v8_debug/../../cobalt/browser/browser_module.cc:372:3
#8 0x23124f7 in cobalt::browser::Application::Application(base::Callback<void ()> const&, bool) out/linux-x64x11-v8_debug/../../cobalt/browser/application.cc:614:11
#9 0x230cb48 in (anonymous namespace)::StartApplication(int, char**, char const*, base::Callback<void ()> const&) out/linux-x64x11-v8_debug/../../cobalt/browser/main.cc:78:25
#10 0x230c0b2 in void cobalt::wrap_main::BaseEventHandler<&(anonymous namespace)::PreloadApplication, &(anonymous namespace)::StartApplication, &(anonymous namespace)::HandleStarboardEvent, &(anonymous namespace)::StopApplication>(SbEvent const*) out/linux-x64x11-v8_debug/../../cobalt/base/wrap_main_starboard.h:74:7
#11 0x230b214 in SbEventHandle out/linux-x64x11-v8_debug/../../cobalt/browser/main.cc:105:1
#12 0x2d246b4 in starboard::shared::starboard::Application::DispatchAndDelete(starboard::shared::starboard::Application::Event*) out/linux-x64x11-v8_debug/../../starboard/shared/starboard/application.cc:307:3
#13 0x2d23685 in starboard::shared::starboard::Application::DispatchStart() out/linux-x64x11-v8_debug/../../starboard/shared/starboard/application.cc:194:3
#14 0x2d2242b in starboard::shared::starboard::Application::RunLoop() out/linux-x64x11-v8_debug/../../starboard/shared/starboard/application.cc:382:5
#15 0x2d228b8 in starboard::shared::starboard::Application::Run(starboard::shared::starboard::CommandLine) out/linux-x64x11-v8_debug/../../starboard/shared/starboard/application.cc:111:10
#16 0x277ca1f in starboard::shared::starboard::Application::Run(int, char**) out/linux-x64x11-v8_debug/../../starboard/shared/starboard/application.h:166:12
#17 0x277c849 in main out/linux-x64x11-v8_debug/../../starboard/linux/x64x11/main.cc:31:26
#18 0x7f37360cff44 in __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:287
SUMMARY: AddressSanitizer: heap-use-after-free out/linux-x64x11-v8_debug/../../cobalt/script/v8c/v8c_heap_tracer.cc:76:16 in cobalt::script::v8c::V8cHeapTracer::AdvanceTracing(double, v8::EmbedderHeapTracer::AdvanceTracingActions)
Shadow bytes around the buggy address:
0x0c18800250a0: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
0x0c18800250b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c18800250c0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
0x0c18800250d0: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
0x0c18800250e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
=>0x0c18800250f0: fa fa fa fa fa fa fa fa[fd]fd fd fd fd fd fd fd
0x0c1880025100: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa
0x0c1880025110: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
0x0c1880025120: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
0x0c1880025130: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
0x0c1880025140: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==184290==ABORTING
Log output (logging GC cycle begin/end, object marking, and the weak callback running):
$ cat log.txt | grep -P '(Begin|End|0x60c000199540)'
[0204/150945:INFO:v8c_heap_tracer.cc(53)] Begin GC cycle 1
[0204/151001:INFO:v8c_heap_tracer.cc(37)] 0x60c000199540 got registered by RegisterV8References during GC cycle 1
[0204/151001:INFO:v8c_heap_tracer.cc(172)] 0x60c000199540 got marked during GC cycle 1
[0204/151001:INFO:wrapper_private.h(78)] 0x60c000199540 is dying in GC cycle 1
==190737==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000199540 at pc 0x0000053ad9de bp 0x7fe4ebb76270 sp 0x7fe4ebb76268
READ of size 8 at 0x60c000199540 thread T30 (MainWebModule)
0x60c000199540 is located 0 bytes inside of 120-byte region [0x60c000199540,0x60c0001995b8)
With the default configuration V8 marks wrappers, i.e., objects pointing into embedder memory, incrementally.
The requirements are
An v8::EmbedderHeapTracer implementation figuring out (transitive) liveness of V8 wrappers based on references passed to it from V8.
Consistency mechanisms, .e.g., write barriers, when DOM is mutated during incremental marking.
Informing V8's young generation garbage collector to keep v8::Persistent alive during incremental marking.
3 is probably subtle. The steps involved are:
Register a callback for Scavenges using Isolate::AddGCPrologueCallback
Visit weak persistent handles using Isolate::VisitWeakHandles
Mark weak persistents as active using v8::PersistentBase<T>::MarkActive
Steps 2 and 3 can be omitted when turning off incremental tracing of wrappers using the flag incremental_marking_wrappers.
I am using bson-ext as a native binding.
Building the native .node file has worked well so far. I installed GCC, make and ran node-gyp configure and node-gyp build. I am now including the file in my node app like so:
var bson = require('./bson/build/Release/bson.node');
var object = bson.BSON.prototype;
console.log(object.serialize('hey'))
The problem is, I am getting this error:
console.log(object.serialize({test: "turkey"}))
TypeError: Illegal invocation
I get confused here because when I do console.log(object)
It outputs:
BSON {
calculateObjectSize: [Function: calculateObjectSize],
serialize: [Function: serialize],
serializeWithBufferAndIndex: [Function: serializeWithBufferAndIndex],
deserialize: [Function: deserialize],
deserializeStream: [Function: deserializeStream] }
These are the native functions from C++ that were built to bson.node, right? But, now I am just not sure how to call them. I have checked their github page as well for documentation, but with no luck.
Edit: The following:
var bson = require('./bson/build/Release/bson');
console.log(bson.BSON)
outputs:
[Function: BSON]
Next, I run:
console.log(bson.BSON().serialize({turkey: 'hey'}));
But receive:
console.log(bson.BSON().serialize({turkey: 'hey'}));
TypeError: First argument passed in must be an array of types
Then I run:
console.log(bson.BSON(['BSON']).serialize({turkey: 'hey'}));
And receive:
Segmentation fault
I found a solution inside the mongodb package.
(Specifically at \mongodb\node_modules\mongodb-core\lib\replset.js # line 15).
They are using .native()
BSON = require('bson').native().BSON;
var newBSON = new bson();
console.log(newBSON.serialize('hello'));
Which does work:
<Buffer 32 00 00 00 02 30 00 02 00 00 00 68 00 02 31 00 02 00 00 00 65 00 02 32 00 02 00 00 00 6c 00 02 33 00 02 00 00 00 6c 00 02 34 00 02 00 00 00 6f 00 00>
However, (Slightly off-topic, but, I made a question yesterday Why is JSON faster than BSON, and the conclusion was native code vs non-native code. But, now, even after installing bson natively, the performance results are roughly the same... bummer.
I have read this link Analyzing kmemleak result, but it seems not give the final answer.
After scanning the memory leak by kmemleak. I can derive the result of unreferenced object's address, say 0xffff880060bb3060 [in the update].
and I use the following gdb command to see the location of this address.
Note I found the .text_address in /sys/module/hello/session/.text, and the value is 0xffffffffa038c000
sudo insmod hello.ko
gdb hello.ko /proc/kcore
add-symbol-file hello.ko 0xffffffffa038c000
list *0xffff880060bb3060
However the list command show nothing.
I have used these steps to debug of kernel oops message, so I'm sure the command I type is correct.
So how can I use gdb to analyze the result given by kmemleak?
Update
I think I should also provide my sample code hello.c:
#include <linux/module.h>
#include <linux/list.h>
#include <linux/slab.h>
struct num {
struct list_head node;
int number;
};
static int __init hello_init(void)
{
LIST_HEAD(my_list);
struct num *tmp;
struct list_head *iterator;
u8 i;
for(i=0; i<5; i++) {
tmp = kmalloc(sizeof(struct num), GFP_KERNEL); //I expect this line will be output as memory leak
tmp->number = i;
list_add(&tmp->node, &my_list);
}
list_for_each(iterator, &my_list) {
printk("%d\n", list_entry(iterator, struct num, node)->number);
}
return 0;
}
static void hello_exit(void)
{
printk(KERN_ALERT "Good, haha\n");
}
module_init(hello_init);
module_exit(hello_exit);
And the following is the scan result:
unreferenced object 0xffff880060bb3060 (size 32):
comm "swapper/0", pid 1, jiffies 4294895149 (age 802.568s)
hex dump (first 32 bytes):
00 01 10 00 00 00 ad de 00 02 20 00 00 00 ad de .......... .....
00 28 b1 57 00 88 ff ff 01 4f 0a 56 00 00 00 00 .(.W.....O.V....
backtrace:
[<ffffffff8170ea7e>] kmemleak_alloc+0x4e/0xc0
[<ffffffff811a5de8>] kmem_cache_alloc_trace+0xb8/0x160
[<ffffffff810b0ed6>] pm_vt_switch_required+0x76/0xb0
[<ffffffff813c1e61>] register_framebuffer+0x1d1/0x370
[<ffffffff813db3fc>] vesafb_probe+0x5bc/0xa70
[<ffffffff814870cc>] platform_drv_probe+0x3c/0x70
[<ffffffff81484d74>] driver_probe_device+0x94/0x3d0
[<ffffffff8148517b>] __driver_attach+0x8b/0x90
[<ffffffff81482913>] bus_for_each_dev+0x73/0xb0
[<ffffffff814847ae>] driver_attach+0x1e/0x20
[<ffffffff814842f8>] bus_add_driver+0x208/0x2e0
[<ffffffff81485844>] driver_register+0x64/0xf0
[<ffffffff81486eca>] __platform_driver_register+0x4a/0x50
[<ffffffff81d923f1>] vesafb_driver_init+0x12/0x14
[<ffffffff810020f2>] do_one_initcall+0xf2/0x1b0
[<ffffffff81d50f24>] kernel_init_freeable+0x144/0x1cc
I was trying to write a pci driver which can display the MAC address of my Ethernet card.
Running a Ubuntu on VM and my Ethernet card is Intel one as follows
00:08.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
I was able to get the data sheet of the same from Intel website and as per data sheet it says IO address are mapped to Bar 2 (Refer to pg 87) and MAC can be read using RAL/RAH register which are at offset RAL (05400h + 8*n; R/W) and RAH (05404h + 8n; R/W)
2 18h IO Register Base Address (bits 31:2) 0b mem
Based on this information, i wrote a small PCI driver but i always get the MAC as fff and when i debugged further, i see io_base address is always zero.
Below is the code
1 /*
2 Program to find a device on the PCI sub-system
3 */
4 #define VENDOR_ID 0x8086
5 #define DEVICE_ID 0x100e
6
7 #include <linux/kernel.h>
8 #include <linux/module.h>
9 #include <linux/stddef.h>
10 #include <linux/pci.h>
11 #include <linux/init.h>
12 #include <linux/cdev.h>
13 #include <linux/device.h>
14 #include <asm/io.h>
15
16 #define LOG(string...) printk(KERN_INFO string)
17
18 #define CDEV_MAJOR 227
19 #define CDEV_MINOR 0
20
21
22 MODULE_LICENSE("GPL");
23
24 struct pci_dev *pci_dev;
25 unsigned long mmio_addr;
26 unsigned long reg_len;
27 unsigned long *base_addr;
28
29 int device_probe(struct pci_dev *dev, const struct pci_device_id *id);
30 void device_remove(struct pci_dev *dev);
31
32 struct pci_device_id pci_device_id_DevicePCI[] =
33 {
34 {VENDOR_ID, DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
35 };
36
37 struct pci_driver pci_driver_DevicePCI =
38 {
39 name: "MyPCIDevice",
40 id_table: pci_device_id_DevicePCI,
41 probe: device_probe,
42 remove: device_remove
43 };
44
45
46 int init_module(void)
47 {
48 //struct pci_dev *pdev = NULL;
49 int ret = 0;
50
51 pci_register_driver(&pci_driver_DevicePCI);
52
53 return ret;
54 }
55
56 void cleanup_module(void)
57 {
58 pci_unregister_driver(&pci_driver_DevicePCI);
59
60 }
61
62 #define REGISTER_OFFSET 0x05400
64 int device_probe(struct pci_dev *dev, const struct pci_device_id *id)
65 {
66 int ret;
67 int bar = 2; // Bar to be reserved
68 unsigned long io_base = 0;
69 unsigned long mem_len = 0;
70 unsigned int register_data = 0;
71
72 LOG("Device probed");
73
74 /* Reserve the access to PCI device */
75 ret = pci_request_region(dev, bar, "my_pci");
76 if (ret) {
77 printk(KERN_ERR "request region failed :%d\n", ret);
78 return ret;
79 }
80
81 ret = pci_enable_device(dev);
82 if (ret < 0 ) LOG("Failed while enabling ... ");
83
84 io_base = pci_resource_start(dev, bar);
85 mem_len = pci_resource_len(dev, bar);
86
87 request_region(io_base, mem_len, "my_pci");
88 register_data = inw(io_base + REGISTER_OFFSET);
89 printk(KERN_INFO "IO base = %lx", io_base);
90 printk(KERN_INFO "MAC = %x", register_data);
91
92 return ret;
93 }
94
95 void device_remove(struct pci_dev *dev)
96 {
97 pci_release_regions(dev);
98 pci_disable_device(dev);
99 }
100
lspci -x output of my card
00:08.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
00: 86 80 0e 10 07 00 30 02 02 00 00 02 00 40 00 00
10: 00 00 82 f0 00 00 00 00 41 d2 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 1e 00
30: 00 00 00 00 dc 00 00 00 00 00 00 00 09 01 ff 00
Can any one let me know what am i doing wrong?
I've modified your code and commented on changes. I have removed all of your existing comments to avoid confusion, and have only modified your probe function.
/* We need a place to store a logical address for unmapping later */
static void* logical_address;
int device_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
int ret;
int bar_mask; /* BAR mask (this variable) and the integer BAR */
int requested_bar = 2; /* (this variable) are not the same thing, so give them */
/* separate variables */
resource_size_t io_base = 0; /* use kernel macros instead of built-in datatypes */
resource_size_t mem_len = 0;
unsigned int register_data = 0;
LOG("Device probed");
/* add this call to get the correct BAR mask */
bar_mask = pci_select_bars(dev, 0);
/* switched order - enable device before requesting memory */
ret = pci_enable_device(dev);
if (ret < 0 ) LOG("Failed while enabling ... ");
/* for this call, we want to pass the BAR mask, NOT the integer bar we want */
ret = pci_request_region(dev, bar_mask, "my_pci");
if (ret) {
printk(KERN_ERR "request region failed :%d\n", ret);
return ret;
}
/* it is in THESE calls that we request a specific BAR */
io_base = pci_resource_start(dev, requested_bar);
mem_len = pci_resource_len(dev, requested_bar);
/* you don't need to request anything again, so get rid of this line: */
/* request_region(io_base, mem_len, "my_pci"); */
/* you're missing an important step: we need to translate the IO address
* to a kernel logical address that we can actually use. Add a call to
* ioremap()
*/
logical_address = ioremap(io_base, mem_len);
/* we need to use the logical address returned by ioremap(), not the physical
* address returned by resource_start
*/
register_data = inw(logical_address + REGISTER_OFFSET);
printk(KERN_INFO "IO base = %lx", io_base);
printk(KERN_INFO "MAC = %x", register_data);
return ret;
}
You will need to add a corresponding call to iounmap() in your device_remove() routine. Take a look at the Intel E100E driver source code for some good examples.