Skip to content
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.

Sign up for GitHub

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

Jump to bottom

bad idea to have make-linux-fast-again by default? #6

Closed
bbigras opened this issue Jan 8, 2020 · 2 comments · Fixed by #7
Closed

bad idea to have make-linux-fast-again by default? #6

bbigras opened this issue Jan 8, 2020 · 2 comments · Fixed by #7

Comments

@bbigras
Copy link
Contributor

bbigras commented Jan 8, 2020

I don't know if it's possible to import imports = [ ../profiles ] directly but someone importing ../profiles/misc might not realize that it will disable the meltdown/spectre mitigations.

Maybe it should only be importable directly with the path containing something like:
DISABLE_SECURITY_I_KNOW_THE_RISK.
@nrdxp
Copy link
Collaborator

nrdxp commented Jan 8, 2020 •
edited
Loading

Yeah, your probably right. I was thinking as much. Perhaps removing it from misc and renaming it to something like disable_mitigations.nix would be enough. If you really think it is necessary, we could define a custom option like mitigations.acceptRisk and use an assertion in the profile which fails if this is not true with a message like:

You must explicitly accept the risk of running without mitigations by setting mitigations.acceptRisk = true;

nrdxp added a commit that referenced this issue Jan 8, 2020
@nrdxp
security#mitigations: init module
db71946 
Resolves #6 by breaking out the disabling of mitigations into it's own module.
Now users must explicitly accept the risk of disabling Spectre and Meltdown
mitigations with `security.mitigations.acceptRisk` in addtion to actually
disabling them with `security.mitigations.disable`.
@nrdxp nrdxp mentioned this issue Jan 8, 2020
Merged
nrdxp added a commit that referenced this issue Jan 8, 2020
@nrdxp
security#mitigations: init module
a3e9f46 
Resolves #6 by breaking out the disabling of mitigations into it's own module.
Now users must explicitly accept the risk of disabling Spectre and Meltdown
mitigations with security.mitigations.acceptRisk in addtion to actually
disabling them with security.mitigations.disable.# Please enter the commit message for your changes. Lines starting
nrdxp added a commit that referenced this issue Jan 8, 2020
@nrdxp
security#mitigations: init module
413a6c7 
Resolves #6 by breaking out the disabling of mitigations into it's own module.
Now users must explicitly accept the risk of disabling Spectre and Meltdown
mitigations with `security.mitigations.acceptRisk` in addition to actually
disabling them with `security.mitigations.disable`.
@nrdxp nrdxp closed this as completed in #7 Jan 8, 2020
@bbigras
Copy link
Contributor Author

bbigras commented Jan 9, 2020

Thanks 👍

Pacman99 pushed a commit that referenced this issue Feb 26, 2022
@bors
Merge #6
c756c17 
6: test mkFlake with a full flake similar to devos r=Pacman99 a=Pacman99

Starting point for tests, so you can mostly trust a `nix flake check` success. To test more things, we can add more "checks" in fullFlake/default.nix. So you could test if `ourlib` works right, or see if other outputs are evaluated right in mkFlake/evalArgs by forcing those things to be evaluated in a module or overlay. But this PR is just to get that framework setup.

Co-authored-by: Pacman99 <pachum99@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

security#mitigations: init module divnix/digga
2 participants
@bbigras @nrdxp