Safe mode: Difference between revisions

m
 
(10 intermediate revisions by 7 users not shown)
Line 6:
 
=={{header|6502 Assembly}}==
The 6502 itself has no safe mode. This is true for most assembly languages (except maybe the Big Two: x86 and ARM.)
 
=={{header|68000 Assembly}}==
There is a "Supervisor Mode", however there's really nothing stopping you from setting the supervisor flag to true if you can execute arbitrary code.
The 68000 itself has no safe mode. This is true for most assembly languages (except maybe the Big Two: x86 and ARM.)
 
=={{header|8080 Assembly}}==
The 8080 itself has no safe mode. This is true for most assembly languages (except maybe the Big Two: x86 and ARM.)
 
=={{header|8086 Assembly}}==
The 8086 itself has no safe mode. Protected Mode did not exist in the 16-bit x86 architecture, only "Real Mode."
 
=={{header|AWK}}==
<syntaxhighlight lang="awk">
<lang AWK>
# syntax: GAWK --sandbox -f SAFE_MODE.AWK
#
Line 37:
exit(0)
}
</syntaxhighlight>
</lang>
 
=={{header|C3}}==
The C3 compiler has a `--fast` and a `--safe` mode respectively. The latter, intended for development, enables a wide range of checks from out-of-bounds checks and null dereference checks to runtime contracts with full stacktraces.
 
<!-- == Free Pascal == -->
Line 47 ⟶ 50:
The easiest way to test this is to add the <CODE>--sandbox</CODE> option when starting Frink. This enforces the strictest sandboxing mode. Similarly, when creating a Frink interpreter from Java code, the most restrictive security can be enabled by calling its <CODE><I>Frink</I>.setRestrictiveSecurity(true)</CODE> method.
 
<langsyntaxhighlight lang="java">
frink.parser.Frink interp = new frink.parser.Frink();
interp.setRestrictiveSecurity(true);
</syntaxhighlight>
</lang>
 
Below are some operations that can be allowed/disallowed from a custom security manager. For most of these, the permission can be restricted to allow/disallow a ''particular'' file, URL, or class, or method:
Line 89 ⟶ 92:
'cgo' is Go's bridge to using C code. As such it is just as unsafe as writing C code directly.
 
=={{header|JsishJ}}==
The ''security level'' (default: 0) can be increased to 1 by executing:
<syntaxhighlight lang="j">(9!:25) 1</syntaxhighlight>
Afterwards, all verbs able to alter the environment outside J are prohibited. See the [https://code.jsoftware.com/wiki/Vocabulary/ErrorMessages#security J Community Wiki] for details regarding the restrictions.
 
=={{header|Jsish}}==
The '''jsish''' interpreter allows a '''-s''', '''--safe''' command line switch to restrict access to the file system.
 
For example, given '''safer.jsi''':
 
<langsyntaxhighlight lang="javascript">File.write('/tmp/safer-mode.txt', 'data line');</langsyntaxhighlight>
 
{{out}}
Line 115 ⟶ 122:
Some control is allowed over the restrictions provided by safer mode.
 
<langsyntaxhighlight lang="javascript">var interp1 = new Interp({isSafe:true, safeWriteDirs:['/tmp'], , safeReadDirs:['/tmp']});</langsyntaxhighlight>
 
=={{header|Julia}}==
Julia does not have a "sandbox" mode that restricts access to operating system resources such as files, since this is considered to be the province of the underlying operating system. Julia does have functions that handle underlying OS memory resources similar to C type pointers. Such functions, including <pre> unsafe_wrap unsafe_read unsafe_load unsafe_write unsafe_trunc unsafe_string unsafe_store! unsafe_copyto! </pre> are prefixed with "unsafe_" to indicate that a memory access fault could be generated if arguments to those functions are in error.
 
=={{header|Nim}}==
Nim doesn’t provide safe mode, but it make a distinction between safe and unsafe features. Safe features are those which cannot corrupt memory integrity while unsafe ones can.
 
There is currently no restrictions for using unsafe features, but a programmer should be aware that they must be used with care.
 
Here are some unsafe features:
 
* The ones dealing with raw memory and especially those using pointers. Note that Nim makes a difference between pointers which allow access to raw (untraced) memory and references which allow access to traced memory.
 
* Type casting which, contrary to type conversion, is a simple assignment of a new type without any conversion to make the value fully compatible with the new type.
 
* Using <code>cstring</code> variables as no index checking is performed when accessing an element.
 
* Inserting assembly instructions with the <code>asm</code> statement.
 
=={{header|Perl}}==
Line 197 ⟶ 222:
Regina REXX supports a '''--restricted''' command-line option, and embedded interpreters can also be set to run restricted. Many commands are disabled in this mode, including most access to hosted services. The intrinsic '''FUNCTION REXX()''' extension in GnuCOBOL defaults to restricted mode, and programmers must explicitly use '''FUNCTION REXX-UNRESTRICTED(script, args...)''' for access to the full REXX programming environment from that [[COBOL]] implementation.
 
<langsyntaxhighlight lang="cobol"> identification division.
program-id. rexxtrial.
 
Line 219 ⟶ 244:
display "No exception raised: " exception-status
goback.
end program rexxtrial.</langsyntaxhighlight>
 
{{out}}
Line 261 ⟶ 286:
 
=={{header|Z80 Assembly}}==
Has no safe mode.
The Z80 itself has no safe mode. This is true for most assembly languages (except maybe the Big Two: x86 and ARM.)
 
=={{header|zkl}}==
Line 267 ⟶ 292:
the system. Additionally, any program can load a program or
eval (compile and run) text.
 
=={{header|Zig}}==
Zig provides compilation mode settings for safety (`Debug` and `ReleaseSafe`) and code-block annotations (`@setRuntimeSafety`) to allow the user tight control of optimization and safety.
The list of checked safety properties and tooling to debug existing memory problems is extensive.
Computations at compiletime are unconditionally checked for those errors and memory problems.
 
Zig is optimized for compilation performance and thus will not include advanced shape analysis like Rust's borrow checker into the compilation phase or compromise on compilation performance for the necessary data.
Thus temporal memory safety and data race safety are not covered during compilation time analysis and must be tested,
ie with thread sanitizer, Valgrind and test allocator.
There are plans to offer upper bound stack- and uninitialized memory analysis.
4,102

edits