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

139 lines
4.7 KiB
Bash
Raw Normal View History

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
#!/bin/sh
remove trailing whitespace after the "created from: NetBSD..." line.
2005-02-27 02:55:49 +03:00
# $NetBSD: makemachservices.sh,v 1.6 2005/02/26 23:55:49 perry 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
#
# Copyright (c) 2003 The NetBSD Foundation, Inc.
# All rights reserved.
# This code is derived from software contributed to The NetBSD Foundation
# by Emmanuel Dreyfus.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# 3. All advertising materials mentioning features or use of this software
# must display the following acknowledgement:
# This product includes software developed by the NetBSD
# Foundation, Inc. and its contributors.
# 4. The name of the author may not be used to endorse or promote products
# derived from this software without specific prior written permission
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
# IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
# OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
# IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
# NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
# THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
master="mach_services.master"
table="mach_services.c"
headers="mach_services.h"
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
names="mach_services_names.c"
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
sed -e '
:join
/\\$/{a\
N
s/\\\n//
b join
}
' $master | awk '
BEGIN{
intable = 0;
table = "'$table'";
headers = "'$headers'";
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
names = "'$names'";
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
printf("/* \$NetBSD\$ *\/\n\n") > table;
printf("/*\n * Mach services table.\n *\n") > table;
printf(" * DO NOT EDIT -- this file is automatically generated.\n") > \
table;
printf("/* \$NetBSD\$ *\/\n\n") > headers;
printf("/*\n * Mach services prototypes.\n *\n") > headers;
printf(" * DO NOT EDIT -- this file is automatically generated.\n") > \
headers;
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
printf("/* \$NetBSD\$ *\/\n\n") > names;
printf("/*\n * Mach services names. This file is not built\n") > names;
printf(" * by the kernel, it is included by kdump sources.\n *\n") > \
names;
printf(" * DO NOT EDIT -- this file is automatically generated.\n") > \
Fix minor bug in the script that generate Mach services files (the master fie tag was not copied)
2003-11-30 03:09:59 +03:00
names;
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
}
(NR == 1) {
Fix minor bug in the script that generate Mach services files (the master fie tag was not copied)
2003-11-30 03:09:59 +03:00
gsub(/^[^\$]*\$/, "", $0);
gsub(/\$.*$/, "", $0);
remove trailing whitespace after the "created from: NetBSD..." line.
2005-02-27 02:55:49 +03:00
sub(/ $/, "");
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
printf(" * created from %s\n */\n\n", $0) > table;
printf("#include \<sys/cdefs.h\>\n__KERNEL_RCSID(0, " \
"\"\$NetBSD\$\");\n\n") > table;
printf(" * created from %s\n */\n\n", $0) > headers;
printf("#include \<sys/cdefs.h\>\n__KERNEL_RCSID(0, " \
"\"\$NetBSD\$\");\n\n") > headers;
printf("#include <compat/mach/mach_types.h>\n") > headers;
printf("#include <compat/mach/mach_message.h>\n") > headers;
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
printf(" * created from %s\n */\n\n", $0) > names;
printf("#include \<sys/cdefs.h\>\n__KERNEL_RCSID(0, " \
"\"\$NetBSD\$\");\n\n") > names;
printf("struct mach_service_name {\n") > names;
printf(" int srv_id;\n") > names;
printf(" const char *srv_name;\n") > names;
printf("};\n\n") > names;
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
next;
}
(NF == 0 || $1 ~ /^;/) {
next;
}
($0 ~ /^%%$/) {
intable = 1;
printf("\nstruct mach_service mach_services_table[] = {\n") > table;
printf("\n") > headers;
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
printf("struct mach_service_name mach_services_names[] = {\n") > names;
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
next;
}
(!intable) {
printf("%s\n", $0) > table;
next;
}
(intable && $2 == "STD") {
printf(" {%d, mach_%s, \"%s\", " \
"sizeof(mach_%s_request_t), sizeof(mach_%s_reply_t)},\n", \
$1, $3, $3, $3, $3) > table;
printf("int mach_%s(struct mach_trap_args *);\n", $3) > headers;
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
printf(" {%d, \"%s\"},\n", $1, $3) > names;
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
}
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
(intable && $2 == "NODEF") {
printf(" {%d, NULL, \"%s\", 0, 0},\n", \
$1, $3, $3, $3, $3) > table;
printf(" {%d, \"%s\"},\n", $1, $3) > names;
}
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
(intable && $2 == "UNIMPL") {
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
printf(" {%d, NULL, \"unimpl. %s\", 0, 0},\n", \
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
$1, $3, $3, $3, $3) > table;
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
printf(" {%d, \"unimpl. %s\"},\n", $1, $3) > names;
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
}
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
(intable && $2 == "OBSOL") {
printf(" {%d, NULL, \"obsolete %s\", 0, 0},\n", \
$1, $3, $3, $3, $3) > table;
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
printf(" {%d, \"obsolete %s\"},\n", $1, $3) > names;
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
}
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
END {
printf(" {0, NULL, NULL, 0, 0}\n") > table;
printf("};\n") > table;
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
printf(" {0, NULL}\n") > names;
printf("};\n") > names;
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
}
'