How can you know if this interface is not emulated, and you never talk to the
real cpu.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
That attack is a real thing, its called a mitm, but things use https now, so
you would need a malicious CA.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
Also, whats stops the owner of the machine to run the vm in a normal
hypervisor, then modify it so any attempts to check if it is "trusted" will
always look real.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
If it is really compromised, then you have to assume anything the vm sends you
is fake. As far as the owner of guest knows, there could not even a a real vm,
only a ssh shell that looks like it.
In a real situation, the guest owner would send the host owner a "starting
disk" or ISO. Then the
> My expectation would be that by default we'd just use the GPT auto
discovery stuff
Existing Fedora installations do not follow the GPT auto discovery spec. Also,
I think the existing system for the root device can still work, it is passed in
the command line, not the initrd.
With virtual machines, nothing can actually be verified completely, the host
running the vm can, 1) Modify the firmware to intercept anything the attacker
wants, or 2) directly intercept things at the cpu level.
___
devel mailing list --
Even if initrds are (somehow) signed, the kernel command line can still be
modified, like adding `init=/usr/bin/bash`. Also, if everything is signed by
fedora, then the user can not modify the command line. There is a lot of
hardware that needs command line modifications to boot. Also, fedora
I think using credentials for the rootfs is not very useful, the user already
enters the LUKS password on boot. Also, if the encryption keys are not stored
locally, then they have no use, an attacker can just get them from the external
storage. Many users also would not like needing an
> Like what?
I know there are some efi implementations that need pcie_ports=compat. I also
know that sometimes you need intel_iommu or amd_iommu=off.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
> level of tweaking then it's probably totally OK to just turn
>of Secureboot, at which point you can change it freely.
The user having choice and the user having secure shouldn't be mutually
exclusive. Also, if users have "special" hardware, shouldn't they also have
security.
A key on an encrypted disk can still prevent evil maid attacks, though an
attacker with local access can still compromise the system. In the current
system, an attacker with permissions required to read kernel memory can just
ask the shim to boot their modified kernel.
The entire purpose of a unified kernel image is to have the initrd bundled, so
it can be signed. systemd-boot also supports s multiple initrds. If there was a
way to sign the initrd and command line locally, and sign have fedora sign the
kernel, then there shouldn't have to be a huge initrd.
This is a good idea, but some users might want to modify or need to modify the
command line to boot, if it was signed using fedoras key, then you cant do
that. Also some users dont like keeping their trust in fedora and would like to
modify their kernel freely. Also, though the private key is
Akmods can automatically sign kernel modules, its just a few commands and then
every version will be signed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
Secure boot itself, when used right, actually helps your privacy. Microsoft
doesn't require oems to allow the keys to be changed, so it sometimes prevents
your freedom, but when implemented right, it can stop evil maid attacks. Also,
even when you cant remove Microsoft keys, you can still use
> How big is the demand for this kind of lockdown?
It can help users security, but most users have no idea what this is. Software
should be secure by itself, without users needing extra effort.
> As a since-last-century Linux user, I'm choosing Fedora
> exactly to NOT have all this
The latest akmods version can automatically sign kernel modules, it could even
be enabled by default.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
If the system owner wanted to, they could use their own firmware/ comprimise
firmware, then fake the firmware version to something new, the vm could not
even be interacting with the cpu at all. Also, if the keys are in the cpu, then
the keys can be extracted.
This could be for a later fedora version if it doesnt work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
It would be stored with permissions for only root to read it, and you disk
should be encrypted, or none of this matters.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
Also, can it be fixed so adding the --uefi flag to dracut works with the
default generation scripots
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
> The Flathub remote is available to users who opt-in to enabling
> third-party software repositories in either GNOME Initial Setup or
> GNOME Software.
A lot of flatpaks in Flathub have debatable quality, and are closed source. If
we could wait until flathub separates open-source and
It should be possible to load sd-boot directly, it picks up any kernel in
/boot/EFI/linux for me. Try loading sd-boot directly from ovmf, skipping grub.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Use unified kernel images by default for new releases. This can allow for the
local installation to sign the kernel and the initrd, so the boot chain can be
verified until after the uefi. Currently, the initrd can be modified by
attackers, so even if the / partition is encrypted, the systems
Would pre-building the initrds mean all users have to use the same partition
layout. If that happened, than many people dual boot setups will not work
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
25 matches
Mail list logo
