Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/sys/compat/mach/mach_services.c

363 lines
26 KiB
C
Raw Normal View History

Regen to prove I didn't screw up the conversion: purely RCSID changes.
2009-01-14 01:33:08 +03:00
/* $NetBSD: mach_services.c,v 1.19 2009/01/13 22:33:10 pooka Exp $ */
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
/*
* Mach services table.
*
* DO NOT EDIT -- this file is automatically generated.
Regen to prove I didn't screw up the conversion: purely RCSID changes.
2009-01-14 01:33:08 +03:00
* created from NetBSD: mach_services.master,v 1.13 2005/12/11 12:20:20 christos Exp
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
*/
#include <sys/cdefs.h>
Regen to prove I didn't screw up the conversion: purely RCSID changes.
2009-01-14 01:33:08 +03:00
__KERNEL_RCSID(0, "$NetBSD: mach_services.c,v 1.19 2009/01/13 22:33:10 pooka Exp $");
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
#include <sys/types.h>
#include <sys/param.h>
#include <compat/mach/mach_types.h>
#include <compat/mach/mach_message.h>
#include <compat/mach/mach_bootstrap.h>
#include <compat/mach/mach_iokit.h>
#include <compat/mach/mach_clock.h>
#include <compat/mach/mach_host.h>
#include <compat/mach/mach_port.h>
#include <compat/mach/mach_task.h>
#include <compat/mach/mach_thread.h>
#include <compat/mach/mach_semaphore.h>
More work on exceptions. Once a task has raised an exception, it remains blocked in the kernel. The task that catched the exception may unblock it by sending a reply to the exception message (Of course it will have to change something so that the exception is not immediatly raised again). Handling of this reply is a bit complicated, as the kernel acts as the client instead of the server. In this situation, we receive a message but we will not send any reply (the message we receive is already a reply). I have not found anything better than a special case in mach_msg_overwrite_trap() to handle this. A surprise: exceptions ports are preserved accross forks. While we are there, use appropriate 64 bit types for make_memory_entry_64.
2003-11-18 04:40:18 +03:00
#include <compat/mach/mach_notify.h>
Move exception related code to a dedicated file
2003-12-09 15:13:44 +03:00
#include <compat/mach/mach_exception.h>
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
#include <compat/mach/mach_vm.h>
#include <compat/mach/mach_services.h>
struct mach_service mach_services_table[] = {
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
{64, NULL, "obsolete notify_first", 0, 0},
First work on Mach exceptions. Things that can turn into signals on UNIX may turn into exceptions on Mach: a small message sent by the kernel to the task that requested the exception. On Darwin, when an exception is sent, no signal can be delivered. TODO: more exceptions: arithmetic, bad instructions, emulation, s software, and syscalls (plain and Mach). There is also RPC alert, but I have no idea about what it is. While we are there, remove some user ktrace in notification code, and add a NODEF qualifier in mach_services.master: it will be used for notifications and exceptions, where the kernel is always client and never server: we don't want the message to be displayed as "unimplemented xxx" in kdump (thus UNIMPL is not good), but we don't want to generate the server prototype (therefore, STD is not good either). NODEF will declare it normally in the name tables without creating the prototype.
2003-11-17 04:52:14 +03:00
{65, NULL, "notify_port_deleted", 0, 0},
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
{66, NULL, "obsolete notify_msg_accepted", 0, 0},
{67, NULL, "obsolete notify_ownership_rights", 0, 0},
{68, NULL, "obsolete notify_receive_rights", 0, 0},
First work on Mach exceptions. Things that can turn into signals on UNIX may turn into exceptions on Mach: a small message sent by the kernel to the task that requested the exception. On Darwin, when an exception is sent, no signal can be delivered. TODO: more exceptions: arithmetic, bad instructions, emulation, s software, and syscalls (plain and Mach). There is also RPC alert, but I have no idea about what it is. While we are there, remove some user ktrace in notification code, and add a NODEF qualifier in mach_services.master: it will be used for notifications and exceptions, where the kernel is always client and never server: we don't want the message to be displayed as "unimplemented xxx" in kdump (thus UNIMPL is not good), but we don't want to generate the server prototype (therefore, STD is not good either). NODEF will declare it normally in the name tables without creating the prototype.
2003-11-17 04:52:14 +03:00
{69, NULL, "notify_port_destroyed", 0, 0},
{70, NULL, "notify_port_no_senders", 0, 0},
{71, NULL, "notify_port_send_once", 0, 0},
{72, NULL, "notify_port_dead_name", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{200, mach_host_info, "host_info", sizeof(mach_host_info_request_t), sizeof(mach_host_info_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{201, NULL, "unimpl. host_kernel_version", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{202, mach_host_page_size, "host_page_size", sizeof(mach_host_page_size_request_t), sizeof(mach_host_page_size_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{203, NULL, "unimpl. memory_object_memory_entry", 0, 0},
{204, NULL, "unimpl. host_processor_info", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{205, mach_host_get_io_master, "host_get_io_master", sizeof(mach_host_get_io_master_request_t), sizeof(mach_host_get_io_master_reply_t)},
{206, mach_host_get_clock_service, "host_get_clock_service", sizeof(mach_host_get_clock_service_request_t), sizeof(mach_host_get_clock_service_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{207, NULL, "unimpl. kmod_get_info", 0, 0},
{208, NULL, "unimpl. host_zone_info", 0, 0},
{209, NULL, "unimpl. host_virtual_physical_table_info", 0, 0},
{210, NULL, "unimpl. host_ipc_hash_info", 0, 0},
{211, NULL, "unimpl. enable_bluebox", 0, 0},
{212, NULL, "unimpl. disable_bluebox", 0, 0},
Added Mach services (no real implementation, just empty shells to make userland happy) processor_set_default, host_processor_set_priv, and thread_set_policy
2003-12-29 04:30:27 +03:00
{213, mach_processor_set_default, "processor_set_default", sizeof(mach_processor_set_default_request_t), sizeof(mach_processor_set_default_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{214, NULL, "unimpl. processor_set_create", 0, 0},
{215, NULL, "unimpl. memory_object_memory_entry_64", 0, 0},
{216, NULL, "unimpl. host_statistics", 0, 0},
{400, NULL, "unimpl. host_get_boot_info", 0, 0},
{401, NULL, "unimpl. host_reboot", 0, 0},
{402, NULL, "unimpl. host_priv_statistics", 0, 0},
Added port_get_refs and port_mod_refs
2004-07-24 19:46:02 +04:00
{403, NULL, "unimpl. boostrap_register", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{404, mach_bootstrap_look_up, "bootstrap_look_up", sizeof(mach_bootstrap_look_up_request_t), sizeof(mach_bootstrap_look_up_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{405, NULL, "unimpl. thread_wire", 0, 0},
{406, NULL, "unimpl. vm_allocate_cpm", 0, 0},
{407, NULL, "unimpl. host_processors", 0, 0},
{408, NULL, "unimpl. host_get_clock_control", 0, 0},
{409, NULL, "unimpl. kmod_create", 0, 0},
{410, NULL, "unimpl. kmod_destroy", 0, 0},
{411, NULL, "unimpl. kmod_control", 0, 0},
{412, NULL, "unimpl. host_get_special_port", 0, 0},
{413, NULL, "unimpl. host_set_special_port", 0, 0},
{414, NULL, "unimpl. host_set_exception_ports", 0, 0},
{415, NULL, "unimpl. host_get_exception_ports", 0, 0},
{416, NULL, "unimpl. host_swap_exception_ports", 0, 0},
{417, NULL, "unimpl. host_load_symbol_table", 0, 0},
{418, NULL, "unimpl. task_swappable", 0, 0},
{419, NULL, "unimpl. host_processor_sets", 0, 0},
Added Mach services (no real implementation, just empty shells to make userland happy) processor_set_default, host_processor_set_priv, and thread_set_policy
2003-12-29 04:30:27 +03:00
{420, mach_host_processor_set_priv, "host_processor_set_priv", sizeof(mach_host_processor_set_priv_request_t), sizeof(mach_host_processor_set_priv_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{421, NULL, "unimpl. set_dp_control_port", 0, 0},
{422, NULL, "unimpl. get_dp_control_port", 0, 0},
{423, NULL, "unimpl. host_set_UNDServer", 0, 0},
{424, NULL, "unimpl. host_get_UNDServer", 0, 0},
{600, NULL, "unimpl. host_security_create_task_token", 0, 0},
{601, NULL, "unimpl. host_security_set_task_token", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{1000, mach_clock_get_time, "clock_get_time", sizeof(mach_clock_get_time_request_t), sizeof(mach_clock_get_time_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{1001, NULL, "unimpl. clock_get_attributes", 0, 0},
{1002, NULL, "unimpl. clock_alarm", 0, 0},
{1200, NULL, "unimpl. clock_set_time", 0, 0},
{1201, NULL, "unimpl. clock_set_attributes", 0, 0},
{2000, NULL, "unimpl. memory_object_get_attributes", 0, 0},
{2001, NULL, "unimpl. memory_object_change_attributes", 0, 0},
{2002, NULL, "unimpl. memory_object_synchronize_completed", 0, 0},
{2003, NULL, "unimpl. memory_object_lock_request", 0, 0},
{2004, NULL, "unimpl. memory_object_destroy", 0, 0},
{2005, NULL, "unimpl. memory_object_upl_request", 0, 0},
{2006, NULL, "unimpl. memory_object_super_upl_request", 0, 0},
{2007, NULL, "unimpl. memory_object_page_op", 0, 0},
{2008, NULL, "unimpl. memory_object_recover_named", 0, 0},
{2009, NULL, "unimpl. memory_object_release_name", 0, 0},
{2050, NULL, "unimpl. upl_abort", 0, 0},
{2051, NULL, "unimpl. upl_abort_range", 0, 0},
{2052, NULL, "unimpl. upl_commit", 0, 0},
{2053, NULL, "unimpl. upl_commit_range", 0, 0},
{2200, NULL, "unimpl. memory_object_init", 0, 0},
{2201, NULL, "unimpl. memory_object_terminate", 0, 0},
{2202, NULL, "unimpl. memory_object_data_request", 0, 0},
{2203, NULL, "unimpl. memory_object_data_return", 0, 0},
{2204, NULL, "unimpl. memory_object_data_initialize", 0, 0},
{2205, NULL, "unimpl. memory_object_data_unlock", 0, 0},
{2206, NULL, "unimpl. memory_object_synchronize", 0, 0},
{2207, NULL, "unimpl. memory_object_unmap", 0, 0},
{2250, NULL, "unimpl. memory_object_create", 0, 0},
{2275, NULL, "unimpl. default_pager_object_create", 0, 0},
{2276, NULL, "unimpl. default_pager_info", 0, 0},
{2277, NULL, "unimpl. default_pager_objects", 0, 0},
{2278, NULL, "unimpl. default_pager_object_pages", 0, 0},
{2279, NULL, "unimpl. default_pager_backing_store_create", 0, 0},
{2280, NULL, "unimpl. default_pager_backing_store_delete", 0, 0},
{2281, NULL, "unimpl. default_pager_add_segment", 0, 0},
{2282, NULL, "unimpl. default_pager_backing_store_info", 0, 0},
{2283, NULL, "unimpl. default_pager_add_file", 0, 0},
{2284, NULL, "unimpl. default_pager_triggers", 0, 0},
{2295, NULL, "unimpl. default_pager_space_alert", 0, 0},
First work on Mach exceptions. Things that can turn into signals on UNIX may turn into exceptions on Mach: a small message sent by the kernel to the task that requested the exception. On Darwin, when an exception is sent, no signal can be delivered. TODO: more exceptions: arithmetic, bad instructions, emulation, s software, and syscalls (plain and Mach). There is also RPC alert, but I have no idea about what it is. While we are there, remove some user ktrace in notification code, and add a NODEF qualifier in mach_services.master: it will be used for notifications and exceptions, where the kernel is always client and never server: we don't want the message to be displayed as "unimplemented xxx" in kdump (thus UNIMPL is not good), but we don't want to generate the server prototype (therefore, STD is not good either). NODEF will declare it normally in the name tables without creating the prototype.
2003-11-17 04:52:14 +03:00
{2401, NULL, "exception_raise", 0, 0},
{2402, NULL, "exception_raise_state", 0, 0},
{2403, NULL, "exception_raise_state_identity", 0, 0},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{2450, NULL, "unimpl. samples", 0, 0},
{2451, NULL, "unimpl. notices", 0, 0},
More work on exceptions. Once a task has raised an exception, it remains blocked in the kernel. The task that catched the exception may unblock it by sending a reply to the exception message (Of course it will have to change something so that the exception is not immediatly raised again). Handling of this reply is a bit complicated, as the kernel acts as the client instead of the server. In this situation, we receive a message but we will not send any reply (the message we receive is already a reply). I have not found anything better than a special case in mach_msg_overwrite_trap() to handle this. A surprise: exceptions ports are preserved accross forks. While we are there, use appropriate 64 bit types for make_memory_entry_64.
2003-11-18 04:40:18 +03:00
{2501, mach_exception_raise, "exception_raise", sizeof(mach_exception_raise_request_t), sizeof(mach_exception_raise_reply_t)},
{2502, mach_exception_raise_state, "exception_raise_state", sizeof(mach_exception_raise_state_request_t), sizeof(mach_exception_raise_state_reply_t)},
{2503, mach_exception_raise_state_identity, "exception_raise_state_identity", sizeof(mach_exception_raise_state_identity_request_t), sizeof(mach_exception_raise_state_identity_reply_t)},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{2800, mach_io_object_get_class, "io_object_get_class", sizeof(mach_io_object_get_class_request_t), sizeof(mach_io_object_get_class_reply_t)},
{2801, mach_io_object_conforms_to, "io_object_conforms_to", sizeof(mach_io_object_conforms_to_request_t), sizeof(mach_io_object_conforms_to_reply_t)},
{2802, mach_io_iterator_next, "io_iterator_next", sizeof(mach_io_iterator_next_request_t), sizeof(mach_io_iterator_next_reply_t)},
{2803, mach_io_iterator_reset, "io_iterator_reset", sizeof(mach_io_iterator_reset_request_t), sizeof(mach_io_iterator_reset_reply_t)},
{2804, mach_io_service_get_matching_services, "io_service_get_matching_services", sizeof(mach_io_service_get_matching_services_request_t), sizeof(mach_io_service_get_matching_services_reply_t)},
{2805, mach_io_registry_entry_get_property, "io_registry_entry_get_property", sizeof(mach_io_registry_entry_get_property_request_t), sizeof(mach_io_registry_entry_get_property_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{2806, NULL, "unimpl. io_registry_create_iterator", 0, 0},
{2807, NULL, "unimpl. io_registry_iterator_enter_entry", 0, 0},
{2808, NULL, "unimpl. io_registry_iterator_exit_entry", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{2809, mach_io_registry_entry_from_path, "io_registry_entry_from_path", sizeof(mach_io_registry_entry_from_path_request_t), sizeof(mach_io_registry_entry_from_path_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{2810, NULL, "unimpl. io_registry_entry_get_name", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{2811, mach_io_registry_entry_get_properties, "io_registry_entry_get_properties", sizeof(mach_io_registry_entry_get_properties_request_t), sizeof(mach_io_registry_entry_get_properties_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{2812, NULL, "unimpl. io_registry_entry_get_property_bytes", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{2813, mach_io_registry_entry_get_child_iterator, "io_registry_entry_get_child_iterator", sizeof(mach_io_registry_entry_get_child_iterator_request_t), sizeof(mach_io_registry_entry_get_child_iterator_reply_t)},
{2814, mach_io_registry_entry_get_parent_iterator, "io_registry_entry_get_parent_iterator", sizeof(mach_io_registry_entry_get_parent_iterator_request_t), sizeof(mach_io_registry_entry_get_parent_iterator_reply_t)},
{2815, mach_io_service_open, "io_service_open", sizeof(mach_io_service_open_request_t), sizeof(mach_io_service_open_reply_t)},
{2816, mach_io_service_close, "io_service_close", sizeof(mach_io_service_close_request_t), sizeof(mach_io_service_close_reply_t)},
{2817, mach_io_connect_get_service, "io_connect_get_service", sizeof(mach_io_connect_get_service_request_t), sizeof(mach_io_connect_get_service_reply_t)},
{2818, mach_io_connect_set_notification_port, "io_connect_set_notification_port", sizeof(mach_io_connect_set_notification_port_request_t), sizeof(mach_io_connect_set_notification_port_reply_t)},
{2819, mach_io_connect_map_memory, "io_connect_map_memory", sizeof(mach_io_connect_map_memory_request_t), sizeof(mach_io_connect_map_memory_reply_t)},
{2820, mach_io_connect_add_client, "io_connect_add_client", sizeof(mach_io_connect_add_client_request_t), sizeof(mach_io_connect_add_client_reply_t)},
{2821, mach_io_connect_set_properties, "io_connect_set_properties", sizeof(mach_io_connect_set_properties_request_t), sizeof(mach_io_connect_set_properties_reply_t)},
{2822, mach_io_connect_method_scalari_scalaro, "io_connect_method_scalari_scalaro", sizeof(mach_io_connect_method_scalari_scalaro_request_t), sizeof(mach_io_connect_method_scalari_scalaro_reply_t)},
{2823, mach_io_connect_method_scalari_structo, "io_connect_method_scalari_structo", sizeof(mach_io_connect_method_scalari_structo_request_t), sizeof(mach_io_connect_method_scalari_structo_reply_t)},
{2824, mach_io_connect_method_scalari_structi, "io_connect_method_scalari_structi", sizeof(mach_io_connect_method_scalari_structi_request_t), sizeof(mach_io_connect_method_scalari_structi_reply_t)},
{2825, mach_io_connect_method_structi_structo, "io_connect_method_structi_structo", sizeof(mach_io_connect_method_structi_structo_request_t), sizeof(mach_io_connect_method_structi_structo_reply_t)},
{2826, mach_io_registry_entry_get_path, "io_registry_entry_get_path", sizeof(mach_io_registry_entry_get_path_request_t), sizeof(mach_io_registry_entry_get_path_reply_t)},
{2827, mach_io_registry_get_root_entry, "io_registry_get_root_entry", sizeof(mach_io_registry_get_root_entry_request_t), sizeof(mach_io_registry_get_root_entry_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{2828, NULL, "unimpl. io_registry_entry_set_properties", 0, 0},
{2829, NULL, "unimpl. io_registry_entry_in_plane", 0, 0},
{2830, NULL, "unimpl. io_object_get_retain_count", 0, 0},
{2831, NULL, "unimpl. io_service_get_busy_state", 0, 0},
{2832, NULL, "unimpl. io_service_wait_quiet", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{2833, mach_io_registry_entry_create_iterator, "io_registry_entry_create_iterator", sizeof(mach_io_registry_entry_create_iterator_request_t), sizeof(mach_io_registry_entry_create_iterator_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{2834, NULL, "unimpl. io_iterator_is_valid", 0, 0},
{2835, NULL, "unimpl. io_make_matching", 0, 0},
{2836, NULL, "unimpl. io_catalog_send_data", 0, 0},
{2837, NULL, "unimpl. io_catalog_terminate", 0, 0},
{2838, NULL, "unimpl. io_catalog_get_data", 0, 0},
{2839, NULL, "unimpl. io_catalog_get_gen_count", 0, 0},
{2840, NULL, "unimpl. io_catalog_module_loaded", 0, 0},
{2841, NULL, "unimpl. io_catalog_reset", 0, 0},
{2842, NULL, "unimpl. io_service_request_probe", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{2843, mach_io_registry_entry_get_name_in_plane, "io_registry_entry_get_name_in_plane", sizeof(mach_io_registry_entry_get_name_in_plane_request_t), sizeof(mach_io_registry_entry_get_name_in_plane_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{2844, NULL, "unimpl. io_service_match_property_table", 0, 0},
{2845, NULL, "unimpl. io_async_method_scalari_scalaro", 0, 0},
{2846, NULL, "unimpl. io_async_method_scalari_structo", 0, 0},
{2847, NULL, "unimpl. io_async_method_scalari_structi", 0, 0},
{2848, NULL, "unimpl. io_async_method_structi_structo", 0, 0},
{2849, NULL, "unimpl. io_service_add_notification", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{2850, mach_io_service_add_interest_notification, "io_service_add_interest_notification", sizeof(mach_io_service_add_interest_notification_request_t), sizeof(mach_io_service_add_interest_notification_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{2851, NULL, "unimpl. io_service_acknowledge_notification", 0, 0},
{2852, NULL, "unimpl. io_connect_get_notification_semaphore", 0, 0},
{2853, NULL, "unimpl. io_connect_unmap_memory", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{2854, mach_io_registry_entry_get_location_in_plane, "io_registry_entry_get_location_in_plane", sizeof(mach_io_registry_entry_get_location_in_plane_request_t), sizeof(mach_io_registry_entry_get_location_in_plane_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{2855, NULL, "unimpl. io_registry_entry_get_property_recursively", 0, 0},
{3000, NULL, "unimpl. processor_start", 0, 0},
{3001, NULL, "unimpl. processor_exit", 0, 0},
{3002, NULL, "unimpl. processor_info", 0, 0},
{3003, NULL, "unimpl. processor_control", 0, 0},
{3004, NULL, "unimpl. processor_assign", 0, 0},
{3005, NULL, "unimpl. processor_get_assignment", 0, 0},
{3200, NULL, "unimpl. port_names", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3201, mach_port_type, "port_type", sizeof(mach_port_type_request_t), sizeof(mach_port_type_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3202, NULL, "unimpl. port_rename", 0, 0},
{3203, NULL, "unimpl. port_allocate_name", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3204, mach_port_allocate, "port_allocate", sizeof(mach_port_allocate_request_t), sizeof(mach_port_allocate_reply_t)},
{3205, mach_port_destroy, "port_destroy", sizeof(mach_port_destroy_request_t), sizeof(mach_port_destroy_reply_t)},
{3206, mach_port_deallocate, "port_deallocate", sizeof(mach_port_deallocate_request_t), sizeof(mach_port_deallocate_reply_t)},
Added port_get_refs and port_mod_refs
2004-07-24 19:46:02 +04:00
{3207, mach_port_get_refs, "port_get_refs", sizeof(mach_port_get_refs_request_t), sizeof(mach_port_get_refs_reply_t)},
{3208, mach_port_mod_refs, "port_mod_refs", sizeof(mach_port_mod_refs_request_t), sizeof(mach_port_mod_refs_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3210, NULL, "unimpl. port_set_mscount", 0, 0},
{3211, NULL, "unimpl. port_get_set_status", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3212, mach_port_move_member, "port_move_member", sizeof(mach_port_move_member_request_t), sizeof(mach_port_move_member_reply_t)},
{3213, mach_port_request_notification, "port_request_notification", sizeof(mach_port_request_notification_request_t), sizeof(mach_port_request_notification_reply_t)},
{3214, mach_port_insert_right, "port_insert_right", sizeof(mach_port_insert_right_request_t), sizeof(mach_port_insert_right_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3215, NULL, "unimpl. port_extract_right", 0, 0},
{3216, NULL, "unimpl. port_set_seqno", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3217, mach_port_get_attributes, "port_get_attributes", sizeof(mach_port_get_attributes_request_t), sizeof(mach_port_get_attributes_reply_t)},
{3218, mach_port_set_attributes, "port_set_attributes", sizeof(mach_port_set_attributes_request_t), sizeof(mach_port_set_attributes_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3219, NULL, "unimpl. port_allocate_qos", 0, 0},
{3220, NULL, "unimpl. port_allocate_full", 0, 0},
{3221, NULL, "unimpl. task_set_port_space", 0, 0},
{3222, NULL, "unimpl. port_get_srights", 0, 0},
{3223, NULL, "unimpl. port_space_info", 0, 0},
{3224, NULL, "unimpl. port_dnrequest_info", 0, 0},
{3225, NULL, "unimpl. port_kernel_object", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3226, mach_port_insert_member, "port_insert_member", sizeof(mach_port_insert_member_request_t), sizeof(mach_port_insert_member_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3227, NULL, "unimpl. port_extract_member", 0, 0},
{3400, NULL, "unimpl. task_create", 0, 0},
Add task_terminate
2003-11-30 23:42:03 +03:00
{3401, mach_task_terminate, "task_terminate", sizeof(mach_task_terminate_request_t), sizeof(mach_task_terminate_reply_t)},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3402, mach_task_threads, "task_threads", sizeof(mach_task_threads_request_t), sizeof(mach_task_threads_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3403, NULL, "unimpl. ports_register", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3404, mach_ports_lookup, "ports_lookup", sizeof(mach_ports_lookup_request_t), sizeof(mach_ports_lookup_reply_t)},
{3405, mach_task_info, "task_info", sizeof(mach_task_info_request_t), sizeof(mach_task_info_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3406, NULL, "unimpl. task_set_info", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3407, mach_task_suspend, "task_suspend", sizeof(mach_task_suspend_request_t), sizeof(mach_task_suspend_reply_t)},
{3408, mach_task_resume, "task_resume", sizeof(mach_task_resume_request_t), sizeof(mach_task_resume_reply_t)},
{3409, mach_task_get_special_port, "task_get_special_port", sizeof(mach_task_get_special_port_request_t), sizeof(mach_task_get_special_port_reply_t)},
{3410, mach_task_set_special_port, "task_set_special_port", sizeof(mach_task_set_special_port_request_t), sizeof(mach_task_set_special_port_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3411, NULL, "unimpl. thread_create", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3412, mach_thread_create_running, "thread_create_running", sizeof(mach_thread_create_running_request_t), sizeof(mach_thread_create_running_reply_t)},
{3413, mach_task_set_exception_ports, "task_set_exception_ports", sizeof(mach_task_set_exception_ports_request_t), sizeof(mach_task_set_exception_ports_reply_t)},
{3414, mach_task_get_exception_ports, "task_get_exception_ports", sizeof(mach_task_get_exception_ports_request_t), sizeof(mach_task_get_exception_ports_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3415, NULL, "unimpl. task_swap_exception_ports", 0, 0},
{3416, NULL, "unimpl. lock_set_create", 0, 0},
{3417, NULL, "unimpl. lock_set_destroy", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3418, mach_semaphore_create, "semaphore_create", sizeof(mach_semaphore_create_request_t), sizeof(mach_semaphore_create_reply_t)},
{3419, mach_semaphore_destroy, "semaphore_destroy", sizeof(mach_semaphore_destroy_request_t), sizeof(mach_semaphore_destroy_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3420, NULL, "unimpl. task_policy_set", 0, 0},
{3421, NULL, "unimpl. task_policy_get", 0, 0},
{3422, NULL, "unimpl. task_sample", 0, 0},
{3423, NULL, "unimpl. task_policy", 0, 0},
{3424, NULL, "unimpl. task_set_emulation", 0, 0},
{3425, NULL, "unimpl. task_get_emulation_vector", 0, 0},
{3426, NULL, "unimpl. task_set_emulation_vector", 0, 0},
{3427, NULL, "unimpl. task_set_ras_pc", 0, 0},
{3428, NULL, "unimpl. kernel_task_create", 0, 0},
{3429, NULL, "unimpl. task_assign", 0, 0},
{3430, NULL, "unimpl. task_assign_default", 0, 0},
{3431, NULL, "unimpl. task_get_assignment", 0, 0},
{3432, NULL, "unimpl. task_set_policy", 0, 0},
{3600, NULL, "unimpl. thread_terminate", 0, 0},
{3601, NULL, "unimpl. act_get_state", 0, 0},
{3602, NULL, "unimpl. act_set_state", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3603, mach_thread_get_state, "thread_get_state", sizeof(mach_thread_get_state_request_t), sizeof(mach_thread_get_state_reply_t)},
{3604, mach_thread_set_state, "thread_set_state", sizeof(mach_thread_set_state_request_t), sizeof(mach_thread_set_state_reply_t)},
Rework Mach exception and Darwin's ptrace. gdb is now able to attach a remote process. This new implementation also passes all the test programs I've written so far. - When exceptions come from traps, no UNIX signal should evet be sent. - Add a lock to ensure a debugger handles only one exception at a time - Use a structure to hold flavor and behavior in exception ports, instead of stuffing the two argument into an int. - Implement new Mach services: thread_suspend, thread_resume and thread_abort - Implement Darwin's ptrace PT_ATTACHEXC and PT_THUPDATE commands - Handle NULL second argument correctly in sigprocmask. - One mistake in the last commit (darwin_tracesig prototype)
2003-12-25 02:22:22 +03:00
{3605, mach_thread_suspend, "thread_suspend", sizeof(mach_thread_suspend_request_t), sizeof(mach_thread_suspend_reply_t)},
{3606, mach_thread_resume, "thread_resume", sizeof(mach_thread_resume_request_t), sizeof(mach_thread_resume_reply_t)},
{3607, mach_thread_abort, "thread_abort", sizeof(mach_thread_abort_request_t), sizeof(mach_thread_abort_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3608, NULL, "unimpl. thread_abort_safely", 0, 0},
{3609, NULL, "unimpl. thread_depress_abort", 0, 0},
{3610, NULL, "unimpl. thread_get_special_port", 0, 0},
{3611, NULL, "unimpl. thread_set_special_port", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3612, mach_thread_info, "thread_info", sizeof(mach_thread_info_request_t), sizeof(mach_thread_info_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3613, NULL, "unimpl. thread_set_exception_ports", 0, 0},
{3614, NULL, "unimpl. thread_get_exception_ports", 0, 0},
{3615, NULL, "unimpl. thread_swap_exception_ports", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3616, mach_thread_policy, "thread_policy", sizeof(mach_thread_policy_request_t), sizeof(mach_thread_policy_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3617, NULL, "unimpl. thread_policy_set", 0, 0},
{3618, NULL, "unimpl. thread_policy_get", 0, 0},
{3619, NULL, "unimpl. thread_sample", 0, 0},
{3620, NULL, "unimpl. etap_trace_thread", 0, 0},
{3621, NULL, "unimpl. thread_assign", 0, 0},
{3622, NULL, "unimpl. thread_assign_default", 0, 0},
{3623, NULL, "unimpl. thread_get_assignment", 0, 0},
Added Mach services (no real implementation, just empty shells to make userland happy) processor_set_default, host_processor_set_priv, and thread_set_policy
2003-12-29 04:30:27 +03:00
{3624, mach_thread_set_policy, "thread_set_policy", sizeof(mach_thread_set_policy_request_t), sizeof(mach_thread_set_policy_reply_t)},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3800, mach_vm_region, "vm_region", sizeof(mach_vm_region_request_t), sizeof(mach_vm_region_reply_t)},
{3801, mach_vm_allocate, "vm_allocate", sizeof(mach_vm_allocate_request_t), sizeof(mach_vm_allocate_reply_t)},
{3802, mach_vm_deallocate, "vm_deallocate", sizeof(mach_vm_deallocate_request_t), sizeof(mach_vm_deallocate_reply_t)},
{3803, mach_vm_protect, "vm_protect", sizeof(mach_vm_protect_request_t), sizeof(mach_vm_protect_reply_t)},
{3804, mach_vm_inherit, "vm_inherit", sizeof(mach_vm_inherit_request_t), sizeof(mach_vm_inherit_reply_t)},
Implement vm_read, vm_write, and a framework for vm_machine_attribute. THe machine dependent bit nees to be written.
2003-11-30 02:56:08 +03:00
{3805, mach_vm_read, "vm_read", sizeof(mach_vm_read_request_t), sizeof(mach_vm_read_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3806, NULL, "unimpl. vm_read_list", 0, 0},
Implement vm_read, vm_write, and a framework for vm_machine_attribute. THe machine dependent bit nees to be written.
2003-11-30 02:56:08 +03:00
{3807, mach_vm_write, "vm_write", sizeof(mach_vm_write_request_t), sizeof(mach_vm_write_reply_t)},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3808, mach_vm_copy, "vm_copy", sizeof(mach_vm_copy_request_t), sizeof(mach_vm_copy_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3809, NULL, "unimpl. vm_read_overwrite", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3810, mach_vm_msync, "vm_msync", sizeof(mach_vm_msync_request_t), sizeof(mach_vm_msync_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3811, NULL, "unimpl. vm_behavior_set", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3812, mach_vm_map, "vm_map", sizeof(mach_vm_map_request_t), sizeof(mach_vm_map_reply_t)},
Implement vm_read, vm_write, and a framework for vm_machine_attribute. THe machine dependent bit nees to be written.
2003-11-30 02:56:08 +03:00
{3813, mach_vm_machine_attribute, "vm_machine_attribute", sizeof(mach_vm_machine_attribute_request_t), sizeof(mach_vm_machine_attribute_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3814, NULL, "unimpl. vm_remap", 0, 0},
{3815, NULL, "unimpl. task_wire", 0, 0},
{3816, NULL, "unimpl. make_memory_entry", 0, 0},
{3817, NULL, "unimpl. vm_map_page_query", 0, 0},
{3818, NULL, "unimpl. vm_region_info", 0, 0},
{3819, NULL, "unimpl. vm_mapped_pages_info", 0, 0},
{3820, NULL, "unimpl. vm_region_object_create", 0, 0},
{3821, NULL, "unimpl. vm_region_recurse", 0, 0},
{3822, NULL, "unimpl. vm_region_recurse_64", 0, 0},
{3823, NULL, "unimpl. vm_region_info_64", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{3824, mach_vm_region_64, "vm_region_64", sizeof(mach_vm_region_64_request_t), sizeof(mach_vm_region_64_reply_t)},
Try to add all mach servers defined in Darwin in the server list. Most of them will never be implemented, of course.
2003-11-15 20:44:38 +03:00
{3825, mach_make_memory_entry_64, "make_memory_entry_64", sizeof(mach_make_memory_entry_64_request_t), sizeof(mach_make_memory_entry_64_reply_t)},
iTry to gather as much Mach services names as possible, this way we will have unimplemented services showing their names in ktrace Add a new generated file with only service id and name, which will be included by kdump to display services names. This removes the need for using the user ktrace facility for services names.
2003-11-16 01:55:35 +03:00
{3826, NULL, "unimpl. vm_map_64", 0, 0},
{3827, NULL, "unimpl. vm_map_get_upl", 0, 0},
{3828, NULL, "unimpl. vm_upl_map", 0, 0},
{3829, NULL, "unimpl. vm_upl_unmap", 0, 0},
{4000, NULL, "unimpl. processor_set_statistics", 0, 0},
{4001, NULL, "unimpl. processor_set_destroy", 0, 0},
{4002, NULL, "unimpl. processor_set_max_priority", 0, 0},
{4003, NULL, "unimpl. processor_set_policy_enable", 0, 0},
{4004, NULL, "unimpl. processor_set_policy_disable", 0, 0},
{4005, NULL, "unimpl. processor_set_tasks", 0, 0},
{4006, NULL, "unimpl. processor_set_threads", 0, 0},
{4007, NULL, "unimpl. processor_set_policy_control", 0, 0},
{4008, NULL, "unimpl. processor_set_stack_usage", 0, 0},
{4009, NULL, "unimpl. processor_set_info", 0, 0},
{5000, NULL, "unimpl. ledger_create", 0, 0},
{5001, NULL, "unimpl. ledger_terminate", 0, 0},
{5002, NULL, "unimpl. ledger_transfer", 0, 0},
{5003, NULL, "unimpl. ledger_read", 0, 0},
{6000, NULL, "unimpl. und_execute_rpc", 0, 0},
{6001, NULL, "unimpl. und_display_notice_from_bundle_rpc", 0, 0},
{6002, NULL, "unimpl. und_display_alert_from_bundle_rpc", 0, 0},
{6003, NULL, "unimpl. und_display_custom_from_bundle_rpc", 0, 0},
{6004, NULL, "unimpl. und_display_custom_from_dictionary_rpc", 0, 0},
{6005, NULL, "unimpl. und_cancel_notification_rpc", 0, 0},
{6006, NULL, "unimpl. und_display_notice_simple_rpc", 0, 0},
{6007, NULL, "unimpl. und_display_alert_simple_rpc", 0, 0},
{6200, NULL, "unimpl. und_alert_completed_with_result_rpc", 0, 0},
{6201, NULL, "unimpl. und_notification_created_rpc(", 0, 0},
{555001, NULL, "unimpl. task_set_child_node", 0, 0},
{555002, NULL, "unimpl. norma_node_self", 0, 0},
{555005, NULL, "unimpl. norma_task_clone", 0, 0},
{555006, NULL, "unimpl. norma_task_create", 0, 0},
{555007, NULL, "unimpl. norma_get_special_port", 0, 0},
{555008, NULL, "unimpl. norma_set_special_port", 0, 0},
{555009, NULL, "unimpl. norma_task_teleport", 0, 0},
{555012, NULL, "unimpl. norma_port_location_hint", 0, 0},
{617000, NULL, "unimpl. lock_acquire", 0, 0},
{617001, NULL, "unimpl. lock_release", 0, 0},
{617002, NULL, "unimpl. lock_try", 0, 0},
{617003, NULL, "unimpl. lock_make_stable", 0, 0},
{617004, NULL, "unimpl. lock_handoff", 0, 0},
{617005, NULL, "unimpl. lock_handoff_accept", 0, 0},
{617005, NULL, "unimpl. lock_set_create", 0, 0},
{617006, NULL, "unimpl. lock_set_destroy", 0, 0},
{617007, NULL, "unimpl. lock_acquire", 0, 0},
{617008, NULL, "unimpl. lock_release", 0, 0},
{617009, NULL, "unimpl. lock_try", 0, 0},
{617010, NULL, "unimpl. lock_make_stable", 0, 0},
{617011, NULL, "unimpl. lock_handoff", 0, 0},
{617012, NULL, "unimpl. lock_handoff_accept", 0, 0},
{617200, NULL, "unimpl. semaphore_signal", 0, 0},
{617201, NULL, "unimpl. semaphore_signal_all", 0, 0},
{617202, NULL, "unimpl. semaphore_wait", 0, 0},
{617203, NULL, "unimpl. semaphore_signal_thread", 0, 0},
{617204, NULL, "unimpl. semaphore_timedwait", 0, 0},
{617205, NULL, "unimpl. semaphore_wait_signal", 0, 0},
{617206, NULL, "unimpl. semaphore_timedwait_signal", 0, 0},
Enforce good santity checks with Mach messages sizes: 1) make sure Mach servers will not work on data beyond the end of the request message buffer. 2) make sure that on copying out the reply message buffer, we will not leak kernel data located after the buffer. 3) make sure that the server will not overwrite memory beyond the end of the reply message buffer. That check is the responsability of the server, there is just a DIAGNOSTIC test to check everything is in good shape. All currently implemented servers in NetBSD have been modified to check for this condition While we are here, build the mach services table (formerly in mach_namemap.c) and the services prototypes automatically from mach_services.master, just as this is done for system calls. The next step would be to fold the message formats in the mach_services.master file, but this tends to be difficult, as some messages are quite long and complex.
2003-11-13 16:40:39 +03:00
{0, NULL, NULL, 0, 0}
};