Re: [Part2 PATCH v4.1 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-04 Thread P J P
. 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

Re: [Part2 PATCH v4.1 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-04 Thread P J P
+-- 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

Re: [Part2 PATCH v4.1 07/29] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

2017-10-03 Thread P J P
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

Re: [Part2 Patch v4.2] crypto: ccp: Add Platform Security Processor (PSP) device support

2017-10-03 Thread P J P
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

Re: [PATCH] KVM: x86: fix out-of-bounds accesses of rtc_eoi map

2016-11-23 Thread P J P
+-- 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: KAS

Re: [PATCH] initramfs: allow again choice of the embedded compression algorithm

2014-09-29 Thread P J P
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 t

Re: [PATCH] initramfs: remove "compression mode" choice

2014-04-11 Thread P J P
t be better. 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

Re: [PATCH] initramfs: remove "compression mode" choice

2014-04-08 Thread P J P
+-- 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&m=138536209816822&w=2 . Yes, that's the one. -- - P J P -- To unsubscribe from this list: send the line "unsubscri

Re: [PATCH] initramfs: remove "compression mode" choice

2014-04-08 Thread P J P
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.

Re: Broken initrd compression settings in 3.13

2013-12-23 Thread P J P
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

Re: [Patch] Read CONFIG_RD_ variables for initramfs compression

2013-12-11 Thread P J P
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 t

[PATCH 1/1] Drop INITRAMFS_COMPRESSION_GZIP option

2013-11-24 Thread P J P
nfig 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..

Re: [Patch] Read CONFIG_RD_ variables for initramfs compression

2013-10-31 Thread P J P
/ Red Hat 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

Re: [Patch] Read CONFIG_RD_ variables for initramfs compression

2013-10-30 Thread P J P
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: co

[Patch] Read CONFIG_RD_ variables for initramfs compression

2013-10-15 Thread P J P
y 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 Date: Tue, 15 Oct 2013 19:28:40 +053

Re: [PATCH 2/2] Export initial ramdisk compression config

2013-10-10 Thread P J P
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

Re: [PATCH 2/2] Export initial ramdisk compression config

2013-10-10 Thread P J P
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

Re: [PATCH 2/2] Export initial ramdisk compression config

2013-10-10 Thread P J P
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 fi

Re: [PATCH 1/2] Fix NULL pointer dereference while loading initramfs

2013-10-06 Thread P J P
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 pa

Re: [PATCH 2/2] Export initial ramdisk compression config

2013-10-05 Thread P J P
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

Re: [PATCH 1/2] Fix NULL pointer dereference while loading initramfs

2013-10-05 Thread P J P
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 http://vger.ke

Re: [PATCH 1/2] Fix NULL pointer dereference while loading initramfs

2013-09-30 Thread P J P
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 t

Re: [PATCH 2/2] Export initial ramdisk compression config

2013-09-30 Thread P J P
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

Re: [PATCH 2/2] Export initial ramdisk compression config

2013-09-26 Thread P J P
+-- 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

Re: [PATCH 2/2] Export initial ramdisk compression config

2013-09-24 Thread P J P
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 use

Re: [PATCH 1/2] Fix NULL pointer dereference while loading initramfs

2013-09-24 Thread P J P
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 -> https://dracut.wiki.kernel.or

Re: [PATCH 1/2] Fix NULL pointer dereference while loading initramfs

2013-09-24 Thread P J P
to do that. Thank you so much! -- Prasad J Pandit / 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 der

Need patch review

2013-09-20 Thread P J P
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 Respon

[PATCH 2/2] Export initial ramdisk compression config

2013-09-15 Thread P J P
on Sep 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

[PATCH 1/2] Fix NULL pointer dereference while loading initramfs

2013-09-15 Thread P J P
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

About perf,arm -- oops in validate_event

2013-08-20 Thread P J P
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 --- a/arch/arm64

Re: [patch] cciss: info leak in cciss_ioctl32_passthru()

2013-06-04 Thread P J P
| 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 l

Re: [patch] cciss: info leak in cciss_ioctl32_passthru()

2013-06-04 Thread P J P
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; +

Re: [PATCH] To add NULL pointer check

2013-04-03 Thread P J P
+-- 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 C9

Re: [PATCH] To add NULL pointer check

2013-04-03 Thread P J P
+-- 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?

Re: [PATCH] To add NULL pointer check

2013-04-03 Thread P J P
+-- 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 excess_nr

Re: [PATCH] To add NULL pointer check

2013-04-02 Thread P J P
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 | +++ b/fs/f2fs

[PATCH] To add NULL pointer check

2013-04-02 Thread P J P
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

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-11-25 Thread P J P
+-- 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 T

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-11-23 Thread P J P
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

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-11-22 Thread P J P
+-- 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 r

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-11-19 Thread P J P
+-- 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 C939

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-11-19 Thread P J P
+-- 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 needi

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-11-18 Thread P J P
+-- 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 hit

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-11-18 Thread P J P
+-- 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 i

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-11-16 Thread P J P
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 loadi

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-11-06 Thread P J P
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

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-10-27 Thread P J P
+-- 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 an

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-10-27 Thread P J P
+-- 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 informa

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-10-26 Thread P J P
+-- 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 t

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-10-25 Thread P J P
Hello Tetsuo, +-- On Thu, 25 Oct 2012, Tetsuo Handa wrote --+ | Excuse me, but why do you change definition of printable(c) ? | Looks like a regression. #define printable(c) (((c)=='\t') || ((c)=='\n') || (0x20<=(c) && (c)<=0x7e)) Earlier definition of printable() as above was used to - bre

Re: [PATCH] exec: do not leave bprm->interp on stack

2012-10-25 Thread P J P
Hello Kees, +-- On Wed, 24 Oct 2012, Kees Cook wrote --+ | What should the code here _actually_ be doing? The _script and _misc | handlers expect to rewrite the bprm contents and recurse, but the module | loader want to try again. It's not clear to me what the binfmt module | handler is even