On 7/22/22 08:26, Chris Adams wrote:
> Once upon a time, Lennart Poettering said:
>> Hence, I am not convinved the benefit really outweighs the effort
>> here. Modifying your kernel command line is invasive, and hackish, and
>> hence I think it's OK to leave it out of the model.
> It may be
Once upon a time, Lennart Poettering said:
> Hence, I am not convinved the benefit really outweighs the effort
> here. Modifying your kernel command line is invasive, and hackish, and
> hence I think it's OK to leave it out of the model.
It may be invasive or hackish, but sometimes it is
On 7/22/22 05:40, Lennart Poettering wrote:
> On Mi, 20.07.22 20:48, Demi Marie Obenour (demioben...@gmail.com) wrote:
>
>>> So, in my view of the world, the kernel command line is fixated in the
>>> unified kernel image (if you use systemd-stub, this already happens if
>>> a .cmdline PE section
On Mi, 20.07.22 20:48, Demi Marie Obenour (demioben...@gmail.com) wrote:
> > So, in my view of the world, the kernel command line is fixated in the
> > unified kernel image (if you use systemd-stub, this already happens if
> > a .cmdline PE section exists, and SecureBoot is on). If you want to
>
On 7/20/22 16:20, Lennart Poettering wrote:
> On Mi, 20.07.22 21:55, Marek Marczykowski-Górecki
> (marma...@invisiblethingslab.com) wrote:
>
>>> I wonder if Qubes OS could use any of this work. It seems that it
>>> would be incredibly useful, at least if it supported systems using
>>> the Xen
On 7/20/22 15:55, Marek Marczykowski-Górecki wrote:
> On Wed, Jul 20, 2022 at 03:06:46PM -0400, Demi Marie Obenour wrote:
>> On 7/19/22 12:13, Lennart Poettering wrote:
>>> On Di, 19.07.22 16:15, Gerd Hoffmann (kra...@redhat.com) wrote:
>>>
> Moreover, this allows us to implemented TPM
On Mi, 20.07.22 21:55, Marek Marczykowski-Górecki
(marma...@invisiblethingslab.com) wrote:
> > I wonder if Qubes OS could use any of this work. It seems that it
> > would be incredibly useful, at least if it supported systems using
> > the Xen hypervisor.
>
> That's probably going to be useful
On Wed, Jul 20, 2022 at 03:06:46PM -0400, Demi Marie Obenour wrote:
> On 7/19/22 12:13, Lennart Poettering wrote:
> > On Di, 19.07.22 16:15, Gerd Hoffmann (kra...@redhat.com) wrote:
> >
> >>> Moreover, this allows us to implemented TPM policies that bind to
> >>> signatures of PCR hashes, instead
On 7/19/22 12:13, Lennart Poettering wrote:
> On Di, 19.07.22 16:15, Gerd Hoffmann (kra...@redhat.com) wrote:
>
>>> Moreover, this allows us to implemented TPM policies that bind to
>>> signatures of PCR hashes, instead of the literal hash values. That
>>> makes the measurements a *million* times
On Wed, Jul 20, 2022, at 4:44 AM, Gerd Hoffmann wrote:
> Where does that build happen? Must be outside the kernel
> rpm build process, so probably when generating the ostree?
Exactly. We also run all %post scripts server side too for example.
You can see the logs for this at e.g.
On Tue, Jul 19, 2022 at 11:02:32AM -0400, Colin Walters wrote:
>
>
> On Tue, Jul 19, 2022, at 10:15 AM, Gerd Hoffmann wrote:
> >
> > That is the big if. If you have the initrds.
> >
> > I've hacked up the kernel rpm to also build a initrd (targeting virtual
> > machines for starters) and
On Di, 19.07.22 21:16, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> 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
No, it dos not mean that.
Lennart
--
Lennart
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
On Di, 19.07.22 16:15, Gerd Hoffmann (kra...@redhat.com) wrote:
> > Moreover, this allows us to implemented TPM policies that bind to
> > signatures of PCR hashes, instead of the literal hash values. That
> > makes the measurements a *million* times more useful, since we loose
> > the brittleness
On Tue, Jul 19, 2022, at 10:15 AM, Gerd Hoffmann wrote:
>
> That is the big if. If you have the initrds.
>
> I've hacked up the kernel rpm to also build a initrd (targeting virtual
> machines for starters) and shipping that as (optional) sub-rpm ...
FWIW, every rpm-ostree based system defaults
On Mon, Jul 18, 2022 at 05:03:53PM +0200, Lennart Poettering wrote:
> On Mo, 18.07.22 14:52, Gerd Hoffmann (kra...@redhat.com) wrote:
>
> > Problem with measuring the initrd is that we don't have fixed hashes for
> > a given kernel version (due to generating the initrd on the installed
> >
On Mo, 18.07.22 14:52, Gerd Hoffmann (kra...@redhat.com) wrote:
> On Fri, Jul 15, 2022 at 10:33:03AM -, Francois Rigault wrote:
> > Another idea is to measure the initrd and the boot configuration, for
> > example taking a hash of the grub configuration and initrd and
> > extending a PCR
indeed, this is why a proposal is to change the way grub measure things.
For example introducing a new PCR, for example PCR10, and a new command,
"extend", that replay a command into the PCR without actually executing it.
This would mean for your above example, if we only limit to the last line,
On Fri, Jul 15, 2022 at 10:33:03AM -, Francois Rigault wrote:
> Another idea is to measure the initrd and the boot configuration, for
> example taking a hash of the grub configuration and initrd and
> extending a PCR register.
That is already happening.
Problem with measuring the initrd is
Another idea is to measure the initrd and the boot configuration, for
example taking a hash of the grub configuration and initrd and
extending a PCR register.
To make it work across upgrades, the grub configuration could be put
into a git repository. Each commit hash is computed using the TPM and
On Thursday, 7 July 2022 19:37:16 BST Sharpened Blade via devel wrote:
> 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,
On 7/7/22 14:09, Sharpened Blade via devel wrote:
> 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.
They cannot fake the attestation without somehow extracting the needed
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
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
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
On Wed, Jul 06, 2022 at 05:12:20PM +0200, Lennart Poettering wrote:
> On Mi, 06.07.22 16:13, Gerd Hoffmann (kra...@redhat.com) wrote:
>
> > grub2 doesn't find it. Support not implemented?
>
> afics grub2 upstream has no native support for boot loader spec
> stuff. (or has that changed?)
Nope.
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
On Mi, 06.07.22 16:13, Gerd Hoffmann (kra...@redhat.com) wrote:
> grub2 doesn't find it. Support not implemented?
afics grub2 upstream has no native support for boot loader spec
stuff. (or has that changed?)
The fedora version of grub2 implements a flavour of type #1 boot loader spec
entries
On Mon, Jul 04, 2022 at 03:59:25PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf
>
> Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like
> being at proof-of-concept state. mkosi going fetch stuff
Once upon a time, Sharpened Blade said:
> How can you know if this interface is not emulated, and you never talk to the
> real cpu.
That's like saying you can't know if https://www.google.com/ is Google
because your computer only talks to AT
--
Chris Adams
Lennart Poettering writes:
> On Di, 05.07.22 01:44, Fedora Development ML (devel@lists.fedoraproject.org)
> wrote:
>
>> Also, if users have "special" hardware, shouldn't they also have
>> security.
>
> if you need a special kernel cmdline to get your system to boot, then
> that's a bug in the
On Tuesday, 5 July 2022 17:26:40 BST Sharpened Blade via devel wrote:
> How can you know if this interface is not emulated, and you never talk to
> the real cpu
The TDX white papers address how this is meant to work - it's based around the
same "measurement" concept as TPM measured boot (see
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:
On Mon, Jul 04, 2022 at 07:20:32PM -, Sharpened Blade via devel wrote:
> 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.
On Di, 05.07.22 09:49, Gerd Hoffmann (kra...@redhat.com) wrote:
> Hi,
>
> > > > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf
> >
> > we tried to make rh image builder people inetreested in that, but they
> > weren't interested in that at all.
>
> For initrd
On Mon, Jul 04, 2022 at 07:24:28PM -, Sharpened Blade via devel wrote:
> > 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
On Mon, Jul 04, 2022 at 10:25:05PM +0100, Richard W.M. Jones wrote:
> On Mon, Jul 04, 2022 at 03:59:25PM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf
> >
> > Hmm. Nice ideas (reproducible initrds, yay!), but it
Hi,
> > > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf
>
> we tried to make rh image builder people inetreested in that, but they
> weren't interested in that at all.
For initrd building or for cloud image building?
> > I don't think mkosi is a hard
On Di, 05.07.22 02:34, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> > 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.
Those are local hacks to get very new or very
On Di, 05.07.22 01:44, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> Also, if users have "special" hardware, shouldn't they also have
> security.
if you need a special kernel cmdline to get your system to boot, then
that's a bug in the kernel, and should be fixed there. Adding
> 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.
On Mon, Jul 4 2022 at 09:55:20 AM +0200, Lennart Poettering
wrote:
Signing and authenticating the code is a good thing to protect
systems – it's a good thing if we can do so for the boot code too as
we boot.
Tangent:
After installing or upgrading your Fedora or RHEL system, you have to
On Mo, 04.07.22 19:27, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> I think using credentials for the rootfs is not very useful, the
> user already enters the LUKS password on boot.
I can't parse this.
the systemd credentials stuff are not just for passing secrets or
so. They
On Mo, 04.07.22 15:59, Gerd Hoffmann (kra...@redhat.com) wrote:
> Hi,
>
> > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf
>
> Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like
> being at proof-of-concept state. mkosi going fetch stuff
On Mo, 04.07.22 19:24, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> > 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.
If it is desirable to automatically switch
On Mo, 04.07.22 19:18, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> Even if initrds are (somehow) signed, the kernel command line can
> still be modified, like adding `init=/usr/bin/bash`.
Hmm? sd-stub refused any kernel cmdline passed in manually if
SecureBoot is on. The
On Mon, Jul 04, 2022 at 03:59:25PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf
>
> Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like
> being at proof-of-concept state. mkosi going fetch stuff
Once upon a time, Sharpened Blade said:
> 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.
There are CPU extensions that I
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
> 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
Hi,
> https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initrd.pdf
Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like
being at proof-of-concept state. mkosi going fetch stuff from the
internet to generate the initrd is clearly a non-starter (maybe not
On Mo, 04.07.22 11:32, Gerd Hoffmann (kra...@redhat.com) wrote:
> Hi,
>
> > We have been working on building tools and filling gaps to make that
> > workable reasonably in systemd upstream, and with a focus on
> > Fedora. The difficulty is in both being able to prebuild everything
> > but also
Hi,
> We have been working on building tools and filling gaps to make that
> workable reasonably in systemd upstream, and with a focus on
> Fedora. The difficulty is in both being able to prebuild everything
> but also keeping things somewhat modular and parameterizable. Because
> right now
On Mo, 04.07.22 09:30, Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > When going for multiple initrds the best approach is probably to simply
> > > split out the kernel modules into a version-specific initrd and store
> > > everything else in another, shared initrd.
> >
> > In the approach
On Mo, 04.07.22 04:19, Demi Marie Obenour (demioben...@gmail.com) wrote:
> On 7/4/22 04:13, Lennart Poettering wrote:
> > On Fr, 01.07.22 08:30, Gerd Hoffmann (kra...@redhat.com) wrote:
> >
> >>> I do wonder if it's possible to use multiple initrds, and maybe have
> >>> the firmware in a separate
On Mon, Jul 04, 2022 at 10:13:23AM +0200, Lennart Poettering wrote:
> On Fr, 01.07.22 08:30, Gerd Hoffmann (kra...@redhat.com) wrote:
>
> > > I do wonder if it's possible to use multiple initrds, and maybe have
> > > the firmware in a separate initrd shared between all installed kernels
> > > if
On 7/4/22 04:13, Lennart Poettering wrote:
> On Fr, 01.07.22 08:30, Gerd Hoffmann (kra...@redhat.com) wrote:
>
>>> I do wonder if it's possible to use multiple initrds, and maybe have
>>> the firmware in a separate initrd shared between all installed kernels
>>> if we go down this route.
>>
>>
On Fr, 01.07.22 08:30, Gerd Hoffmann (kra...@redhat.com) wrote:
> > I do wonder if it's possible to use multiple initrds, and maybe have
> > the firmware in a separate initrd shared between all installed kernels
> > if we go down this route.
>
> grub supports multiple initrds just fine.
On Sa, 25.06.22 20:43, Neal Gompa (ngomp...@gmail.com) wrote:
> > It’s necessary for secure boot to actually be meaningful in
> > practice. I expect that people who care about secure boot
> > will want this.
>
> I don't. I only care about secure boot enough to bootstrap a Free
> platform. Secure
On So, 19.06.22 20:54, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> 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
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.
On Fri, Jul 01, 2022 at 08:30:21AM +0200, Gerd Hoffmann wrote:
> On Fri, Jul 01, 2022 at 06:39:41AM +1000, David Airlie wrote:
> > I do wonder if it's possible to use multiple initrds, and maybe have
> > the firmware in a separate initrd shared between all installed kernels
> > if we go down this
On Fri, Jul 01, 2022 at 06:39:41AM +1000, David Airlie wrote:
> On Mon, Jun 27, 2022 at 6:33 PM Gerd Hoffmann wrote:
> >
> > On Sun, Jun 19, 2022 at 08:54:51PM -, Sharpened Blade via devel wrote:
> > > Use unified kernel images by default for new releases. This can allow
> > > for the local
On Mon, Jun 27, 2022 at 6:33 PM Gerd Hoffmann wrote:
>
> On Sun, Jun 19, 2022 at 08:54:51PM -, Sharpened Blade via devel wrote:
> > 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
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:
V Tue, Jun 28, 2022 at 08:27:16PM +0100, David Howells napsal(a):
> Sharpened Blade via devel wrote:
>
> > It would be stored with permissions for only root to read it, and you disk
> > should be encrypted, or none of this matters.
>
> It doesn't matter if your disk is encrypted. Whilst your
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.
Sharpened Blade via devel wrote:
> It would be stored with permissions for only root to read it, and you disk
> should be encrypted, or none of this matters.
It doesn't matter if your disk is encrypted. Whilst your computer is online,
the contents are accessible. If your kernel memory is
Sharpened Blade via devel wrote:
> [...] Software should be secure by itself, [...]
That's impossible to achieve. Without hardware support, you cannot make your
software secure.
Further, human beings are involved in the writing of the software - and the
larger the codebase and the more people
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
On 6/28/22 07:21, Florian Weimer wrote:
> * Chris Murphy:
>
>> On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer wrote:
>>>
>>> * Neal Gompa:
>>>
I treat Secure Boot purely as a compatibility interface. We need to do
just enough to get through the secure boot environment.
>>>
>>> Right.
> Demi Marie Obenour wrote:
>> On 6/25/22 07:56, Roberto Ragusa wrote:
>>> On 6/19/22 22:54, Sharpened Blade via devel wrote:
>>>
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
* Chris Murphy:
> On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer wrote:
>>
>> * Neal Gompa:
>>
>> > I treat Secure Boot purely as a compatibility interface. We need to do
>> > just enough to get through the secure boot environment.
>>
>> Right. It's not even clear to me why we enforce kernel
On Tue, Jun 28, 2022 at 01:12:25PM +0200, Petr Pisar wrote:
> On Tue, Jun 28, 2022 at 9:27 AM Daniel P. Berrangé
> wrote:
> > That's thinking about the problem from the wrong point of view. SecureBoot
> > doesn't prevent an attacker from booting an OS that's different from what
> > you
On 28/06/2022 09:26, Daniel P. Berrangé wrote:
What SecureBoot does is to provide a mechanism to assert that
what has booted matches the original install, and securely tie that
condition to the release of secrets for example to LUKS key.
No, it doesn't. It just blocks the ability to load
On Tue, Jun 28, 2022 at 9:27 AM Daniel P. Berrangé wrote:
> That's thinking about the problem from the wrong point of view. SecureBoot
> doesn't prevent an attacker from booting an OS that's different from what
> you installed, even without shim they could swap to a different Windows
> install.
On Tue, Jun 28, 2022 at 08:42:43AM +0200, Vitaly Zaitsev via devel wrote:
> On 27/06/2022 21:18, Sharpened Blade via devel wrote:
> > Also, even when you cant remove Microsoft keys, you can still use the shim.
>
> If you can't remove Microsoft keys, you're nullifying the whole purpose of
> secure
On 27/06/2022 21:19, Sharpened Blade via devel wrote:
Akmods can automatically sign kernel modules, its just a few commands and then
every version will be signed.
Yes, but anyone can read your private keys to sign anything. Someone
needs to implement support for hardware tokens, or at least
On 27/06/2022 21:18, Sharpened Blade via devel wrote:
Also, even when you cant remove Microsoft keys, you can still use the shim.
If you can't remove Microsoft keys, you're nullifying the whole purpose
of secure boot, because anyone can use a signed shim to boot whatever
they want.
Also,
On 6/27/22 13:34, Chris Murphy wrote:
> On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer wrote:
>>
>> * Neal Gompa:
>>
>>> I treat Secure Boot purely as a compatibility interface. We need to do
>>> just enough to get through the secure boot environment.
>>
>> Right. It's not even clear to me why
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.
> 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
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
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:
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
On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer wrote:
>
> * Neal Gompa:
>
> > I treat Secure Boot purely as a compatibility interface. We need to do
> > just enough to get through the secure boot environment.
>
> Right. It's not even clear to me why we enforce kernel module
> signatures in
On Mon, Jun 27, 2022 at 08:12:08AM -0400, Neal Gompa wrote:
> On Mon, Jun 27, 2022 at 7:59 AM Daniel P. Berrangé
> wrote:
> >
> > On Mon, Jun 27, 2022 at 07:46:29AM -0400, Neal Gompa wrote:
> > > On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé
> > > wrote:
> > > >
> > > > On Sat, Jun 25,
On Mon, Jun 27, 2022 at 7:59 AM Daniel P. Berrangé wrote:
>
> On Mon, Jun 27, 2022 at 07:46:29AM -0400, Neal Gompa wrote:
> > On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé
> > wrote:
> > >
> > > On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote:
> > > > On Sat, Jun 25, 2022 at
On Mon, Jun 27, 2022 at 07:46:29AM -0400, Neal Gompa wrote:
> On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé
> wrote:
> >
> > On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote:
> > > On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour
> > > wrote:
> > > >
> > > > On 6/25/22 07:56,
On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé wrote:
>
> On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote:
> > On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour
> > wrote:
> > >
> > > On 6/25/22 07:56, Roberto Ragusa wrote:
> > > > On 6/19/22 22:54, Sharpened Blade via devel
On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote:
> On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour
> wrote:
> >
> > On 6/25/22 07:56, Roberto Ragusa wrote:
> > > On 6/19/22 22:54, Sharpened Blade via devel wrote:
> > >
> > >> Use unified kernel images by default for new releases.
On Sun, Jun 19, 2022 at 08:54:51PM -, Sharpened Blade via devel wrote:
> 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
* Neal Gompa:
> I treat Secure Boot purely as a compatibility interface. We need to do
> just enough to get through the secure boot environment.
Right. It's not even clear to me why we enforce kernel module
signatures in Secure Boot mode, and disable a few other kernel features.
Thanks,
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:
On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour
wrote:
>
> On 6/25/22 07:56, Roberto Ragusa wrote:
> > On 6/19/22 22:54, Sharpened Blade via devel wrote:
> >
> >> Use unified kernel images by default for new releases. This can allow for
> >> the local installation to sign the kernel and the
On 6/25/22 07:56, Roberto Ragusa wrote:
> On 6/19/22 22:54, Sharpened Blade via devel wrote:
>
>> 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.
>
1 - 100 of 102 matches
Mail list logo
