Re: New bug in Audit
On 2023-01-05 11:31, Steve Grubb wrote: > On Thursday, January 5, 2023 10:41:49 AM EST Paul Moore wrote: > > On Thu, Jan 5, 2023 at 8:38 AM Ariel Silver wrote: > > > I found the following bug: > > > > > > OS version = Red Hat Enterprise Linux release 8.6 (Ootpa) > > > Kernel version = 4.18.0-425.3.1.el8.x86_64 > > > auditctl version = 3.0.7 > > > > This mailing list is focused on the development and support of > > upstream Linux Kernels and Steve's audit userspace, we don't really > > provide support for paid distributions. If you are seeing problems > > with the upstream Linux Kernel or tools, please report them here, but > > issues with distribution kernels and/or tools should be sent to the > > distribution for support/assistance. > > Paul, we take bug reports and help requests from anyone. Often, distributions > are how we first hear of problems. We did, it is filed upstream as: https://github.com/linux-audit/audit-kernel/issues/138 > > I believe you should be able to submit a bug report against Red Hat > > Enterprise Linux using the Red Hat bugzilla instance at the URL below: > > I believe this is fixed by this commit: > > https://github.com/linux-audit/audit-kernel/commit/ > 1b2263a807ca651f94517b1b22dc5f13e494984d Yes, that commit fixes that bug upstream. It has been backported to RHEL. > -Steve - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: New bug in Audit
On Thu, Jan 5, 2023 at 11:32 AM Steve Grubb wrote: > On Thursday, January 5, 2023 10:41:49 AM EST Paul Moore wrote: > > On Thu, Jan 5, 2023 at 8:38 AM Ariel Silver > wrote: > > > I found the following bug: > > > > > > OS version = Red Hat Enterprise Linux release 8.6 (Ootpa) > > > Kernel version = 4.18.0-425.3.1.el8.x86_64 > > > auditctl version = 3.0.7 > > > > This mailing list is focused on the development and support of > > upstream Linux Kernels and Steve's audit userspace, we don't really > > provide support for paid distributions. If you are seeing problems > > with the upstream Linux Kernel or tools, please report them here, but > > issues with distribution kernels and/or tools should be sent to the > > distribution for support/assistance. > > Paul, we take bug reports and help requests from anyone. Often, distributions > are how we first hear of problems. Steve, re-read what I wrote. This mailing list is *focused* on upstream work and support, and while it does not preclude talking about distro specific bugs, I believe there are better avenues for those discussions (e.g. see the RHBZ link I provided in my response) as upstream isn't really going to be able to provide adequate help for someone experiencing problems with a distro kernel which has a number of patches and backports. If you have a problem with this approach, perhaps we should move upstream development to an audit mailing list on vger.kernel.org and leave this list for RH specific issues? -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: New bug in Audit
On Thursday, January 5, 2023 10:41:49 AM EST Paul Moore wrote: > On Thu, Jan 5, 2023 at 8:38 AM Ariel Silver wrote: > > I found the following bug: > > > > OS version = Red Hat Enterprise Linux release 8.6 (Ootpa) > > Kernel version = 4.18.0-425.3.1.el8.x86_64 > > auditctl version = 3.0.7 > > This mailing list is focused on the development and support of > upstream Linux Kernels and Steve's audit userspace, we don't really > provide support for paid distributions. If you are seeing problems > with the upstream Linux Kernel or tools, please report them here, but > issues with distribution kernels and/or tools should be sent to the > distribution for support/assistance. Paul, we take bug reports and help requests from anyone. Often, distributions are how we first hear of problems. > I believe you should be able to submit a bug report against Red Hat > Enterprise Linux using the Red Hat bugzilla instance at the URL below: I believe this is fixed by this commit: https://github.com/linux-audit/audit-kernel/commit/ 1b2263a807ca651f94517b1b22dc5f13e494984d -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: New bug in Audit
On Thu, Jan 5, 2023 at 8:38 AM Ariel Silver wrote: > I found the following bug: > > OS version = Red Hat Enterprise Linux release 8.6 (Ootpa) > Kernel version = 4.18.0-425.3.1.el8.x86_64 > auditctl version = 3.0.7 This mailing list is focused on the development and support of upstream Linux Kernels and Steve's audit userspace, we don't really provide support for paid distributions. If you are seeing problems with the upstream Linux Kernel or tools, please report them here, but issues with distribution kernels and/or tools should be sent to the distribution for support/assistance. I believe you should be able to submit a bug report against Red Hat Enterprise Linux using the Red Hat bugzilla instance at the URL below: * https://bugzilla.redhat.com -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [RFC PATCH 00/25] Upstream kvx Linux port
On Thu, Jan 5, 2023, at 11:40, Jules Maselbas wrote:
> On Wed, Jan 04, 2023 at 04:58:25PM +0100, Arnd Bergmann wrote:
>> On Tue, Jan 3, 2023, at 17:43, Yann Sionneau wrote:
>> I commented on the syscall patch directly, I think it's
>> important to stop using the deprecated syscalls as soon
>> as possible to avoid having dependencies in too many
>> libc binaries. Almost everything else can be changed
>> easily as you get closer to upstream inclusion.
>>
>> I did not receive most of the other patches as I'm
>> not subscribed to all the mainline lists. For future
>> submissions, can you add the linux-arch list to Cc for
>> all patches?
>
> We misused get_maintainers.pl, running it on each patch instead
> of using it on the whole series. next time every one will be in
> copy of every patch in the series and including linux-arch.
Be careful not to make the list too long though, there is
usually a limit of 1024 characters for the entire Cc list,
above this your mails may get dropped by the mailing lists.
>> Reading the rest of the series through lore.kernel.org,
>> most of the comments I have are for improvements that
>> you may find valuable rather than serious mistakes:
>>
>> - the {copy_to,copy_from,clear}_user functions are
>> well worth optimizing better than the byte-at-a-time
>> version you have, even just a C version built around
>> your __get_user/__put_user inline asm should help, and
>> could be added to lib/usercopy.c.
>
> right, we are using memcpy for {copy_to,copy_from}_user_page
> which has a simple optimized version introduced in
> (kvx: Add some library functions).
> I wonder if it is possible to do the same for copy_*_user functions.
copy_from_user_page() is only about managing cache aliases,
not user access, and it's not used anywhere in the fast
path, so it's a bit different.
arch/arm/lib/copy_template.S has an example for how
you can share the same assembler implementation between
memcpy() and copy_from_user(), but it's not very
intuitive.
The tricky bit with copy_from_user() is the partial copy
that relies on copying the exact amount of data that can
be accessed including the last byte before the end of
the mapping, and returning the correct count of non-copied
bytes.
If you want a C version, you can probably use the
copy_from_kernel_nofault implementation mm/maccess.c
as a template, but have to add code for the correct
return value.
Arnd
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
New bug in Audit
I found the following bug: OS version = Red Hat Enterprise Linux release 8.6 (Ootpa) Kernel version = 4.18.0-425.3.1.el8.x86_64 auditctl version = 3.0.7 Scenario 1: When I load the configurations : *auditctl -a always,exit -S all -F dir=/ -F perm=w -F success=1* And run the command: *cp /tmp/1 /tmp/2* No new log is created in: /var/log/audit/audit.log But the file is indeed copied. Scenario 2: When I load the configurations : *auditctl -a always,exit -S all -F dir=/ -F perm=w -F success=0* And run the command: *cp /tmp/1 /tmp/2* No new log is created in: /var/log/audit/audit.log But the file is indeed copied. Scenario 3: When I load the configurations : *auditctl -a always,exit -S all -F dir=/ -F perm=w* And run the command: *cp /tmp/1 /tmp/2* Yes new log is created in: /var/log/audit/audit.log File was indeed copied. Conclusion: Only when I don't use the -F success new logs are created. Why is that? Any alternative ? -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [RFC PATCH 00/25] Upstream kvx Linux port
Hi,
On Wed, Jan 04, 2023 at 04:58:25PM +0100, Arnd Bergmann wrote:
> On Tue, Jan 3, 2023, at 17:43, Yann Sionneau wrote:
> > This patch series adds support for the kv3-1 CPU architecture of the kvx
> > family
> > found in the Coolidge (aka MPPA3-80) SoC of Kalray.
> >
> > This is an RFC, since kvx support is not yet upstreamed into gcc/binutils,
> > therefore this patch series cannot be merged into Linux for now.
> >
> > The goal is to have preliminary reviews and to fix problems early.
> >
> > The Kalray VLIW processor family (kvx) has the following features:
> > * 32/64 bits execution mode
> > * 6-issue VLIW architecture
> > * 64 x 64bits general purpose registers
> > * SIMD instructions
> > * little-endian
> > * deep learning co-processor
>
> Thanks for posting these, I had been wondering about the
> state of the port. Overall this looks really nice, I can
> see that you and the team have looked at other ports
> and generally made the right decisions.
Thank you and all for the reviews. We are currently going
through every remarks and we are trying to do our best to
send a new patch series with everything addressed.
> I commented on the syscall patch directly, I think it's
> important to stop using the deprecated syscalls as soon
> as possible to avoid having dependencies in too many
> libc binaries. Almost everything else can be changed
> easily as you get closer to upstream inclusion.
>
> I did not receive most of the other patches as I'm
> not subscribed to all the mainline lists. For future
> submissions, can you add the linux-arch list to Cc for
> all patches?
We misused get_maintainers.pl, running it on each patch instead
of using it on the whole series. next time every one will be in
copy of every patch in the series and including linux-arch.
> Reading the rest of the series through lore.kernel.org,
> most of the comments I have are for improvements that
> you may find valuable rather than serious mistakes:
>
> - the {copy_to,copy_from,clear}_user functions are
> well worth optimizing better than the byte-at-a-time
> version you have, even just a C version built around
> your __get_user/__put_user inline asm should help, and
> could be added to lib/usercopy.c.
right, we are using memcpy for {copy_to,copy_from}_user_page
which has a simple optimized version introduced in
(kvx: Add some library functions).
I wonder if it is possible to do the same for copy_*_user functions.
> - The __raw_{read,write}{b,w,l,q} helpers should
> normally be defined as inline asm instead of
> volatile pointer dereferences, I've seen cases where
> the compiler ends up splitting the access or does
> other things you may not want on MMIO areas.
>
> - I would recomment implementing HAVE_ARCH_VMAP_STACK
> as well as IRQ stacks, both of these help to
> avoid data corruption from stack overflow that you
> will eventually run into.
>
> - You use qspinlock as the only available spinlock
> implementation, but only support running on a
> single cluster of 16 cores. It may help to use
> the generic ticket spinlock instead, or leave it
> as a Kconfig option, in particular since you only
> have the emulated xchg16() atomic for qspinlock.
>
> - Your defconfig file enables CONFIG_EMBEDDED, which
> in turn enables CONFIG_EXPERT. This is probably
> not what you want, so better turn off both of these.
>
> - The GENERIC_CALIBRATE_DELAY should not be necessary
> since you have a get_cycles() based delay loop.
> Just set loops_per_jiffy to the correct value based
> on the frequency of the cycle counter, to save
> a little time during boot and get a more accurate
> delay loop.
>
Ack !
Jules
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
