Re: New bug in Audit
On Mon, Jan 9, 2023 at 10:59 AM Steve Grubb wrote: > On Friday, January 6, 2023 3:33:18 PM EST Paul Moore 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? > > > > Steve, I realize it's only been ~24hrs, but should I assume you are > > okay with that (the upstream focused approach)? > > For the 18 years I've spent on this mail list, it has alway been open to any > topic audit related. I've answered questions for many distributions. If I can > reproduce the issue, then it's a bug worth looking at. If I can't reproduce > it, I let them know. I've even answered questions for people writing their > own audit implementation. Since I was asked to maintain the upstream Linux Kernel audit subsystem I've generally asked people to try and reproduce their problems on a modern~ish upstream Linux Kernel as it simply isn't sustainable for me to replicate the environment of every problem report. Enterprise distributions which run old and/or heavily patched Linux Kernels should have their own support staff to provide assistance in these areas, the upstream developers can't support every distro kernel that ships. > A lot of the email is upstream kernel work - no doubt. But Many times, we > miss upstream kernel bugs because no one is running upstream code. We usually > hear about it when a distribution which stays close to upstream releases a > new update. In which case I would expect the distro support team to reproduce the problem and report it upstream and/or submit an upstream patch for review. This has been shown to work very well, and fits nicely within the "upstream first" motto adopted by some of the better Linux distributions. > The text where you sign up for this mail list does not limit the topc to > upstream work, Perhaps the term "limit" is a bit strong, but I think it would be good if the list welcome message indicates that the list is primarily for the development and support of the upstream Linux audit tools, distribution specific concerns should be sent to the distribution provider. > it allows for any discussion as long as it's audit related. I > do not think making a new mail list is in anyone's interest. Bugs will always > get misreported if there are 2 lists. I disagree, the upstream and Fedora SELinux mailing lists have been a good example of this working well. I also tend to think there is some value in having a vendor agnostic mailing list host, but that's more of a tie breaker in my mind, and not reason enough alone to force a switch. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v5 3/3] fanotify,audit: Allow audit to use the full permission event response
On 2023-01-09 19:06, Steve Grubb wrote:
> Hello,
>
> Sorry to take so long. Holidays and kernel build problems. However, I have
> built a kernel with these patches. I only have 2 comments. When I use an
> application that expected the old API, meaning it simply does:
>
> response.fd = metadata->fd;
> response.response = reply;
> close(metadata->fd);
> write(fd, , sizeof(struct fanotify_response));
>
> I get access denials. Every time. If the program is using the new API and
> sets FAN_INFO, then it works as expected. I'll do some more testing but I
> think there is something wrong in the compatibility path.
I'll have a closer look, because this wasn't the intended behaviour.
> On Monday, December 12, 2022 9:06:11 AM EST Richard Guy Briggs wrote:
> > This patch passes the full response so that the audit function can use all
> > of it. The audit function was updated to log the additional information in
> > the AUDIT_FANOTIFY record.
>
> What I'm seeing is:
>
> type=FANOTIFY msg=audit(01/09/2023 18:43:16.306:366) : resp=deny fan_type=1
> fan_info=3133 subj_trust=0 obj_trust=0
>
> Where fan_info was supposed to be 13 decimal. More below...
Well, it *is* 13 decimal, expressed as a hex-encoded string as was
requested for future-proofing, albeit longer than necessary...
> > Currently the only type of fanotify info that is defined is an audit
> > rule number, but convert it to hex encoding to future-proof the field.
> > Hex encoding suggested by Paul Moore .
> >
> > Sample records:
> > type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1
> > fan_info=3137 subj_trust=3 obj_trust=5 type=FANOTIFY
> > msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F subj_trust=2
> > obj_trust=2
> >
> > Suggested-by: Steve Grubb
> > Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2
> > Signed-off-by: Richard Guy Briggs
> > ---
> > fs/notify/fanotify/fanotify.c | 3 ++-
> > include/linux/audit.h | 9 +
> > kernel/auditsc.c | 25 ++---
> > 3 files changed, 29 insertions(+), 8 deletions(-)
> >
> > diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> > index 24ec1d66d5a8..29bdd99b29fa 100644
> > --- a/fs/notify/fanotify/fanotify.c
> > +++ b/fs/notify/fanotify/fanotify.c
> > @@ -273,7 +273,8 @@ static int fanotify_get_response(struct fsnotify_group
> > *group,
> >
> > /* Check if the response should be audited */
> > if (event->response & FAN_AUDIT)
> > - audit_fanotify(event->response & ~FAN_AUDIT);
> > + audit_fanotify(event->response & ~FAN_AUDIT,
> > + >audit_rule);
> >
> > pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__,
> > group, event, ret);
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index d6b7d0c7ce43..31086a72e32a 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #define AUDIT_INO_UNSET ((unsigned long)-1)
> > #define AUDIT_DEV_UNSET ((dev_t)-1)
> > @@ -416,7 +417,7 @@ extern void __audit_log_capset(const struct cred *new,
> > const struct cred *old); extern void __audit_mmap_fd(int fd, int flags);
> > extern void __audit_openat2_how(struct open_how *how);
> > extern void __audit_log_kern_module(char *name);
> > -extern void __audit_fanotify(u32 response);
> > +extern void __audit_fanotify(u32 response, struct
> > fanotify_response_info_audit_rule *friar); extern void
> > __audit_tk_injoffset(struct timespec64 offset);
> > extern void __audit_ntp_log(const struct audit_ntp_data *ad);
> > extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int
> > nentries, @@ -523,10 +524,10 @@ static inline void
> > audit_log_kern_module(char *name) __audit_log_kern_module(name);
> > }
> >
> > -static inline void audit_fanotify(u32 response)
> > +static inline void audit_fanotify(u32 response, struct
> > fanotify_response_info_audit_rule *friar) {
> > if (!audit_dummy_context())
> > - __audit_fanotify(response);
> > + __audit_fanotify(response, friar);
> > }
> >
> > static inline void audit_tk_injoffset(struct timespec64 offset)
> > @@ -679,7 +680,7 @@ static inline void audit_log_kern_module(char *name)
> > {
> > }
> >
> > -static inline void audit_fanotify(u32 response)
> > +static inline void audit_fanotify(u32 response, struct
> > fanotify_response_info_audit_rule *friar) { }
> >
> > static inline void audit_tk_injoffset(struct timespec64 offset)
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index d1fb821de104..8d523066d81f 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -64,6 +64,7 @@
> > #include
> > #include
> > #include // struct open_how
> > +#include
> >
> > #include "audit.h"
> >
> > @@ -2877,10 +2878,28 @@ void __audit_log_kern_module(char *name)
Re: [PATCH v5 3/3] fanotify, audit: Allow audit to use the full permission event response
Hello,
Sorry to take so long. Holidays and kernel build problems. However, I have
built a kernel with these patches. I only have 2 comments. When I use an
application that expected the old API, meaning it simply does:
response.fd = metadata->fd;
response.response = reply;
close(metadata->fd);
write(fd, , sizeof(struct fanotify_response));
I get access denials. Every time. If the program is using the new API and
sets FAN_INFO, then it works as expected. I'll do some more testing but I
think there is something wrong in the compatibility path.
On Monday, December 12, 2022 9:06:11 AM EST Richard Guy Briggs wrote:
> This patch passes the full response so that the audit function can use all
> of it. The audit function was updated to log the additional information in
> the AUDIT_FANOTIFY record.
What I'm seeing is:
type=FANOTIFY msg=audit(01/09/2023 18:43:16.306:366) : resp=deny fan_type=1
fan_info=3133 subj_trust=0 obj_trust=0
Where fan_info was supposed to be 13 decimal. More below...
> Currently the only type of fanotify info that is defined is an audit
> rule number, but convert it to hex encoding to future-proof the field.
> Hex encoding suggested by Paul Moore .
>
> Sample records:
> type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1
> fan_info=3137 subj_trust=3 obj_trust=5 type=FANOTIFY
> msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F subj_trust=2
> obj_trust=2
>
> Suggested-by: Steve Grubb
> Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2
> Signed-off-by: Richard Guy Briggs
> ---
> fs/notify/fanotify/fanotify.c | 3 ++-
> include/linux/audit.h | 9 +
> kernel/auditsc.c | 25 ++---
> 3 files changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 24ec1d66d5a8..29bdd99b29fa 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -273,7 +273,8 @@ static int fanotify_get_response(struct fsnotify_group
> *group,
>
> /* Check if the response should be audited */
> if (event->response & FAN_AUDIT)
> - audit_fanotify(event->response & ~FAN_AUDIT);
> + audit_fanotify(event->response & ~FAN_AUDIT,
> +>audit_rule);
>
> pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__,
>group, event, ret);
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index d6b7d0c7ce43..31086a72e32a 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #define AUDIT_INO_UNSET ((unsigned long)-1)
> #define AUDIT_DEV_UNSET ((dev_t)-1)
> @@ -416,7 +417,7 @@ extern void __audit_log_capset(const struct cred *new,
> const struct cred *old); extern void __audit_mmap_fd(int fd, int flags);
> extern void __audit_openat2_how(struct open_how *how);
> extern void __audit_log_kern_module(char *name);
> -extern void __audit_fanotify(u32 response);
> +extern void __audit_fanotify(u32 response, struct
> fanotify_response_info_audit_rule *friar); extern void
> __audit_tk_injoffset(struct timespec64 offset);
> extern void __audit_ntp_log(const struct audit_ntp_data *ad);
> extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int
> nentries, @@ -523,10 +524,10 @@ static inline void
> audit_log_kern_module(char *name) __audit_log_kern_module(name);
> }
>
> -static inline void audit_fanotify(u32 response)
> +static inline void audit_fanotify(u32 response, struct
> fanotify_response_info_audit_rule *friar) {
> if (!audit_dummy_context())
> - __audit_fanotify(response);
> + __audit_fanotify(response, friar);
> }
>
> static inline void audit_tk_injoffset(struct timespec64 offset)
> @@ -679,7 +680,7 @@ static inline void audit_log_kern_module(char *name)
> {
> }
>
> -static inline void audit_fanotify(u32 response)
> +static inline void audit_fanotify(u32 response, struct
> fanotify_response_info_audit_rule *friar) { }
>
> static inline void audit_tk_injoffset(struct timespec64 offset)
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index d1fb821de104..8d523066d81f 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -64,6 +64,7 @@
> #include
> #include
> #include // struct open_how
> +#include
>
> #include "audit.h"
>
> @@ -2877,10 +2878,28 @@ void __audit_log_kern_module(char *name)
> context->type = AUDIT_KERN_MODULE;
> }
>
> -void __audit_fanotify(u32 response)
> +void __audit_fanotify(u32 response, struct
> fanotify_response_info_audit_rule *friar) {
> - audit_log(audit_context(), GFP_KERNEL,
> - AUDIT_FANOTIFY, "resp=%u", response);
> + struct audit_context *ctx = audit_context();
> + struct audit_buffer *ab;
> + char numbuf[12];
> +
> + if (friar->hdr.type == FAN_RESPONSE_INFO_NONE)
Re: [PATCH v3 1/2] bpf: restore the ebpf program ID for BPF_AUDIT_UNLOAD and PERF_BPF_EVENT_PROG_UNLOAD
On 01/09, Paul Moore wrote:
On Fri, Jan 6, 2023 at 2:45 PM Stanislav Fomichev wrote:
> On Fri, Jan 6, 2023 at 7:44 AM Paul Moore wrote:
> >
> > When changing the ebpf program put() routines to support being called
> > from within IRQ context the program ID was reset to zero prior to
> > calling the perf event and audit UNLOAD record generators, which
> > resulted in problems as the ebpf program ID was bogus (always zero).
> > This patch addresses this problem by removing an unnecessary call to
> > bpf_prog_free_id() in __bpf_prog_offload_destroy() and adjusting
> > __bpf_prog_put() to only call bpf_prog_free_id() after audit and perf
> > have finished their bpf program unload tasks in
> > bpf_prog_put_deferred(). For the record, no one can determine, or
> > remember, why it was necessary to free the program ID, and remove it
> > from the IDR, prior to executing bpf_prog_put_deferred();
> > regardless, both Stanislav and Alexei agree that the approach in this
> > patch should be safe.
> >
> > It is worth noting that when moving the bpf_prog_free_id() call, the
> > do_idr_lock parameter was forced to true as the ebpf devs determined
> > this was the correct as the do_idr_lock should always be true. The
> > do_idr_lock parameter will be removed in a follow-up patch, but it
> > was kept here to keep the patch small in an effort to ease any stable
> > backports.
> >
> > I also modified the bpf_audit_prog() logic used to associate the
> > AUDIT_BPF record with other associated records, e.g. @ctx != NULL.
> > Instead of keying off the operation, it now keys off the execution
> > context, e.g. '!in_irg && !irqs_disabled()', which is much more
> > appropriate and should help better connect the UNLOAD operations with
> > the associated audit state (other audit records).
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: d809e134be7a ("bpf: Prepare bpf_prog_put() to be called from
irq context.")
> > Reported-by: Burn Alting
> > Reported-by: Jiri Olsa
> > Suggested-by: Stanislav Fomichev
> > Suggested-by: Alexei Starovoitov
> > Signed-off-by: Paul Moore
>
> Acked-by: Stanislav Fomichev
>
> Thank you! There might be a chance it breaks test_offload.py (I don't
> remember whether it checks this prog-is-removed-from-id part or not),
> but I don't think it's fair to ask to address it :-)
> Since it doesn't trigger in CI, I'll take another look next week when
> doing a respin of my 'xdp-hints' series.
No problem, I'm glad we found a solution that works for everyone; and
thank you for chasing down any test changes that may be necessary.
I'd like to get this patch into Linus' tree sooner rather than later
as it fixes a kinda ugly problem, would you be okay if this went in
via the bpf tree? With the appropriate ACKs I could send it to Linus
via the audit tree, but I think it would be much better to send it via
the bpf/netdev tree.
Don't see any reason that this should go via bpf-next, so assuming
going via bpf three should be fine.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v3 2/2] bpf: remove the do_idr_lock parameter from bpf_prog_free_id()
On 01/09, Paul Moore wrote: On Fri, Jan 6, 2023 at 2:45 PM Stanislav Fomichev wrote: > > On Fri, Jan 6, 2023 at 7:44 AM Paul Moore wrote: > > > > It was determined that the do_idr_lock parameter to > > bpf_prog_free_id() was not necessary as it should always be true. > > > > Suggested-by: Stanislav Fomichev > > nit: I believe it's been suggested several times by different people As much as I would like to follow all of the kernel relevant mailing lists, I'm short about 30hrs in a day to do that, and you were the first one I saw suggesting that change :) Sure, sure, I'm just stating it for the other people on the CC. So maybe we can drop this line when applying. > Acked-by: Stanislav Fomichev -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v3 2/2] bpf: remove the do_idr_lock parameter from bpf_prog_free_id()
On Mon, Jan 9, 2023 at 12:58 PM wrote: > On 01/09, Paul Moore wrote: > > On Fri, Jan 6, 2023 at 2:45 PM Stanislav Fomichev wrote: > > > > > > On Fri, Jan 6, 2023 at 7:44 AM Paul Moore wrote: > > > > > > > > It was determined that the do_idr_lock parameter to > > > > bpf_prog_free_id() was not necessary as it should always be true. > > > > > > > > Suggested-by: Stanislav Fomichev > > > > > > nit: I believe it's been suggested several times by different people > > > As much as I would like to follow all of the kernel relevant mailing > > lists, I'm short about 30hrs in a day to do that, and you were the > > first one I saw suggesting that change :) > > Sure, sure, I'm just stating it for the other people on the CC. So maybe > we can drop this line when applying. That's fine with me. To be honest, you folks can do whatever tweaks you want to these patches and that's okay with me; or even just dump them and rewrite them as you see fit, if that's easier. I'm only concerned with getting the regression fixed, who fixes it isn't something I'm worried about. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v3 2/2] bpf: remove the do_idr_lock parameter from bpf_prog_free_id()
On Fri, Jan 6, 2023 at 2:45 PM Stanislav Fomichev wrote: > > On Fri, Jan 6, 2023 at 7:44 AM Paul Moore wrote: > > > > It was determined that the do_idr_lock parameter to > > bpf_prog_free_id() was not necessary as it should always be true. > > > > Suggested-by: Stanislav Fomichev > > nit: I believe it's been suggested several times by different people As much as I would like to follow all of the kernel relevant mailing lists, I'm short about 30hrs in a day to do that, and you were the first one I saw suggesting that change :) > Acked-by: Stanislav Fomichev -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH v3 1/2] bpf: restore the ebpf program ID for BPF_AUDIT_UNLOAD and PERF_BPF_EVENT_PROG_UNLOAD
On Fri, Jan 6, 2023 at 2:45 PM Stanislav Fomichev wrote:
> On Fri, Jan 6, 2023 at 7:44 AM Paul Moore wrote:
> >
> > When changing the ebpf program put() routines to support being called
> > from within IRQ context the program ID was reset to zero prior to
> > calling the perf event and audit UNLOAD record generators, which
> > resulted in problems as the ebpf program ID was bogus (always zero).
> > This patch addresses this problem by removing an unnecessary call to
> > bpf_prog_free_id() in __bpf_prog_offload_destroy() and adjusting
> > __bpf_prog_put() to only call bpf_prog_free_id() after audit and perf
> > have finished their bpf program unload tasks in
> > bpf_prog_put_deferred(). For the record, no one can determine, or
> > remember, why it was necessary to free the program ID, and remove it
> > from the IDR, prior to executing bpf_prog_put_deferred();
> > regardless, both Stanislav and Alexei agree that the approach in this
> > patch should be safe.
> >
> > It is worth noting that when moving the bpf_prog_free_id() call, the
> > do_idr_lock parameter was forced to true as the ebpf devs determined
> > this was the correct as the do_idr_lock should always be true. The
> > do_idr_lock parameter will be removed in a follow-up patch, but it
> > was kept here to keep the patch small in an effort to ease any stable
> > backports.
> >
> > I also modified the bpf_audit_prog() logic used to associate the
> > AUDIT_BPF record with other associated records, e.g. @ctx != NULL.
> > Instead of keying off the operation, it now keys off the execution
> > context, e.g. '!in_irg && !irqs_disabled()', which is much more
> > appropriate and should help better connect the UNLOAD operations with
> > the associated audit state (other audit records).
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: d809e134be7a ("bpf: Prepare bpf_prog_put() to be called from irq
> > context.")
> > Reported-by: Burn Alting
> > Reported-by: Jiri Olsa
> > Suggested-by: Stanislav Fomichev
> > Suggested-by: Alexei Starovoitov
> > Signed-off-by: Paul Moore
>
> Acked-by: Stanislav Fomichev
>
> Thank you! There might be a chance it breaks test_offload.py (I don't
> remember whether it checks this prog-is-removed-from-id part or not),
> but I don't think it's fair to ask to address it :-)
> Since it doesn't trigger in CI, I'll take another look next week when
> doing a respin of my 'xdp-hints' series.
No problem, I'm glad we found a solution that works for everyone; and
thank you for chasing down any test changes that may be necessary.
I'd like to get this patch into Linus' tree sooner rather than later
as it fixes a kinda ugly problem, would you be okay if this went in
via the bpf tree? With the appropriate ACKs I could send it to Linus
via the audit tree, but I think it would be much better to send it via
the bpf/netdev tree.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: A question on monitoring time or time management changes in the kernel and the adjtimex system call
Hello, On Monday, January 9, 2023 2:33:39 AM EST Burn Alting wrote: > Would it be correct to say that when one sees an adjtimex system call audit > event, a change has occurred ONLY if either a AUDIT_TIME_ADJNTPVAL > (algorithm change) or AUDIT_TIME_INJOFFSET (time change) record is present > in the event? I think if you see either, time has been changed. I haven't studied the syscall to see if there isn't a sneak path, but I think they can be relied on. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: New bug in Audit
On Friday, January 6, 2023 3:33:18 PM EST Paul Moore 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? > > Steve, I realize it's only been ~24hrs, but should I assume you are > okay with that (the upstream focused approach)? For the 18 years I've spent on this mail list, it has alway been open to any topic audit related. I've answered questions for many distributions. If I can reproduce the issue, then it's a bug worth looking at. If I can't reproduce it, I let them know. I've even answered questions for people writing their own audit implementation. A lot of the email is upstream kernel work - no doubt. But Many times, we miss upstream kernel bugs because no one is running upstream code. We usually hear about it when a distribution which stays close to upstream releases a new update. The text where you sign up for this mail list does not limit the topc to upstream work, it allows for any discussion as long as it's audit related. I do not think making a new mail list is in anyone's interest. Bugs will always get misreported if there are 2 lists. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
Re: A question on monitoring time or time management changes in the kernel and the adjtimex system call
On Mon, Jan 9, 2023 at 2:33 AM Burn Alting wrote: > > All, > > Would it be correct to say that when one sees an adjtimex system call audit > event, a change has occurred ONLY if either a AUDIT_TIME_ADJNTPVAL (algorithm > change) or AUDIT_TIME_INJOFFSET (time change) record is present in the event? Looking at audit_log_time() and audit_tk_injoffset() it appears that an AUDIT_TIME_INJOFFSET record would indicate a time shift given by the "sec"/"nsec" fields while an AUDIT_TIME_ADJNTPVAL *might* indicate a shift depending on what was adjusted, you probably want to check the adjtimex(2) manpage, specifically the struct timex definition for more information on the AUDIT_TIME_ADJNTPVAL "op" field and "new"/"old" values. * https://man7.org/linux/man-pages/man2/adjtimex.2.html Hopefully that helps a little bit. -- 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 Mon, Jan 9, 2023 at 9:21 PM Yann Sionneau wrote:
>
> Hi Jeff,
>
> On 1/7/23 07:25, Jeff Xie wrote:
> > Hi,
> >
> > On Wed, Jan 4, 2023 at 1:01 AM Yann Sionneau wrote:
> >> [snip]
> >>
> >> A kvx toolchain can be built using:
> >> # install dependencies: texinfo bison flex libgmp-dev libmpc-dev
> >> libmpfr-dev
> >> $ git clone https://github.com/kalray/build-scripts
> >> $ cd build-scripts
> >> $ source last.refs
> >> $ ./build-kvx-xgcc.sh output
> > I would like to build the kvx-xgcc to compile and test the linux
> > kernel, but it reported a compile error.
> > I wonder what version of gcc you are using.
> >
> > My build environment:
> > VERSION="20.04.2 LTS (Focal Fossa)"
> > gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
> >
> >
> > Compile error:
> > $ ./build-kvx-xgcc.sh output
> >
> > ../../binutils/libiberty/fibheap.c: In function ‘fibheap_replace_key_data’:
> > ../../binutils/libiberty/fibheap.c:38:24: error: ‘LONG_MIN’ undeclared
> > (first use in this function)
> > 38 | #define FIBHEAPKEY_MIN LONG_MIN
> >|^~~~
> > [snip]
>
> What SHA1 of https://github.com/kalray/build-scripts are you using?
I have executed the "source last.refs"
> We are building our toolchain on Ubuntu 18.04 / 20.04 and 22.04 without
> issues, I don't understand why it does not work for you, although indeed
> the error log you are having pops out on my search engine and seems to
> be some well known issue.
Yes, there are many answers on the web, but none of them solve this problem.
> If the build-script does not work for you, you can still use the
> pre-built toolchains generated by the GitHub automated actions:
> https://github.com/kalray/build-scripts/releases/tag/v4.11.1 ("latest"
> means 22.04)
Thanks, this is the final solution ;-)
>
> I hope it will work for you.
>
> Regards,
>
> --
>
> Yann
>
>
>
>
>
--
Thanks,
JeffXie
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
Re: New bug in Audit
On Mon, Jan 9, 2023 at 3:30 AM Ariel Silver wrote:
>
> Hey guys and thank you for the quick reply, Much appreciated!
>
> As Richard and Steve mentioned the commit:
> https://github.com/linux-audit/audit-kernel/commit/1b2263a807ca651f94517b1b22dc5f13e494984d
> Fixed this issue.
A quick note for anyone looking to backport, the actual commit in the
upstream Linux Kernel is d4fefa4801a1 ("audit: move audit_return_fixup
before the filters"). Looking at the commit ID posted above and the
note in the commit about the manual merge, it looks like the 1b22
commit had a munged subject line that was fixed in d4fe.
> Any timeframe to when we can get a new version of auditd with that fix?
> Or should I count on redhat to release an update to the kernel ?
>
> Any update will be good.
This is one of those reasons why you really need to contact RH
directly via their bugzilla and/or a support representative; those of
us who work on the upstream Linux Kernel do not have visibility into
RH's kernel release process. I maintain the Linux Kernel's audit
subsystem and I don't currently work for RH, and haven't for over four
years ;)
--
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
Hi, On Wed, Jan 4, 2023 at 1:01 AM 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 > > Kalray kv3-1 core which is the third of the kvx family is embedded in Kalray > Coolidge SoC currently used on K200 and K200-LP boards. > > The Coolidge SoC contains 5 clusters each of which is made of: > * 4MiB of on-chip memory (SMEM) > * 1 dedicated safety/security core (kv3-1 core). > * 16 PEs (Processing Elements) (kv3-1 cores). > * 16 Co-processors (one per PE) > * 2 Crypto accelerators > > The Coolidge SoC contains the following features: > * 5 Clusters > * 2 100G Ethernet controllers > * 8 PCIe GEN4 controllers (Root Complex and Endpoint capable) > * 2 USB 2.0 controllers > * 1 Octal SPI-NOR flash controller > * 1 eMMC controller > * 3 Quad SPI controllers > * 6 UART > * 5 I2C controllers (3 of which are SMBus capable) > * 4 CAN controllers > * 1 OTP memory > > A kvx toolchain can be built using: > # install dependencies: texinfo bison flex libgmp-dev libmpc-dev libmpfr-dev > $ git clone https://github.com/kalray/build-scripts > $ cd build-scripts > $ source last.refs > $ ./build-kvx-xgcc.sh output I would like to build the kvx-xgcc to compile and test the linux kernel, but it reported a compile error. I wonder what version of gcc you are using. My build environment: VERSION="20.04.2 LTS (Focal Fossa)" gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) Compile error: $ ./build-kvx-xgcc.sh output ../../binutils/libiberty/fibheap.c: In function ‘fibheap_replace_key_data’: ../../binutils/libiberty/fibheap.c:38:24: error: ‘LONG_MIN’ undeclared (first use in this function) 38 | #define FIBHEAPKEY_MIN LONG_MIN |^~~~ ../../binutils/libiberty/fibheap.c:220:30: note: in expansion of macro ‘FIBHEAPKEY_MIN’ 220 | if (okey == key && okey != FIBHEAPKEY_MIN) | ^~ ../../binutils/libiberty/fibheap.c:36:1: note: ‘LONG_MIN’ is defined in header ‘’; did you forget to ‘#include ’? 35 | #include "fibheap.h" +++ |+#include 36 | ../../binutils/libiberty/fibheap.c:38:24: note: each undeclared identifier is reported only once for each function it appears in 38 | #define FIBHEAPKEY_MIN LONG_MIN |^~~~ ../../binutils/libiberty/fibheap.c:220:30: note: in expansion of macro ‘FIBHEAPKEY_MIN’ 220 | if (okey == key && okey != FIBHEAPKEY_MIN) | ^~ ../../binutils/libiberty/fibheap.c: In function ‘fibheap_delete_node’: ../../binutils/libiberty/fibheap.c:38:24: error: ‘LONG_MIN’ undeclared (first use in this function) 38 | #define FIBHEAPKEY_MIN LONG_MIN |^~~~ ../../binutils/libiberty/fibheap.c:261:36: note: in expansion of macro ‘FIBHEAPKEY_MIN’ 261 | fibheap_replace_key (heap, node, FIBHEAPKEY_MIN); |^~ ../../binutils/libiberty/fibheap.c:38:24: note: ‘LONG_MIN’ is defined in header ‘’; did you forget to ‘#include ’? 38 | #define FIBHEAPKEY_MIN LONG_MIN |^~~~ ../../binutils/libiberty/fibheap.c:261:36: note: in expansion of macro ‘FIBHEAPKEY_MIN’ 261 | fibheap_replace_key (heap, node, FIBHEAPKEY_MIN); |^~ > The kvx toolchain will be installed in the "output" directory. > > A buildroot image (kernel+rootfs) and toolchain can be built using: > $ git clone -b coolidge-for-upstream https://github.com/kalray/buildroot > $ cd buildroot > $ make O=build_kvx kvx_defconfig > $ make O=build_kvx > > The vmlinux image can be found in buildroot/build_kvx/images/vmlinux. > > If you are just interested in building the Linux kernel with no rootfs you can > just do this with the kvx-elf- toolchain: > $ make ARCH=kvx O=build_kvx CROSS_COMPILE=kvx-elf- default_defconfig > $ make ARCH=kvx O=build_kvx CROSS_COMPILE=kvx-elf- -j$(($(nproc) + 1)) > > The vmlinux ELF can be run with qemu by doing: > # install dependencies: ninja pkg-config libglib-2.0-dev cmake libfdt-dev > libpixman-1-dev zlib1g-dev > $ git clone https://github.com/kalray/qemu-builder > $ cd qemu-builder > $ git submodule update --init > $ make -j$(($(nproc) + 1)) > $ ./qemu-system-kvx -m 1024 -nographic -kernel > > Yann Sionneau (25): > Documentation: kvx: Add basic documentation > kvx: Add ELF-related definitions > kvx: Add build infrastructure > kvx: Add
Re: New bug in Audit
Hey guys and thank you for the quick reply, Much appreciated! As Richard and Steve mentioned the commit: https://github.com/linux-audit/audit-kernel/commit/1b2263a807ca651f94517b1b22dc5f13e494984d Fixed this issue. Any timeframe to when we can get a new version of auditd with that fix? Or should I count on redhat to release an update to the kernel ? Any update will be good. Once again thanks a lot! בתאריך יום ו׳, 6 בינו׳ 2023 ב-22:33 מאת Paul Moore <p...@paul-moore.com >: > On Thu, Jan 5, 2023 at 2:32 PM Paul Moore wrote: > > 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? > > Steve, I realize it's only been ~24hrs, but should I assume you are > okay with that (the upstream focused approach)? > > -- > 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
Hi Jeff,
On 1/7/23 07:25, Jeff Xie wrote:
Hi,
On Wed, Jan 4, 2023 at 1:01 AM Yann Sionneau wrote:
[snip]
A kvx toolchain can be built using:
# install dependencies: texinfo bison flex libgmp-dev libmpc-dev libmpfr-dev
$ git clone https://github.com/kalray/build-scripts
$ cd build-scripts
$ source last.refs
$ ./build-kvx-xgcc.sh output
I would like to build the kvx-xgcc to compile and test the linux
kernel, but it reported a compile error.
I wonder what version of gcc you are using.
My build environment:
VERSION="20.04.2 LTS (Focal Fossa)"
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
Compile error:
$ ./build-kvx-xgcc.sh output
../../binutils/libiberty/fibheap.c: In function ‘fibheap_replace_key_data’:
../../binutils/libiberty/fibheap.c:38:24: error: ‘LONG_MIN’ undeclared
(first use in this function)
38 | #define FIBHEAPKEY_MIN LONG_MIN
|^~~~
[snip]
What SHA1 of https://github.com/kalray/build-scripts are you using?
We are building our toolchain on Ubuntu 18.04 / 20.04 and 22.04 without
issues, I don't understand why it does not work for you, although indeed
the error log you are having pops out on my search engine and seems to
be some well known issue.
If the build-script does not work for you, you can still use the
pre-built toolchains generated by the GitHub automated actions:
https://github.com/kalray/build-scripts/releases/tag/v4.11.1 ("latest"
means 22.04)
I hope it will work for you.
Regards,
--
Yann
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
