.
Quick glance would work if it is readable. Currently it is not if one is
viewing it in 80 cols screen/window. They do that. Writing return on the same
line does not add specific value IMO.
Up to you; I pointed it out as 80 columns rule makes sense to me.
--
- P J P
47AF CE69 3A90 54AA 9045
.
Quick glance would work if it is readable. Currently it is not if one is
viewing it in 80 cols screen/window. They do that. Writing return on the same
line does not add specific value IMO.
Up to you; I pointed it out as 80 columns rule makes sense to me.
--
- P J P
47AF CE69 3A90 54AA 9045
+-- On Wed, 4 Oct 2017, Borislav Petkov wrote --+
| On Wed, Oct 04, 2017 at 12:26:11PM +0530, P J P wrote:
| > Each return above needs to be on its own line.
|
| ... because?
It appears to cross 80 columns limit, checkpatch.pl throws warnings. Adding
new line would be consistent with cod
+-- On Wed, 4 Oct 2017, Borislav Petkov wrote --+
| On Wed, Oct 04, 2017 at 12:26:11PM +0530, P J P wrote:
| > Each return above needs to be on its own line.
|
| ... because?
It appears to cross 80 columns limit, checkpatch.pl throws warnings. Adding
new line would be consistent with cod
SEV_CMD_RECEIVE_UPDATE_VMSA:return sizeof(struct
sev_data_receive_update_vmsa);
| + case SEV_CMD_LAUNCH_UPDATE_SECRET:return sizeof(struct
sev_data_launch_secret);
| + default:return 0;
| + }
Each return above needs to be on its own line.
--
- P J P
47AF CE69
SEV_CMD_RECEIVE_UPDATE_VMSA:return sizeof(struct
sev_data_receive_update_vmsa);
| + case SEV_CMD_LAUNCH_UPDATE_SECRET:return sizeof(struct
sev_data_launch_secret);
| + default:return 0;
| + }
Each return above needs to be on its own line.
--
- P J P
47AF CE69
err;
| +
| + sp->psp_data = psp;
| ...
| +e_err:
| + sp->psp_data = NULL;
Needs to kfree(sp->psp_data) before setting to NULL.
--
- P J P
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F
err;
| +
| + sp->psp_data = psp;
| ...
| +e_err:
| + sp->psp_data = NULL;
Needs to kfree(sp->psp_data) before setting to NULL.
--
- P J P
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F
+-- On Wed, 23 Nov 2016, Paolo Bonzini wrote --+
| On 23/11/2016 21:15, Radim Krčmář wrote:
| > KVM was using arrays of size KVM_MAX_VCPUS with vcpu_id, but ID can be
| > bigger that the maximal number of VCPUs, resulting in out-of-bounds
| > access.
| >
| > Found by syzkaller:
| >
| > BUG:
+-- On Wed, 23 Nov 2016, Paolo Bonzini wrote --+
| On 23/11/2016 21:15, Radim Krčmář wrote:
| > KVM was using arrays of size KVM_MAX_VCPUS with vcpu_id, but ID can be
| > bigger that the maximal number of VCPUs, resulting in out-of-bounds
| > access.
| >
| > Found by syzkaller:
| >
| > BUG:
using lzo
| INITRAMFS_COMPRESSION_LZ4 Compress using lz4
I haven't tested the patch yet, but does it preserve the CONFIG_RD_*
options' functionality?
Would unifying the two options into one be a good idea?
--
- P J P
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F
--
To unsubscribe from this list: send the line &q
Compress using lz4
I haven't tested the patch yet, but does it preserve the CONFIG_RD_*
options' functionality?
Would unifying the two options into one be a good idea?
--
- P J P
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F
--
To unsubscribe from this list: send the line unsubscribe
r.
I don't get it. You mean one option for build time compression and another
for run time compression? Shouldn't those two be exactly same?
--
- P J P
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
compression and another
for run time compression? Shouldn't those two be exactly same?
--
- P J P
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
+-- On Tue, 8 Apr 2014, Paul Bolle wrote --+
| lkml.org shows nothing for me, currently, but I think it's the same one as
| http://marc.info/?l=linux-kernel=138536209816822=2 .
Yes, that's the one.
--
- P J P
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
Please see -> https://lkml.org/lkml/2013/11/25/21
@Andrew: is it queued to be merged upstream?
Thank you.
--
- P J P
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.
://lkml.org/lkml/2013/11/25/21
@Andrew: is it queued to be merged upstream?
Thank you.
--
- P J P
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
+-- On Tue, 8 Apr 2014, Paul Bolle wrote --+
| lkml.org shows nothing for me, currently, but I think it's the same one as
| http://marc.info/?l=linux-kernelm=138536209816822w=2 .
Yes, that's the one.
--
- P J P
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hi,
+-- On Fri, 20 Dec 2013, Linus Torvalds wrote --+
| So commit 1bf49dd4be0b ("./Makefile: export initial ramdisk
| compression config option") seems to be totally broken.
|
| And I'm not saying that because Jan fixed a make-3.80 incompatibility
| in commit 7ac181568342 ("fix build with
Hi,
+-- On Fri, 20 Dec 2013, Linus Torvalds wrote --+
| So commit 1bf49dd4be0b (./Makefile: export initial ramdisk
| compression config option) seems to be totally broken.
|
| And I'm not saying that because Jan fixed a make-3.80 incompatibility
| in commit 7ac181568342 (fix build with make
Hello Simon, Andrew
+-- On Wed, 11 Dec 2013, Simon Guinot wrote --+
| IIUC this patch, the INITRAMFS_COMPRESSION_* options are now
| ignored/useless. Don't you think we should remove them from the
| usr/Kconfig file ?
-> https://lkml.org/lkml/2013/11/25/21
I'v pushed a patch from Mr Hristo
Hello Simon, Andrew
+-- On Wed, 11 Dec 2013, Simon Guinot wrote --+
| IIUC this patch, the INITRAMFS_COMPRESSION_* options are now
| ignored/useless. Don't you think we should remove them from the
| usr/Kconfig file ?
- https://lkml.org/lkml/2013/11/25/21
I'v pushed a patch from Mr Hristo
file with the CONFIG_RD_GZIP=y, for
INITRAMFS_COMPRESSION_GZIP is not set. Also removed the
corresponding Kconfig choice text for all INITRAMFS_COMPRESSION_*
options.
Signed-off-by: P J P
diff --git a/arch/mips/configs/nlm_xlr_defconfig
b/arch/mips/configs/nlm_xlr_defconfig
index 44b4734..17388d0 10
defconfig file with the CONFIG_RD_GZIP=y, for
INITRAMFS_COMPRESSION_GZIP is not set. Also removed the
corresponding Kconfig choice text for all INITRAMFS_COMPRESSION_*
options.
Signed-off-by: P J P pra...@redhat.com
diff --git a/arch/mips/configs/nlm_xlr_defconfig
b/arch/mips/configs
Security Response TeamFrom 352781fd2846c54e92ae0c37dd972dc5fcdfb695 Mon Sep 17 00:00:00 2001
From: P J P
Date: Thu, 31 Oct 2013 12:03:00 +0530
Subject: Read CONFIG_RD_ variables for initramfs compression
When expert configuration option(CONFIG_EXPERT) is enabled,
menuconfig offers a choice
Security Response TeamFrom 352781fd2846c54e92ae0c37dd972dc5fcdfb695 Mon Sep 17 00:00:00 2001
From: P J P pra...@redhat.com
Date: Thu, 31 Oct 2013 12:03:00 +0530
Subject: Read CONFIG_RD_ variables for initramfs compression
When expert configuration option(CONFIG_EXPERT) is enabled,
menuconfig
Hello Andrew,
+-- On Tue, 29 Oct 2013, Andrew Morton wrote --+
| On Tue, 15 Oct 2013 20:25:57 +0530 (IST) P J P wrote:
| This patch breaks my x86_64 allmodconfig build, because I don't have
| the lz4 executable installed:
|
| /usr/src/25/scripts/gen_initramfs_list.sh: line 307: lz4: command
Hello Andrew,
+-- On Tue, 29 Oct 2013, Andrew Morton wrote --+
| On Tue, 15 Oct 2013 20:25:57 +0530 (IST) P J P ppan...@redhat.com wrote:
| This patch breaks my x86_64 allmodconfig build, because I don't have
| the lz4 executable installed:
|
| /usr/src/25/scripts/gen_initramfs_list.sh: line
, it could be better to remove their description/references from
usr/Kconfig and other places.
Thank you.
--
Prasad J Pandit / Red Hat Security Response TeamFrom 0304fb400c27227106c1f9a57fe3de13ca03cca2 Mon Sep 17 00:00:00 2001
From: P J P
Date: Tue, 15 Oct 2013 19:28:40 +0530
Subject: Read
. But if they are not
used, it could be better to remove their description/references from
usr/Kconfig and other places.
Thank you.
--
Prasad J Pandit / Red Hat Security Response TeamFrom 0304fb400c27227106c1f9a57fe3de13ca03cca2 Mon Sep 17 00:00:00 2001
From: P J P pra...@redhat.com
Date: Tue, 15 Oct 2013 19
version, I missed to include init/do_mounts_rd.c
changes in the previous one.
Thank you.
--
Prasad J Pandit / Red Hat Security Response TeamFrom 14dccee98f12f2dbca224510bcfedd1a397ed177 Mon Sep 17 00:00:00 2001
From: P J P
Date: Thu, 10 Oct 2013 20:37:48 +0530
Subject: Export initial ramdisk
, an updated patch which adds the export snippet
to the top level ./Makefile. I tried init/Makefile too, but it does not seem
to work.
Thank you!
--
Prasad J Pandit / Red Hat Security Response TeamFrom 2bb603f666371289ee660be5cf7a6f87740edd8e Mon Sep 17 00:00:00 2001
From: P J P
Date: Thu, 10 Oct 2013 19
Hello Andrew,
+-- On Wed, 9 Oct 2013, Andrew Morton wrote --+
| It would be better to make the change in one place, rather than for each
| architecture. That would appear to involve moving a hunk from
| arch/x86/Makefile into init/Makefile, or perhaps ./Makefile.
Right, I was trying to
Hello Andrew,
+-- On Wed, 9 Oct 2013, Andrew Morton wrote --+
| It would be better to make the change in one place, rather than for each
| architecture. That would appear to involve moving a hunk from
| arch/x86/Makefile into init/Makefile, or perhaps ./Makefile.
Right, I was trying to
, an updated patch which adds the export snippet
to the top level ./Makefile. I tried init/Makefile too, but it does not seem
to work.
Thank you!
--
Prasad J Pandit / Red Hat Security Response TeamFrom 2bb603f666371289ee660be5cf7a6f87740edd8e Mon Sep 17 00:00:00 2001
From: P J P pra...@redhat.com
Date: Thu
version, I missed to include init/do_mounts_rd.c
changes in the previous one.
Thank you.
--
Prasad J Pandit / Red Hat Security Response TeamFrom 14dccee98f12f2dbca224510bcfedd1a397ed177 Mon Sep 17 00:00:00 2001
From: P J P pra...@redhat.com
Date: Thu, 10 Oct 2013 20:37:48 +0530
Subject: Export
Hi,
+-- On Sat, 5 Oct 2013, Andrew Morton wrote --+
| On Sun, 6 Oct 2013 02:12:15 +0530 (IST) P J P wrote:
| Not yet, but it's in the queue.
I see; Thank you for an update. I appreciate it.
Please let me know if there are changes to be done. Or if you think I could
send similar patches
Hi,
+-- On Sat, 5 Oct 2013, Andrew Morton wrote --+
| On Sun, 6 Oct 2013 02:12:15 +0530 (IST) P J P ppan...@redhat.com wrote:
| Not yet, but it's in the queue.
I see; Thank you for an update. I appreciate it.
Please let me know if there are changes to be done. Or if you think I could
send
Hello Andrew,
Just to check, did you have a chance to review it further? Are you waiting on
me for something?
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Hello Andrew,
Just to check, did you have chance to review an updated patch?
--
Prasad J Pandit / Red Hat Security Response Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hello Andrew,
Just to check, did you have chance to review an updated patch?
--
Prasad J Pandit / Red Hat Security Response Team
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hello Andrew,
Just to check, did you have a chance to review it further? Are you waiting on
me for something?
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Hello Andrew,
I was wondering if you had a chance to review the updated patch that I sent.
You aren't waiting on me for something, are you?
Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B
--
To unsubscribe from this list: send
Hello Andrew,
I was wondering if you had a chance to review this patch further? Should I
send similar patches for other architectures too? As in you aren't waiting on
me for that, are you?
Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860
Hello Andrew,
I was wondering if you had a chance to review this patch further? Should I
send similar patches for other architectures too? As in you aren't waiting on
me for that, are you?
Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860
Hello Andrew,
I was wondering if you had a chance to review the updated patch that I sent.
You aren't waiting on me for something, are you?
Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B
--
To unsubscribe from this list: send
+-- On Wed, 25 Sep 2013, Rob Landley wrote --+
| Ah, so it's an out of tree bespoke Red Hat tool. No wonder I couldn't find it.
It is not Red Hat tool.
| You're reimplemented the posix "pax" command?
Ummn, not sure. Didn't see anything about 'pax'.
| Is this what you're currently doing,
+-- On Wed, 25 Sep 2013, Rob Landley wrote --+
| Ah, so it's an out of tree bespoke Red Hat tool. No wonder I couldn't find it.
It is not Red Hat tool.
| You're reimplemented the posix pax command?
Ummn, not sure. Didn't see anything about 'pax'.
| Is this what you're currently doing, or
Hello Andrew,
Thank you so much for reviewing these patches.
+-- On Mon, 23 Sep 2013, Andrew Morton wrote --+
| It's a bit confusing whether all this appiles to initrd, to initramfs
| or to both. Can you please clarify all this and be sure that it's all
| consistent?
IIUC, we no longer
Hello Rob,
+-- On Mon, 23 Sep 2013, Rob Landley wrote --+
| I've been building kernels, including with initramfs, and I don't have
| dracut(8) installed? In today's git:
dracut(8) is a separate tool installed from package dracut.
-> dracut-029-2.fc19.x86_64
->
t / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602BFrom 842d328ba52cb53ec057b0703fbc8fbc2a2d6f1a Mon Sep 17 00:00:00 2001
From: P J P
Date: Tue, 24 Sep 2013 23:59:21 +0530
Subject: [PATCH] Fix NULL pointer dereference while loading initramfs
Make menuconfig
Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602BFrom 842d328ba52cb53ec057b0703fbc8fbc2a2d6f1a Mon Sep 17 00:00:00 2001
From: P J P pra...@redhat.com
Date: Tue, 24 Sep 2013 23:59:21 +0530
Subject: [PATCH] Fix NULL pointer dereference while loading initramfs
Make menuconfig allows one
Hello Rob,
+-- On Mon, 23 Sep 2013, Rob Landley wrote --+
| I've been building kernels, including with initramfs, and I don't have
| dracut(8) installed? In today's git:
dracut(8) is a separate tool installed from package dracut.
- dracut-029-2.fc19.x86_64
-
Hello Andrew,
Thank you so much for reviewing these patches.
+-- On Mon, 23 Sep 2013, Andrew Morton wrote --+
| It's a bit confusing whether all this appiles to initrd, to initramfs
| or to both. Can you please clarify all this and be sure that it's all
| consistent?
IIUC, we no longer
Hello,
NULL pointer dereference while loading initramfs
-> https://lkml.org/lkml/2013/9/15/20
Export initial ramdisk compression config option
-> https://lkml.org/lkml/2013/9/15/22
Could someone have a look at these patches please?
Thank you.
--
Prasad J Pandit / Red Hat Security
Hello,
NULL pointer dereference while loading initramfs
- https://lkml.org/lkml/2013/9/15/20
Export initial ramdisk compression config option
- https://lkml.org/lkml/2013/9/15/22
Could someone have a look at these patches please?
Thank you.
--
Prasad J Pandit / Red Hat Security
p 17 00:00:00 2001
From: P J P
Date: Sun, 15 Sep 2013 13:37:43 +0530
Subject: [PATCH 2/2] Export initial ramdisk compression config option
Make menuconfig allows one to choose compression format of an
initial ramdisk image. But this choice does not result in duly
compressed ramdisk image. Bec
nic("VFS: Unable to mount root fs on %s", b);
Could someone please review this patch?
Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602BFrom 4ff1ddae358dff002080d753e45721a89d07b3af Mon Sep 17 00:00:00 2001
From: P J P
Date
: Unable to mount root fs on %s, b);
Could someone please review this patch?
Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602BFrom 4ff1ddae358dff002080d753e45721a89d07b3af Mon Sep 17 00:00:00 2001
From: P J P pra...@redhat.com
Date
:00:00 2001
From: P J P pra...@redhat.com
Date: Sun, 15 Sep 2013 13:37:43 +0530
Subject: [PATCH 2/2] Export initial ramdisk compression config option
Make menuconfig allows one to choose compression format of an
initial ramdisk image. But this choice does not result in duly
compressed ramdisk image
Hello,
-> https://lkml.org/lkml/2013/8/7/259
I wanted to confirm if this above fix should also go into ARM64 build Or is
ARM64 platform not vulnerable?
===
$ git diff
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 9ba33c4..cbed82f 100644
---
Hello,
- https://lkml.org/lkml/2013/8/7/259
I wanted to confirm if this above fix should also go into ARM64 build Or is
ARM64 platform not vulnerable?
===
$ git diff
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 9ba33c4..cbed82f 100644
---
| No no. Vasily patched cciss_ioctl32_big_passthru() and this patch
| changes cciss_ioctl32_passthru().
Oops, yeah, I missed the `big' part!
Thanks.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B
--
To unsubscribe from this list: send the
Hello Dan,
===
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 6374dc1..34971aa 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -1201,6 +1201,7 @@ static int cciss_ioctl32_passthru(struct block_device
*bdev, fmode_t mode,
int err;
u32 cp;
+
Hello Dan,
===
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 6374dc1..34971aa 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -1201,6 +1201,7 @@ static int cciss_ioctl32_passthru(struct block_device
*bdev, fmode_t mode,
int err;
u32 cp;
+
| No no. Vasily patched cciss_ioctl32_big_passthru() and this patch
| changes cciss_ioctl32_passthru().
Oops, yeah, I missed the `big' part!
Thanks.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B
--
To unsubscribe from this list: send the
+-- On Thu, 4 Apr 2013, Jaegeuk Kim wrote --+
| Why should we take unnecessary locks and an f2fs_submit_bio call?
Yep, we should not. I wasn't sure if these are unnecessary when
a_ops->writepage = NULL.
Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| I'm confusing the question because f2fs doesn't use generic_writepages(),
| since f2fs_write_data_pages() is linked to a_ops->writepages. In
| do_writepages(), always f2fs_write_data_pages() is triggered instead of
| generic_writepages(). Isn't
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
| index 47a2d7c..cf9ff5f 100644
| --- a/fs/f2fs/data.c
| +++ b/fs/f2fs/data.c
| @@ -559,6 +559,10 @@ static int f2fs_write_data_pages(struct
| address_space *mapping,
| int ret;
| long
Hello Jaegeuk,
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| Therefore, I think f2fs_write_data_pages() is better to handle this. Please
| review the modified patch. Thanks,
|
| diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
| index 47a2d7c..cf9ff5f 100644
| --- a/fs/f2fs/data.c
| +++
+-- On Thu, 4 Apr 2013, Jaegeuk Kim wrote --+
| Why should we take unnecessary locks and an f2fs_submit_bio call?
Yep, we should not. I wasn't sure if these are unnecessary when
a_ops-writepage = NULL.
Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB
Hello Jaegeuk,
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| Therefore, I think f2fs_write_data_pages() is better to handle this. Please
| review the modified patch. Thanks,
|
| diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
| index 47a2d7c..cf9ff5f 100644
| --- a/fs/f2fs/data.c
| +++
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
| index 47a2d7c..cf9ff5f 100644
| --- a/fs/f2fs/data.c
| +++ b/fs/f2fs/data.c
| @@ -559,6 +559,10 @@ static int f2fs_write_data_pages(struct
| address_space *mapping,
| int ret;
| long
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| I'm confusing the question because f2fs doesn't use generic_writepages(),
| since f2fs_write_data_pages() is linked to a_ops-writepages. In
| do_writepages(), always f2fs_write_data_pages() is triggered instead of
| generic_writepages(). Isn't it?
Hello,
Commit - fa9150a84c - replaces a call to generic_writepages() in
f2fs_write_data_pages() with write_cache_pages(), with a function pointer
argument pointing to routine: __f2fs_writepage.
-> https://git.kernel.org/linus/fa9150a84ca333f68127097c4fa1eda4b3913a22
The patch below adds
Hello,
Commit - fa9150a84c - replaces a call to generic_writepages() in
f2fs_write_data_pages() with write_cache_pages(), with a function pointer
argument pointing to routine: __f2fs_writepage.
- https://git.kernel.org/linus/fa9150a84ca333f68127097c4fa1eda4b3913a22
The patch below adds
+-- On Sat, 24 Nov 2012, Kees Cook wrote --+
| Well, "ever" meaning "if depth is hit, always fail out", yes. This is
| intentional. We do not want to attempt module loading if we hit a recursion
| limit.
Ah yes, that's right!
Thanks so much! :)
--
Prasad J Pandit / Red Hat Security Response
+-- On Sat, 24 Nov 2012, Kees Cook wrote --+
| Well, ever meaning if depth is hit, always fail out, yes. This is
| intentional. We do not want to attempt module loading if we hit a recursion
| limit.
Ah yes, that's right!
Thanks so much! :)
--
Prasad J Pandit / Red Hat Security Response Team
Hello Kees, all,
Please have a look at a *NEW* patch at the end of this mail. It seems to fix
both the issues, stack disclosure + undue recursions.
It uses modprobe "--first-time" option which returns an error code when trying
to load a module which is already present or unload one which
Hello Kees, all,
Please have a look at a *NEW* patch at the end of this mail. It seems to fix
both the issues, stack disclosure + undue recursions.
It uses modprobe --first-time option which returns an error code when trying
to load a module which is already present or unload one which is
+-- On Mon, 19 Nov 2012, Kees Cook wrote --+
| I think to avoid the explosion of request_module calls in the abusive
| case, we could simply return ELOOP instead of ENOEXEC on max
| recursion.
-> http://www.spinics.net/lists/mm-commits/msg92433.html
1. returning -ELOOP has a side effect of not
+-- On Mon, 19 Nov 2012, Kees Cook wrote --+
| I think to avoid the explosion of request_module calls in the abusive
| case, we could simply return ELOOP instead of ENOEXEC on max
| recursion.
- http://www.spinics.net/lists/mm-commits/msg92433.html
1. returning -ELOOP has a side effect of not
+-- On Mon, 19 Nov 2012, Linus Torvalds wrote --+
| isn't your patch the one that does a request_module even without trying
| without it? There was a discussion about why that isn't valid. Don't do it.
Yep, okay.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB
+-- On Mon, 19 Nov 2012, Kees Cook wrote --+
| I don't think you're being rude at all. You're defending your solution. :)
Thank you Kees, really appreciate it.
| However, it also changes the conditions for when a module is loaded
| (i.e. 0x7f no longer triggers a module_load, so anything
+-- On Mon, 19 Nov 2012, Kees Cook wrote --+
| I don't think you're being rude at all. You're defending your solution. :)
Thank you Kees, really appreciate it.
| However, it also changes the conditions for when a module is loaded
| (i.e. 0x7f no longer triggers a module_load, so anything
+-- On Mon, 19 Nov 2012, Linus Torvalds wrote --+
| isn't your patch the one that does a request_module even without trying
| without it? There was a discussion about why that isn't valid. Don't do it.
Yep, okay.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB
+-- On Sun, 18 Nov 2012, Kees Cook wrote --+
| This is the second problem. I view this as less critical because it's only
| 64 instead of 4, but it certainly should be solved as well.
I don't mean to be rude, but the patch I had sent solves both of these
problems with much less performance
+-- On Fri, 16 Nov 2012, Kees Cook wrote --+
| Hrm? It should be showing only the live heap-allocated interp -- are
| you seeing uninitialized contents?
I don't see uninitialised content; I see interpreter names from previous
iterations. Which was the case earlier as well. The - interp - array
+-- On Fri, 16 Nov 2012, Kees Cook wrote --+
| Hrm? It should be showing only the live heap-allocated interp -- are
| you seeing uninitialized contents?
I don't see uninitialised content; I see interpreter names from previous
iterations. Which was the case earlier as well. The - interp - array
+-- On Sun, 18 Nov 2012, Kees Cook wrote --+
| This is the second problem. I view this as less critical because it's only
| 64 instead of 4, but it certainly should be solved as well.
I don't mean to be rude, but the patch I had sent solves both of these
problems with much less performance
Hello folks,
+-- On Mon, 12 Nov 2012, Kees Cook wrote --+
| > Al, what's your take on the *rare* extra call to request_module?
|
| Without any other feedback, I'd like to use my minimal allocation
| patch, since it fixes the problem and doesn't change any of the
| semantics of how/when
Hello folks,
+-- On Mon, 12 Nov 2012, Kees Cook wrote --+
|Al, what's your take on the *rare* extra call to request_module?
|
| Without any other feedback, I'd like to use my minimal allocation
| patch, since it fixes the problem and doesn't change any of the
| semantics of how/when
Hello Kees, Al,
+-- On Sat, 27 Oct 2012, Kees Cook wrote --+
| If we change binfmt_script to not make a recursive call, then we still
| need to keep the interp change somewhere off the stack. I still think
| my patchset is the least bad.
|
| Al, do you have something else in mind?
Guys, are
Hello Kees, Al,
+-- On Sat, 27 Oct 2012, Kees Cook wrote --+
| If we change binfmt_script to not make a recursive call, then we still
| need to keep the interp change somewhere off the stack. I still think
| my patchset is the least bad.
|
| Al, do you have something else in mind?
Guys, are
+-- On Sat, 27 Oct 2012, Kees Cook wrote --+
| Al showed a list of them earlier in the thread.
Yeah, the list Al showed and I came across mostly has - binfmt_aout - entry.
Do people still use - a.out - format? (considering ELF has been the default
standard for so many years)
| I don't have
+-- On Fri, 26 Oct 2012, Al Viro wrote --+
| > not. Module alias could dodge this though, I guess.
| "Could"? Can you show a single module that would have name matching
| binfmt-[0-9a-f]*? In other words, are they ever loaded _not_ via an
| alias?
I understand. I was wondering if alias
+-- On Fri, 26 Oct 2012, Al Viro wrote --+
| not. Module alias could dodge this though, I guess.
| Could? Can you show a single module that would have name matching
| binfmt-[0-9a-f]*? In other words, are they ever loaded _not_ via an
| alias?
I understand. I was wondering if alias
+-- On Sat, 27 Oct 2012, Kees Cook wrote --+
| Al showed a list of them earlier in the thread.
Yeah, the list Al showed and I came across mostly has - binfmt_aout - entry.
Do people still use - a.out - format? (considering ELF has been the default
standard for so many years)
| I don't have
+-- On Thu, 25 Oct 2012, Al Viro wrote --+
| * every bleeding script will have bogus execution of modprobe done
| at execve time (and you'd better pray that /sbin/modprobe isn't a shell
| script wrapper around the actual binary, or you *will* get loop prevention
| kick in)
| * none of
+-- On Thu, 25 Oct 2012, Al Viro wrote --+
| * every bleeding script will have bogus execution of modprobe done
| at execve time (and you'd better pray that /sbin/modprobe isn't a shell
| script wrapper around the actual binary, or you *will* get loop prevention
| kick in)
| * none of
1 - 100 of 104 matches
Mail list logo
