Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-22 Thread Demi Marie Obenour
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 invasi

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-22 Thread Chris Adams
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 absolute

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-22 Thread Demi Marie Obenour
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 e

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-22 Thread Lennart Poettering
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 > >

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-20 Thread Demi Marie Obenour
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 hy

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-20 Thread Demi Marie Obenour
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 policies

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-20 Thread Lennart Poettering
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 f

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-20 Thread Marek Marczykowski-Górecki
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

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-20 Thread Demi Marie Obenour
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

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-20 Thread Colin Walters
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. https://koj

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-20 Thread Gerd Hoffmann
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 shippin

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-19 Thread Lennart Poettering
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 Poetteri

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-19 Thread Sharpened Blade via devel
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 devel-le...@lis

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-19 Thread Lennart Poettering
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

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-19 Thread Colin Walters
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

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-19 Thread Gerd Hoffmann
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 > > system)

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-18 Thread Lennart Poettering
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 regis

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-18 Thread Francois Rigault
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,

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-18 Thread Gerd Hoffmann
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 th

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-15 Thread Francois Rigault
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

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-08 Thread Simon Farnsworth via devel
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, th

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-07 Thread Demi Marie Obenour
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 secret

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-07 Thread Sharpened Blade via devel
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 Conduct

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-07 Thread Sharpened Blade via devel
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 ho

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-07 Thread Sharpened Blade via devel
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 de

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-07 Thread Gerd Hoffmann
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.

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-06 Thread Sharpened Blade via devel
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 devel-le...@l

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-06 Thread Lennart Poettering
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 (i

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-06 Thread Gerd Hoffmann
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 from

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-05 Thread Chris Adams
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&T. -- Chris Adams __

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-05 Thread Robbie Harwood
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 ke

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-05 Thread Simon Farnsworth via devel
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 http

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-05 Thread Sharpened Blade via devel
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: https://docs.fedo

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-05 Thread Gerd Hoffmann
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. Wit

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-05 Thread Lennart Poettering
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 b

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-05 Thread Gerd Hoffmann
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 c

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-05 Thread Gerd Hoffmann
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

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-05 Thread Gerd Hoffmann
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 requir

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-05 Thread Lennart Poettering
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 exotic

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-05 Thread Lennart Poettering
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 a

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Sharpened Blade via devel
> 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 devel-le...@lis

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Sharpened Blade via devel
> 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. __

rpm signing keys (Was: Suggestion: Use a unified kernel image by default in the future.)

2022-07-04 Thread Dominique Martinet
Michael Catanzaro wrote on Mon, Jul 04, 2022 at 05:48:28PM -0500: > After installing or upgrading your Fedora or RHEL system, you have to accept > a "do you trust this official Fedora project key" prompt or you cannot > install packages from the official repos. So all our users have been trained >

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Michael Catanzaro
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 accep

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Lennart Poettering
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

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Lennart Poettering
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 from

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Lennart Poettering
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 e

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Lennart Poettering
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 kerne

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Richard W.M. Jones
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 from

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Chris Adams
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 under

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Sharpened Blade via devel
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 attestati

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Sharpened Blade via devel
> 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. _

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Sharpened Blade via devel
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 -- devel@lists.fed

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Sharpened Blade via devel
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 wo

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Gerd Hoffmann
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 th

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Lennart Poettering
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 k

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Gerd Hoffmann
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 thos

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Lennart Poettering
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

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Lennart Poettering
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

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Daniel P . Berrangé
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 w

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Demi Marie Obenour
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. >> >> gru

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Lennart Poettering
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. According

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Lennart Poettering
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

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-04 Thread Lennart Poettering
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 in

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-01 Thread Sharpened Blade via devel
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. ___

Re: Suggestion: Use a unified kernel image by default in the future.

2022-07-01 Thread Gerd Hoffmann
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 r

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-30 Thread Gerd Hoffmann
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 in

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-30 Thread David Airlie
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

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-30 Thread Sharpened Blade via devel
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: http

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-28 Thread Petr Pisar
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 co

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-28 Thread Sharpened Blade via devel
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. __

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-28 Thread David Howells
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 acces

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-28 Thread David Howells
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

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-28 Thread Sharpened Blade via devel
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 Co

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-28 Thread Demi Marie Obenour
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. I

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-28 Thread Robbie Harwood
> 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 can

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-28 Thread Florian Weimer
* 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 mod

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-28 Thread Daniel P . Berrangé
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 installed,

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-28 Thread Vitaly Zaitsev via devel
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 unsign

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-28 Thread Petr Pisar
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. Wh

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-28 Thread Daniel P . Berrangé
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

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Vitaly Zaitsev via devel
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 T

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Vitaly Zaitsev via devel
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, if

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Demi Marie Obenour
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 we

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Sharpened Blade via devel
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.

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Sharpened Blade via devel
> 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 signing/trust

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Sharpened Blade via devel
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 Conduc

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Sharpened Blade via devel
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 th

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Sharpened Blade via devel
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: htt

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Sharpened Blade via devel
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 so

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread 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 module > signatures in Secure

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Daniel P . Berrangé
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, 202

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Neal Gompa
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 4:14

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Daniel P . Berrangé
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, Ro

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Neal Gompa
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 wrote

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Daniel P . Berrangé
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. Thi

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Gerd Hoffmann
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 be

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-27 Thread Florian Weimer
* 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, Florian

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-26 Thread Sharpened Blade via devel
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: https://docs.fedoraproject.org/en-US/project/c

Re: Suggestion: Use a unified kernel image by default in the future.

2022-06-25 Thread Neal Gompa
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 in

  1   2   >