User Details
- User Since
- Jun 21 2022, 7:17 PM (128 w, 4 d)
Today
Thu, Dec 5
Thu, Nov 28
Add co-author
Oct 21 2024
Amend commit message
Fix indent
Oct 16 2024
Sep 30 2024
Use Makefile.crates
Sep 28 2024
Sep 18 2024
Elaborate commit message and manual
Sorry I cannot find other use case. Do you have any idea on the use case of raw tcp? Due to the unsafeness of raw TCP. We should use this feature in localhost. And because of the lack of terminal command in raw TCP support. It is much better to use modem device rather than raw tcp in localhost. So this feature actually is for proxy only (like OpenStack) because most of these applications implement raw tcp connection rather than modem device. But if we support telnet it will be useful because it is much simpler than modem device on configuration. I am planning to do so but we need this feature first because telnet is built upon tcp.
Hello, is there any update about this? Anyone want to merge this can use this to have direct patch.
Sep 11 2024
Use ::1 for safe ipv6 address
User 127.0.0.1 instead of 0.0.0.0 in manual
Sep 10 2024
For the 0.0.0.0 problem. I think we should fix it in the separated patch as we should also modify the VNC part.
Here is the branch that follows up the upstream modification of this patch:
Elaborate manual over TCP raw socket
Thanks for your feedback and here is the patch
Use warn instead of warnx on system call
Sep 9 2024
Fix some typo and double close
Sep 8 2024
Rebase and refactor comment
Sep 3 2024
Aug 22 2024
Prevent race condition in is_socket
- Add bhyve uart tcp backend
- Add manual page
Aug 21 2024
- Add bhyve uart tcp backend
- Add manual page
Aug 13 2024
@imp Hello, I found this needed feature in your idea list. Do you have any problem or feedback?
Aug 12 2024
Fix it
Comply with space style
Aug 9 2024
Add extra id for smbus
Aug 7 2024
Remove useless newline
Reduce double outside scale
Aug 6 2024
Apply clang-format
Rebase to main and make scale more obvious
Aug 5 2024
Backward competible implementation
Jul 31 2024
Jun 7 2024
So do you means we only aware of the incompatible kernel and don't implement similar check for kernel module?
I think you are right, I don't think about kernel problem. And in my opinion, it is the chicken-and-egg conundrum if we implemented it in a normal ELF way (rely on VMA of section) for kernel. But it is still a mitigation for driver developer when developing kernel module. Besides, we still need uuid_addr for relocatable kernel module. I have extract my patch to contain relocatable file handling only. So I think we should preserve this patch not merge it until finding a way to verify who is the correct kernel? (by extended the kernel dump header as you mentioned or something else?)
Jun 6 2024
Expose uuid for kernel module in kernel to prevent incompetable coredump loaded by debugger for relocatable file
But we cannot just rely on the file to tell use where the memory is because it maybe wrong after you compile the module. For relocatable file, you don't even have VMA to tell you where is the memory. We should use uuid_addr from kernel memory. This is why I think we should have build-id feature (The file loaded is different from the one statically resides in your file system)
Got it. Thanks for your response!
Just a question, how you test on kernel, I use spike --kernel /path/to/kernel /path/to/sbi. It give me invalid address error even after I add -m0x1000000,0x2000.
Update to 2024-05-31
Jun 5 2024
So should we divided our patch into amd64/arm64 for further discussion about two cases. Or divided the patch into kernel/loader?
Jun 3 2024
- Add bhyve uart tcp backend
- Add manual page
- Add bhyve uart tcp backend
- Add manual page
- Add bhyve uart tcp backend
- Add manual page
- Add bhyve uart tcp backend
- Add manual page
- Add bhyve uart tcp backend
- Add manual page
May 25 2024
- Add bhyve uart tcp backend
- Add manual page
I fix the previous error previously mentioned, and because uart_tcp_disconnect is a helper function and it parent has already lock it. I add comment to let everyone use this function in the future know this.
- Add bhyve uart tcp backend
- Add manual page
Reset commit because I use wrong ID
- Add bhyve uart tcp backend
- Add manual page
May 20 2024
Sorry about my late reply. The patch Ed commit is the pre-request to ensure my patch work. The logic of my patch is the loader would load the build-id from elf file in .gnu.note.build-id section into memory. When kernel crashed, it generate coredump and the build-id loaded from the loader will dump into the coredump file at the same time. After that, when debugger load kernel and it's coredump, the debugger will try to find the elf file of module and its debug file. We can compare the build-id from memory with elf file. If they are different, we shouldn't load the debug file (because they are incompatible).
May 11 2024
LLDB refer build-id as UUID. Sorry about the imprecise word.
After my investigation, I discover that shstrtab section is not loaded into memory (because no SHF_ALLOC). Thus I cannot compare the section name with ".note.gnu.build-id". Besides, in link_elf_link_preload, the function don't open the file as link_elf_load_file but use all of the memory and preload information from boot1. Thus if I want to compare the section name, I should load the file, create temp memory space for it, and read file. Does it worth to a file in kernel just for compare a section name?
I understand your point, I will try not to modify the loader.
Seperate to two patches
For preloaded relocatable kernel module, I think the modification of loader is necessary as I discover SHT_NOTE section was not loaded by boot1 originally when the kernel module is preloaded.
For shared object, actually we can get the address of uuid when kernel is loaded. I modify the loader because I discover that CTORS pass the information from loader and I think I should follow it?
- Add uuid for module to prevent incompetable coredump loaded by debugger
- Expose offset of uuid_addr and uuid_size in linker_file for debugger
May 8 2024
Abandon because I submit the new one.
Apr 26 2024
Fix it!
Check the result of calloc
Sorry I falsely create a duplicate patch...