Writing to stdout/stderr in content process should not return error
Categories
(Core :: Security: Process Sandboxing, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox98 | --- | fixed |
People
(Reporter: cmartin, Assigned: cmartin)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
In Rust's implementation of stdio, this code exists:
if let Err(e) = global_s().write_fmt(args) {
panic!("failed printing to {}: {}", label, e);
}
This means that if Rust fails to write to stdout in WebRender (like it does here), it will crash with the following error:
failed printing to stdout: Access is denied. (os error 5)
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
Comment 3•3 years ago
|
||
Backed out for causing build bustages
Backout link: https://hg.mozilla.org/integration/autoland/rev/55a08c98015b714e4302b50075cb9917e146b375
Failure log:
-https://treeherder.mozilla.org/logviewer?job_id=364832746&repo=autoland&lineNumber=65209
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
After our last team meeting, Nika brought up the good point that sooner-or-later we are going to end up in a situation where Rust code that we don't control will print to stdout/stderr, which will trigger a panic with the current Win32k Lockdown behavior.
It seems like we are going to have to find a way to make writing to stdout/stderr in content not return an error code, even if all it does is yeet the string into the void.
Assignee | ||
Comment 5•3 years ago
|
||
It appears that it's not actually specific to Win32k Lockdown but instead to Windows 8.1 (And possibly others?)
Lowering priority, since it's no longer blocking Win32k Lockdown and afaict it only affects debug builds.
Updated•3 years ago
|
Comment 7•3 years ago
|
||
bugherder |
Description
•