-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[LibOS] Add sys.debug__mock_syscalls = [ ... ]
manifest option
#1859
Conversation
sys.disallowed_syscalls = [ ... ]
manifest optionsys.disallowed_syscalls = [ ... ]
manifest option
0504ab3
to
cf686d2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 12 files reviewed, 2 unresolved discussions, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: Intel)
a discussion (no related file):
This is a patch that I was experimenting with (for reasons not relevant to this PR). I decided to create the PR out of what I have. No idea if this is useful... Any feedback welcome.
Documentation/manifest-syntax.rst
line 397 at r1 (raw file):
:: sgx.disallowed_syscalls = [
Alternatives:
- Provide an allowlist
sys.allowed_syscalls = [ ... ]
. This will be more security-expected and more in line with e.g. seccomp profiles. Downside: much harder for end users. - Provide both this denylist and the allowlist manifest options. At init time, Gramine fails if detects them both.
cf686d2
to
8820f10
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 12 files reviewed, 3 unresolved discussions, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: Intel)
Documentation/manifest-syntax.rst
line 399 at r2 (raw file):
sys.disallowed_syscalls = [ "syscall_name", "syscall_name",
One additional option would be to not simply return -ENOSYS
, but allow to specify what int to return:
sys.fixed_syscalls = [
{ name = "syscall_name1", return = -38}, # returns -ENOSYS
{ name = "syscall_name2", return = 0}, # returns 0, i.e. dummy impl
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 12 files reviewed, 9 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @dimakuv)
Documentation/manifest-syntax.rst
line 397 at r2 (raw file):
:: sys.disallowed_syscalls = [
Should this also be read from a file similarly?
libos/src/libos_parser.c
line 1653 at r2 (raw file):
unsigned long get_syscall_number(const char* name) { assert(LIBOS_SYSCALL_BOUND == ARRAY_SIZE(syscall_parser_table));
Shouldn't this be a static_assert beyond this function?
libos/src/libos_parser.c
line 1658 at r2 (raw file):
if (!syscall_parser_table[i].name) continue; if (strcmp(name, syscall_parser_table[i].name) == 0) {
Do we need sysno
?
if (strcmp(name, syscall_parser_table[i].name) == 0) {
return i;
}
...
return LIBOS_SYSCALL_BOUND;
}
Also shouldn't this indicate the error more clearly?
libos/src/libos_syscalls.c
line 114 at r2 (raw file):
if (!toml_disallowed_syscall_raw) { log_error("Invalid disallowed syscall in manifest at index %ld", i); return -EINVAL;
goto after return?
libos/src/libos_syscalls.c
line 121 at r2 (raw file):
if (ret < 0) { log_error("Invalid disallowed syscall in manifest at index %ld (not a string)", i); return -EINVAL;
ditto
libos/src/libos_syscalls.c
line 129 at r2 (raw file):
log_error("Unrecognized disallowed syscall `%s` in manifest at index %ld", toml_disallowed_syscall_str, i); return -EINVAL;
ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 12 files reviewed, 9 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @oshogbo)
Documentation/manifest-syntax.rst
line 397 at r2 (raw file):
Previously, oshogbo (Mariusz Zaborski) wrote…
Should this also be read from a file similarly?
What would be the benefit of having these syscalls in a separate file, rather than directly in the manifest?
libos/src/libos_parser.c
line 1653 at r2 (raw file):
Previously, oshogbo (Mariusz Zaborski) wrote…
Shouldn't this be a static_assert beyond this function?
Done partially. It indeed needs to be a static assert, but I don't know what you mean by "beyond this function". I add this assert here to make it clear to readers that these two are the same limits.
libos/src/libos_parser.c
line 1658 at r2 (raw file):
Previously, oshogbo (Mariusz Zaborski) wrote…
Do we need
sysno
?if (strcmp(name, syscall_parser_table[i].name) == 0) { return i; } ... return LIBOS_SYSCALL_BOUND; }
Also shouldn't this indicate the error more clearly?
Done partially.
What do you mean by "indicate the error more clearly"? Replace with int get_syscall_number(const char* name, unsigned long* out_sysno)
? I can do it, though the current version looked sufficiently clear to me.
libos/src/libos_syscalls.c
line 114 at r2 (raw file):
Previously, oshogbo (Mariusz Zaborski) wrote…
goto after return?
Done.
libos/src/libos_syscalls.c
line 121 at r2 (raw file):
Previously, oshogbo (Mariusz Zaborski) wrote…
ditto
Done.
libos/src/libos_syscalls.c
line 129 at r2 (raw file):
Previously, oshogbo (Mariusz Zaborski) wrote…
ditto
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 12 files reviewed, 4 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @dimakuv)
Documentation/manifest-syntax.rst
line 397 at r2 (raw file):
Previously, dimakuv (Dmitrii Kuvaiskii) wrote…
What would be the benefit of having these syscalls in a separate file, rather than directly in the manifest?
I was thinking about docker seccomp policies, and they are mainly defined as an outside file. So my idea was that somebody might want to define a more generic policy. But this was just a random idea.
libos/src/libos_parser.c
line 1653 at r2 (raw file):
Previously, dimakuv (Dmitrii Kuvaiskii) wrote…
Done partially. It indeed needs to be a static assert, but I don't know what you mean by "beyond this function". I add this assert here to make it clear to readers that these two are the same limits.
"Beyond this function" I thought about doing it above or where the syscall_parse_table/IBOS_SYSCALL_BOUND is defined. But here makes sense as well.
libos/src/libos_parser.c
line 1658 at r2 (raw file):
Previously, dimakuv (Dmitrii Kuvaiskii) wrote…
Done partially.
What do you mean by "indicate the error more clearly"? Replace with
int get_syscall_number(const char* name, unsigned long* out_sysno)
? I can do it, though the current version looked sufficiently clear to me.
Yes, my idea was to not use a LIBOS_SYSCALL_BOUND as a error msg, as the name does not suggest that something went wrong. And doing it as you proposed. Your decision.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 12 files reviewed, 4 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @oshogbo)
Documentation/manifest-syntax.rst
line 397 at r2 (raw file):
I was thinking about docker seccomp policies, and they are mainly defined as an outside file.
That's simply because there is no "main configuration file" in Docker. Gramine on the other side has such a file, so seems reasonable to put all the configuration in one file. (The only potential exceptions are envvars and cmdline args, but that's because they may be sent in encrypted form.)
libos/src/libos_parser.c
line 1653 at r2 (raw file):
Previously, oshogbo (Mariusz Zaborski) wrote…
"Beyond this function" I thought about doing it above or where the syscall_parse_table/IBOS_SYSCALL_BOUND is defined. But here makes sense as well.
I looked at where else I can easily add this static_assert
, but I don't see another good place:
- in
libos_parser.c
: it's already obvious that the size of the table is equal to the bound (from array definition) - in
libos_defs.h
: there we don't know whatsyscall_parser_table
is, so not possible.
So keeping as is.d
libos/src/libos_parser.c
line 1658 at r2 (raw file):
Previously, oshogbo (Mariusz Zaborski) wrote…
Yes, my idea was to not use a LIBOS_SYSCALL_BOUND as a error msg, as the name does not suggest that something went wrong. And doing it as you proposed. Your decision.
Done
f469e2e
to
073c483
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 14 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel)
Documentation/manifest-syntax.rst
line 397 at r1 (raw file):
Previously, dimakuv (Dmitrii Kuvaiskii) wrote…
Alternatives:
- Provide an allowlist
sys.allowed_syscalls = [ ... ]
. This will be more security-expected and more in line with e.g. seccomp profiles. Downside: much harder for end users.- Provide both this denylist and the allowlist manifest options. At init time, Gramine fails if detects them both.
Done, see discussion in #1876
Documentation/manifest-syntax.rst
line 399 at r2 (raw file):
Previously, dimakuv (Dmitrii Kuvaiskii) wrote…
One additional option would be to not simply return
-ENOSYS
, but allow to specify what int to return:sys.fixed_syscalls = [ { name = "syscall_name1", return = -38}, # returns -ENOSYS { name = "syscall_name2", return = 0}, # returns 0, i.e. dummy impl
Done, replaced with sys.mocked_syscalls
as proposed during the Gramine meeting: #1876
sys.disallowed_syscalls = [ ... ]
manifest optionsys.mock_syscalls = [ ... ]
manifest option
073c483
to
4a5ce3e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed all commit messages.
Reviewable status: 0 of 14 files reviewed, 3 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @dimakuv)
Documentation/manifest-syntax.rst
line 418 at r4 (raw file):
sys.mock_syscalls = [ { name = "eventfd", return = -38 }, { name = "eventfd", return = -38 },
eventfd2
Code quote:
eventfd
Documentation/manifest-syntax.rst
line 428 at r4 (raw file):
(2) it is also used to create threads in the same process. The ``sys.disallow_subprocesses`` manifest option disables only the first usage, whereas ``sys.mock_syscalls = [ name = "clone", ...]`` disables both usages.
{name = "clone"}
Code quote:
name = "clone"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 14 files reviewed, 2 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @llly)
Documentation/manifest-syntax.rst
line 418 at r4 (raw file):
Previously, llly (Li Xun) wrote…
eventfd2
Done, oops, thanks for catching this!
Documentation/manifest-syntax.rst
line 428 at r4 (raw file):
Previously, llly (Li Xun) wrote…
{name = "clone"}
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 13 of 14 files at r4, 1 of 1 files at r5, all commit messages.
Reviewable status: all files reviewed, all discussions resolved, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 10 of 14 files at r4, 1 of 1 files at r5, all commit messages.
Reviewable status: all files reviewed, 4 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @dimakuv)
-- commits
line 19 at r5:
I think we shouldn't encourage such things, it's not semantically correct (vhangup()
is not a semantical no-op).
Documentation/manifest-syntax.rst
line 406 at r5 (raw file):
This syntax specifies the system calls that are mocked when executed in Gramine (i.e. they return a specified value without any other side effects). If ``return`` field is skipped, then the default value is ``0`` (no-op).
I'd also warn the users that returning a success but skipping side-effects may introduce bugs to the app, if it expects them (e.g. mocking futex
may lead to silent introduction of race conditions).
libos/src/libos_parser.c
line 1659 at r5 (raw file):
int get_syscall_number(const char* name, unsigned long* out_sysno) { static_assert(LIBOS_SYSCALL_BOUND == ARRAY_SIZE(syscall_parser_table), "oops"); assert(out_sysno);
Why asserting this, but not asserting name
? I'd just remove it.
libos/src/libos_syscalls.c
line 153 at r5 (raw file):
/* add syscall to the table of mocked syscalls */ libos_mock_syscall_table[sysno].is_mocked = true;
Please check if sysno
fits in the table.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 5 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @dimakuv)
a discussion (no related file):
I don't think doing it like this is a good idea for UX reasons: it exposes what is essentially a debug-level option for a user-level need.
The "user-level" need here is executing sched_yield
within the enclave, which is a fundamentally sound thing to do. It can be a supported option, in the "we provide user support when you use it and something breaks" sense.
However, the proposed generic interface is debug-level: it's a sharp tool that can easily be used to completely break syscall semantics, and make the entire thing unsound. We cannot provide support for using this option.
While I'm not completely against having such debug-level options, I believe they should be clearly marked as such (sys.debug__mock_syscalls
?), and not recommended for production usage. Separately, I believe we should provide a simple user-facing option like sys.sched_yield_noop = true
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 5 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @dimakuv, @kailun-qin, @mkow, and @woju)
a discussion (no related file):
I agree that this is a "sharp tool".
I don't like the prefix debug__
, can we use something else? It's more like a pro__
feature, or maybe even risky__
or experimental__
? @mkow @kailun-qin @woju Would be good to hear your opinion on the possible name.
Separately, I believe we should provide a simple user-facing option like
sys.sched_yield_noop = true
.
Yes, this would make sense if people will start using the current tool and we'll start getting requests to make it "not risky/not debuggy". So I'd only keep a single "sharp tool" manifest option, and only add those ones that will be requested by real clients.
Previously, mkow (Michał Kowalczyk) wrote…
I think we shouldn't encourage such things, it's not semantically correct (
vhangup()
is not a semantical no-op).
Will do: I will remove this example from the commit message
Documentation/manifest-syntax.rst
line 406 at r5 (raw file):
Previously, mkow (Michał Kowalczyk) wrote…
I'd also warn the users that returning a success but skipping side-effects may introduce bugs to the app, if it expects them (e.g. mocking
futex
may lead to silent introduction of race conditions).
Done.
libos/src/libos_parser.c
line 1659 at r5 (raw file):
Previously, mkow (Michał Kowalczyk) wrote…
Why asserting this, but not asserting
name
? I'd just remove it.
Done.
libos/src/libos_syscalls.c
line 153 at r5 (raw file):
Previously, mkow (Michał Kowalczyk) wrote…
Please check if
sysno
fits in the table.
Done. This should be guaranteed by get_syscall_number()
, so I assert here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 3 of 3 files at r6, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @dimakuv, @kailun-qin, and @woju)
a discussion (no related file):
I don't like the prefix
debug__
, can we use something else? It's more like apro__
feature, or maybe evenrisky__
orexperimental__
? @mkow @kailun-qin @woju Would be good to hear your opinion on the possible name.
Hmm, honestly, I don't like any of them 😬
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 2 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @dimakuv and @woju)
a discussion (no related file):
Previously, mkow (Michał Kowalczyk) wrote…
I don't like the prefix
debug__
, can we use something else? It's more like apro__
feature, or maybe evenrisky__
orexperimental__
? @mkow @kailun-qin @woju Would be good to hear your opinion on the possible name.Hmm, honestly, I don't like any of them 😬
I slightly prefer pro__
or adv__
(to indicate that it's an advaned feature for users w/ a specific level of expertise, and state in the manifest doc that it should be applied with caution).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 2 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @woju)
a discussion (no related file):
Previously, kailun-qin (Kailun Qin) wrote…
I slightly prefer
pro__
oradv__
(to indicate that it's an advaned feature for users w/ a specific level of expertise, and state in the manifest doc that it should be applied with caution).
I think maybe experimental__
? It is a feature for experimenting, and it's not particularly for production, so the prefix seems to make sense. Besides, we already have other features with this prefix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 2 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @dimakuv and @mwkmwkmwk)
a discussion (no related file):
Previously, dimakuv (Dmitrii Kuvaiskii) wrote…
I think maybe
experimental__
? It is a feature for experimenting, and it's not particularly for production, so the prefix seems to make sense. Besides, we already have other features with this prefix.
sys.sched_yield_noop = <bool>
is a good way to fix the immediate problem.
However, about generic "mock any syscall interface": I disagree this is not recommended for prod, we already have sys.ioctl_structs
which is similar in that the user is supposed to specify low level behaviour in a sort of DSL. Similar complexity, although possibly less of a footgun.
I also don't think we should escalate prefixes to options, because what will we do next, sys.very_risky__
? (And on related note, I heard frontend developers will have !very-important
in CSS 2025). Having this unprefixed is an OK thing to do, just document this with scary warning in manifest-syntax.rst
that messing with this option is not something to be done lightly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 13 of 14 files reviewed, 2 unresolved discussions, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " found in commit messages' one-liners (waiting on @mkow and @mwkmwkmwk)
a discussion (no related file):
Previously, woju (Wojtek Porczyk) wrote…
sys.sched_yield_noop = <bool>
is a good way to fix the immediate problem.However, about generic "mock any syscall interface": I disagree this is not recommended for prod, we already have
sys.ioctl_structs
which is similar in that the user is supposed to specify low level behaviour in a sort of DSL. Similar complexity, although possibly less of a footgun.I also don't think we should escalate prefixes to options, because what will we do next,
sys.very_risky__
? (And on related note, I heard frontend developers will have!very-important
in CSS 2025). Having this unprefixed is an OK thing to do, just document this with scary warning inmanifest-syntax.rst
that messing with this option is not something to be done lightly.
Done.
I agree with @woju's reasoning. Currently I stick to sys.mock_syscalls
(without any prefix) and I added a warning in the documentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 3 of 14 files at r4, 1 of 1 files at r7, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions, "fixup! " found in commit messages' one-liners (waiting on @mwkmwkmwk)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 3 unresolved discussions, "fixup! " found in commit messages' one-liners (waiting on @dimakuv and @mwkmwkmwk)
Documentation/manifest-syntax.rst
line 441 at r7 (raw file):
implemented in Gramine, and limiting syscalls exposed to the app. .. warning ::
Can you make the enclave insecure using this construct? Like, leak secrets, not just crash. If not, I think this might be .. caution::
, not .. warning::
(but N/B). IIUC only attempting to use this as sort of sandbox is a security footgun, but this is already the subject of the previous admonition (which is correctly a warning).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 3 unresolved discussions, "fixup! " found in commit messages' one-liners (waiting on @mwkmwkmwk and @woju)
Documentation/manifest-syntax.rst
line 441 at r7 (raw file):
Previously, woju (Wojtek Porczyk) wrote…
Can you make the enclave insecure using this construct? Like, leak secrets, not just crash. If not, I think this might be
.. caution::
, not.. warning::
(but N/B). IIUC only attempting to use this as sort of sandbox is a security footgun, but this is already the subject of the previous admonition (which is correctly a warning).
Yes, I think it could make the enclave insecure. Like, if the application expects some side effects from a certain system call, but this system call is mocked to always return 0
(success), then the app may end up in a weird state and start doing smth weird, including leaking secrets.
Thus, I would prefer to keep the warning
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 2 unresolved discussions, "fixup! " found in commit messages' one-liners (waiting on @dimakuv and @mwkmwkmwk)
Documentation/manifest-syntax.rst
line 441 at r7 (raw file):
Previously, dimakuv (Dmitrii Kuvaiskii) wrote…
Yes, I think it could make the enclave insecure. Like, if the application expects some side effects from a certain system call, but this system call is mocked to always return
0
(success), then the app may end up in a weird state and start doing smth weird, including leaking secrets.Thus, I would prefer to keep the
warning
.
I understand. If so, then yes, this should be a .. warning::
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 6 of 14 files at r4, 2 of 3 files at r6, 1 of 1 files at r7, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions, "fixup! " found in commit messages' one-liners (waiting on @dimakuv)
This commit adds manifest syntax `sys.debug__mock_syscalls = [ ... ]` to specify system calls that will be mocked when executed in Gramine (i.e. return a specified value without any other side effects). This may be particularly important for cases where the overhead of invoking a system call on the host (e.g. exiting the SGX enclave) becomes a performance bottleneck, and it is more beneficial to disable or no-op the syscall in the first place; `sched_yield()` is an example. Another example may be disabling certain functionalities for security reasons. For example, one may want to disable `eventfd()` and `eventfd2()` to forbid creation of eventfd objects. Signed-off-by: Dmitrii Kuvaiskii <[email protected]>
c471bb0
to
afb8a35
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 7 of 14 files reviewed, 2 unresolved discussions (waiting on @llly, @mkow, and @mwkmwkmwk)
Previously, dimakuv (Dmitrii Kuvaiskii) wrote…
Will do: I will remove this example from the commit message
Done.
Previously, dimakuv (Dmitrii Kuvaiskii) wrote…
Will do: change everywhere in commit message to
sys.debug__mock_syscalls
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 3 of 14 files at r4, 4 of 4 files at r8, 7 of 7 files at r9, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @mkow)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 7 of 7 files at r9, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved
Jenkins, retest this please (CI supposedly should work again now) |
Jenkins, test this please |
6 similar comments
Jenkins, test this please |
Jenkins, test this please |
Jenkins, test this please |
Jenkins, test this please |
Jenkins, test this please |
Jenkins, test this please |
Jenkins, test check-python-platlib please |
Jenkins, test pkg-rpm-almalinux9 |
Jenkins, test pkg-rpm-almalinux9 please |
Jenkins, test linux-sgx-vm-gcc-release please |
Jenkins, test Jenkins-SGX-EDMM please |
Jenkins, test Jenkins-SGX-Sanitizers please |
Jenkins, test Jenkins-SGX-20.04-apps please |
Jenkins, test Jenkins-SGX-EDMM please |
Jenkins, test Jenkins-SGX-20.04 please |
Jenkins, test Jenkins-SGX-20.04 please |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jenkins, test Jenkins-SGX-20.04 please
Reviewable status: complete! all files reviewed, all discussions resolved
Jenkins, test Jenkins-SGX-20.04 please |
1 similar comment
Jenkins, test Jenkins-SGX-20.04 please |
Jenkins, test Jenkins-SGX-Sanitizers please |
Jenkins, test Jenkins-SGX-20.04-apps please |
Description of the changes
This PR adds the manifest syntax
sys.disallowed_syscalls = [ ... ]
sys.mock_syscalls = [ ... ]
sys.debug_mock_syscalls = [ ... ]
to specify system calls that will return a specified value when executed in Gramine.How to test this PR?
Added a LibOS regression test.
This change is