On Wed, Apr 03, 2024 at 09:32:02AM -0700, Andy Lutomirski wrote:
> On Fri, Feb 23, 2024, at 10:30 AM, Eric Biggers wrote:
> > On Fri, Feb 23, 2024 at 06:20:27PM +, Andrew Cooper wrote:
> >> On 23/02/2024 5:54 pm, Eric Biggers wrote:
> >> > On Fri, Feb 23, 20
On Fri, Feb 23, 2024 at 06:20:27PM +, Andrew Cooper wrote:
> On 23/02/2024 5:54 pm, Eric Biggers wrote:
> > On Fri, Feb 23, 2024 at 04:42:11PM +, Andrew Cooper wrote:
> >> Yes, and I agree. We're not looking to try and force this in with
> >> underhand tactics.
On Fri, Feb 23, 2024 at 04:42:11PM +, Andrew Cooper wrote:
>
> Yes, and I agree. We're not looking to try and force this in with
> underhand tactics.
>
> But a blind "nack to any SHA-1" is similarly damaging in the opposite
> direction.
>
Well, reviewers have said they'd prefer that SHA-1
On Fri, Nov 10, 2023 at 05:27:44PM -0500, Ross Philipson wrote:
> arch/x86/boot/compressed/early_sha1.c | 12
> lib/crypto/sha1.c | 81 +
It's surprising to still see this new use of SHA-1 after so many people objected
to it in the v6 patchset.
On Thu, Jun 01, 2023 at 03:24:39PM +0800, Coiby Xu wrote:
> [PATCH 0/5] Support kdump with LUKS encryption by reusing LUKS volume key
The kernel has no concept of LUKS at all. It provides dm-crypt, which LUKS
happens to use. But LUKS is a userspace concept.
This is a kernel patchset, so why
13:04, Matthew Garrett wrote:
> >>>> On Tue, May 09, 2023 at 06:21:44PM -0700, Eric Biggers wrote:
> >>>>
> >>>>> SHA-1 is insecure. Why are you still using SHA-1? Don't TPMs support
> >>>>> SHA-2
> >>>>> now?
On Thu, May 04, 2023 at 02:50:15PM +, Ross Philipson wrote:
> From: "Daniel P. Smith"
>
> The SHA algorithms are necessary to measure configuration information into
> the TPM as early as possible before using the values. This implementation
> uses the established approach of #including the
On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> >
> > And I still don't really understand. After this patchset, there is still
> > code
> > nearly identical to the above (doing a temporary mapping just for a memcpy)
> > that
> > would still be using kmap_atomic().
>
> I don't
On Sat, Oct 10, 2020 at 01:39:54AM +0100, Matthew Wilcox wrote:
> On Fri, Oct 09, 2020 at 02:34:34PM -0700, Eric Biggers wrote:
> > On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> > > The kmap() calls in this FS are localized to a single thread. To avoid
&
On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Jaegeuk Kim
> Cc: Chao Yu
> Signed-off-by: Ira
appears to be the limit that syslinux enforces.
Removed the tail field of struct x86_linux_header because it doesn't seem to
actually be used (is there a reason for it?).
Also, note that bzImage_probe() was incorrectly using `sizeof (header)', even
though header is a pointer.
Signed-off-by: Eric
Allow bzImages smaller than 32KiB to be kexec'ed.
The current code will fail to load a bzImage smaller than 32768 bytes (sizeof
struct x86_linux_header), but the 'memdisk' program that comes with syslinux is
only about 26 KiB. This patch changes the minimum size to 1024 bytes (2
sectors), which
12 matches
Mail list logo
