and
should not be brought up as a point in favor.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
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
On Wed, 2013-05-29 at 18:56 +0200, Andi Kleen wrote:
> On Wed, May 29, 2013 at 12:18:09PM -0400, Simo Sorce wrote:
> > On Wed, 2013-05-29 at 11:55 -0400, Waiman Long wrote:
> >
> > > My patch set consists of 2 different changes. The first one is to avoid
> >
this an intentional side effect?
Just as a user can add data into a shm segment ?
Is there any difference ?
> Sorry if these are obvious questions. feel free to point me to
> already-documented answers if they exist.
There isn't much documentation, but it is certainly good to sort out any
On Thu, 2013-08-01 at 14:55 -0400, Daniel Kahn Gillmor wrote:
> On 08/01/2013 02:29 PM, Simo Sorce wrote:
>
> > It's called 'abstraction' :-)
>
> Good, I like abstraction :)
>
> >> It seems like a non-privileged user could use this to store arbitrary
LOC_NOT_IN_QUOTA,
> > + ns->krb_cache_register);
> > + up_write(&ns->krb_cache_register_sem);
> > + if (!IS_ERR(krb)) {
> > + krb_ref = make_key_ref(krb, true);
> > + goto found;
> > + }
> > +
> &
;
> In the above scheme, it might be worth just making these the same as the user
> keyring - which means KEYCTL_SPEC_USER_KEYRING will automatically target it.
>
> Simo: I believe the problem you have with the user keyring is that it's not
> persistent beyond the life of the
to modify the gssproxy patches to use the new interfaces.
>
> > Also: it looks like 030d794bf498 "SUNRPC: Introduce
> > rpcauth_get_pseudoflavor()" is in Trond's linux-next, but not his
> > nfs-for-next. I'm not sure what that means--is it safe to rebase
On Mon, 2013-04-29 at 12:37 -0400, Chuck Lever wrote:
> On Apr 29, 2013, at 12:29 PM, Simo Sorce wrote:
>
> > On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote:
> >> On Apr 29, 2013, at 11:45 AM, "J. Bruce Fields"
> >> wrote:
> >>
> >&
o me.
> >
> > I've now pulled the rpcsec_gss changes into the nfs-for-next. The main
> > reason why they were not pulled in earlier was due to uncertainty what
> > to do about the increase in "AUTH_GSS upcall timed out." syslog
> > warnings.
>
> Trond's n
> >> Instead of gss_mech_get_by_OID(), I suspect you want
> >> rpcauth_get_pseudoflavor(), but I haven't looked at the gssproxy code.
> >
> > It's doing
> >
> > status = -EOPNOTSUPP;
> > gm = gss_mech_get_by_OID(&ud
ontainer ID means the process has
> the ability to indirectly control the audit trail.
The container Id can be used also for authorization purposes (by other
processes on the host), not just audit, I think this is why a separate
control has been proposed.
Simo.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
On Tue, 2017-10-17 at 07:59 -0700, Casey Schaufler wrote:
> On 10/17/2017 5:31 AM, Simo Sorce wrote:
> > On Mon, 2017-10-16 at 21:42 -0400, Steve Grubb wrote:
> > > On Monday, October 16, 2017 8:33:40 PM EDT Richard Guy Briggs
> > > wrote:
> > > > There is su
stem or you want to
correlate the system audit logs with other components dealing with
containers, now you need a place where you provide a mapping from your
audit u64 to the ID a container has in the rest of the system.
b) Now you need a mapping of some sort. The simplest way a container
orchestrator can go about this is to just use the UUID or Hash
representing their view of the container, truncate it to a u64 and use
that for Audit. This means there are some chances there will be a
collision and a duplicate u64 ID will be used by the orchestrator as
the container ID. What happen in that case ?
Simo.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
t) changes the integrity check algorithm from md5 to
crc32. This integrity check is used only to verify accidental
corruption of the hybernation data and is not intended as a
cryptographic integrity check.
Md5 is overkill in this case and also disabled in FIPS mode because it
is known to be broken fo
> return false;
> > }
> > #endif
> >
> > #ifdef CONFIG_X86_64
> > -#define RESTORE_MAGIC 0x23456789ABCDEF01UL
> > +#define RESTORE_MAGIC 0x23456789ABCDEF02UL
> > #else
> > -#define RESTORE_MAGIC 0x12345678UL
> > +#define RESTORE_MAGIC 0x12345679UL
> > #endif
> >
> > /**
> > @@ -160,6 +160,9 @@ int arch_hibernation_header_save(void *addr, unsigned
> > int max_size)
> > rdr->jump_address = (unsigned long)restore_registers;
> > rdr->jump_address_phys = __pa_symbol(restore_registers);
> >
> > + /* crc32 digest size is 4 but digest buffer size is 16 so zero it
> > all */
> > + memset(rdr->e820_digest, 0, CRC32_DIGEST_SIZE);
> > +
> > /*
> > * The restore code fixes up CR3 and CR4 in the following sequence:
> > *
> > --
> > 2.18.1
> >
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
e would be called
> "accidental" changes, but sure, it could be changes that are "intentionally"
> made provided that the other side can be trusted to not try to avoid
> detection...), then a non-cryptographic checksum would be sufficient.
Wouldn't you also need a sign
>
> > PS, currently it looks like FIPS mode is broken in the mainline:
> > https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg49414.html
FYI, SHA-1 is not a good choice, it is only permitted in HMAC
constructions and only for specified uses. If you need to change
algorithm you should go straight to SHA-2 or SHA-3 based hashes.
HTH,
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
> On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
> > On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> > > On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui wrote:
> > > > Hi,
> > > > MD
estore the entire system state from a
> > > swap file, and carry on as if the cold boot was just a [firmware
> > > assisted] suspend/resume.
> > >
> > > So forging collisions is *not* a concern here. Let's avoid accidental
> > > or malicious, as those adjectives seem to confuse some people. The
> > > bottom line is that there is no need to protect against deliberate
> > > attempts to hide the fact that the memory map has changed, and so
> > > there is no reason to use cryptographic hashes here.
> > >
> > How about :
> >
> > The check is intended to differentiate between a resume (which expects
> > an identical e820 map to the one saved in suspend), and a cold boot
> > (which need not have an identical e820 map to that saved in suspend if
> > any was done at all). It is not necessary here to protect against
> > deliberate attempts to hide the fact that the memory map has changed, so
> > crc32 is sufficient for detection.
> >
>
> Almost. Hibernation always occurs after a cold boot, but usually, the
> E820 memory map happens to be the same.
>
> How about
>
> """
> The check is intended to detect whether the E820 memory map provided
> by the firmware after cold boot unexpectedly differs from the one that
> was in use when the hibernation image was created. In this case, the
> hibernation image cannot be restored, as it may cover memory regions
> that are no longer available to the OS.
>
> A non-cryptographic hash such as CRC-32 is sufficient to detect such
> inadvertent deviations.
> """
hash -> checksum
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
On Thu, 2021-04-01 at 18:31 +0200, Rafael J. Wysocki wrote:
> On Thu, Apr 1, 2021 at 6:22 PM Simo Sorce wrote:
> > On Thu, 2021-04-01 at 18:02 +0200, Rafael J. Wysocki wrote:
> > > On Thu, Apr 1, 2021 at 3:54 PM Ard Biesheuvel wrote:
> > > > On Thu, 1 Apr 20
On Thu, 2021-04-01 at 18:02 +0200, Rafael J. Wysocki wrote:
> On Thu, Apr 1, 2021 at 3:54 PM Ard Biesheuvel wrote:
> > On Thu, 1 Apr 2021 at 15:38, Rafael J. Wysocki wrote:
> > > On Thu, Apr 1, 2021 at 10:47 AM Ard Biesheuvel wrote:
> > > > On Tue, 30 Mar 20
On Wed, 2014-03-12 at 13:56 -0700, Andy Lutomirski wrote:
> On 03/12/2014 01:46 PM, Vivek Goyal wrote:
> > Hi,
> >
> > This is V2 of patches. Fixed the function format issue and also I was using
> > CONFIG_CGROUP instead of CONFIG_CGROUPS. That led to crash at boot. Fixed
> > that.
> >
> > Some
On Wed, 2014-03-12 at 14:12 -0700, Andy Lutomirski wrote:
> On Wed, Mar 12, 2014 at 2:00 PM, Andy Lutomirski wrote:
> > On 03/12/2014 01:46 PM, Vivek Goyal wrote:
> >> Implement SO_PEERCGROUP along the lines of SO_PEERCRED. This returns the
> >> cgroup of first mounted hierarchy of the task. For t
On Wed, 2014-03-12 at 14:19 -0700, Andy Lutomirski wrote:
> On Wed, Mar 12, 2014 at 2:16 PM, Simo Sorce wrote:
> > On Wed, 2014-03-12 at 14:12 -0700, Andy Lutomirski wrote:
> >> On Wed, Mar 12, 2014 at 2:00 PM, Andy Lutomirski
> >> wrote:
> >> > On
On Wed, 2014-03-12 at 18:21 -0700, Andy Lutomirski wrote:
> On Wed, Mar 12, 2014 at 6:17 PM, Simo Sorce wrote:
> > On Wed, 2014-03-12 at 14:19 -0700, Andy Lutomirski wrote:
> >> On Wed, Mar 12, 2014 at 2:16 PM, Simo Sorce wrote:
> >>
> >> >
> >> &
On Thu, 2014-03-13 at 10:14 -0400, Vivek Goyal wrote:
> On Wed, Mar 12, 2014 at 02:12:33PM -0700, Andy Lutomirski wrote:
> > On Wed, Mar 12, 2014 at 2:00 PM, Andy Lutomirski
> > wrote:
> > > On 03/12/2014 01:46 PM, Vivek Goyal wrote:
> > >> Implement SO_PEERCGROUP along the lines of SO_PEERCRED.
On Thu, 2014-03-13 at 11:00 -0400, Vivek Goyal wrote:
> On Thu, Mar 13, 2014 at 10:55:34AM -0400, Simo Sorce wrote:
>
> [..]
> > > > This might not be quite as awful as I thought. At least you're
> > > > looking up the cgroup at connection time instead
On Wed, 2014-03-12 at 19:12 -0700, Andy Lutomirski wrote:
> On Wed, Mar 12, 2014 at 6:43 PM, Simo Sorce wrote:
> > On Wed, 2014-03-12 at 18:21 -0700, Andy Lutomirski wrote:
> >> On Wed, Mar 12, 2014 at 6:17 PM, Simo Sorce wrote:
> >> > On Wed, 2014-03-12 at 14:1
On Thu, 2014-03-13 at 10:25 -0700, Andy Lutomirski wrote:
> On Thu, Mar 13, 2014 at 9:33 AM, Simo Sorce wrote:
> > On Thu, 2014-03-13 at 11:00 -0400, Vivek Goyal wrote:
> >> On Thu, Mar 13, 2014 at 10:55:34AM -0400, Simo Sorce wrote:
> >>
> >> [..]
> >>
On Thu, 2014-03-13 at 10:55 -0700, Andy Lutomirski wrote:
> On Thu, Mar 13, 2014 at 10:51 AM, Simo Sorce wrote:
> > On Wed, 2014-03-12 at 19:12 -0700, Andy Lutomirski wrote:
> >> On Wed, Mar 12, 2014 at 6:43 PM, Simo Sorce wrote:
> >> > On Wed, 2014-03-12 at 18:2
On Thu, 2014-03-13 at 10:55 -0700, Andy Lutomirski wrote:
>
> So give each container its own unix socket. Problem solved, no?
Not really practical if you have hundreds of containers.
Simo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ma
On Thu, 2014-04-24 at 17:11 -0400, David Miller wrote:
> From: Vivek Goyal
> Date: Thu, 24 Apr 2014 17:04:29 -0400
>
> > Does it really matter.
>
> Good question, if it doesn't matter, you might as well log garbage.
>
> There are a lot of logical holes in this discussion.
>
> Real UIDs are alw
On Tue, 2014-04-15 at 14:53 -0700, Andy Lutomirski wrote:
> On Tue, Apr 15, 2014 at 2:15 PM, Vivek Goyal wrote:
> > This patch implements socket option SO_PASSCGROUP along the lines of
> > SO_PASSCRED.
> >
> > If SO_PASSCGROUP is set, then recvmsg() will get a control message
> > SCM_CGROUP which
On Wed, 2014-04-16 at 07:37 -0700, Andy Lutomirski wrote:
> On Wed, Apr 16, 2014 at 5:57 AM, David Miller wrote:
> >
> > Please, just stop.
>
> No.
>
> This thread is proposing an ABI. This means that, if the ABI ends up
> in Linus's kernel, then it has to be supported forever. Now is the
> ti
On Wed, 2014-04-16 at 12:21 -0400, Tejun Heo wrote:
> Hello,
>
> On Wed, Apr 16, 2014 at 12:13:57PM -0400, Simo Sorce wrote:
> > The only one that *may* be reasonable is the "secret" cgroup name one,
> > however nobody seem to come up with a reason why it is legitim
On Wed, 2014-04-16 at 09:31 -0700, Andy Lutomirski wrote:
> On Wed, Apr 16, 2014 at 9:13 AM, Simo Sorce wrote:
> > On Wed, 2014-04-16 at 07:37 -0700, Andy Lutomirski wrote:
> >> On Wed, Apr 16, 2014 at 5:57 AM, David Miller wrote:
> >> >
> >> > Pleas
On Wed, 2014-04-16 at 10:29 -0700, Andy Lutomirski wrote:
> Then please remove SO_PASSCGROUP.
Can you stop demanding changes while demonstrating you haven't well
understood the needs, let alone the consequences ?
Take a day or 2, put your thoughts together and come back with a clear
description o
On Thu, 2014-04-17 at 08:41 -0700, Daniel J Walsh wrote:
> On 04/16/2014 11:59 AM, Vivek Goyal wrote:
> > On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:
> >> On Wed, Apr 16, 2014 at 11:06 AM, Vivek Goyal wrote:
> >>> On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote
On Thu, 2014-04-17 at 09:11 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 9:04 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 08:41 -0700, Daniel J Walsh wrote:
> >> On 04/16/2014 11:59 AM, Vivek Goyal wrote:
> >> > On Wed, Apr 16, 2014 at 11:13:31A
On Thu, 2014-04-17 at 09:37 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 9:24 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 09:11 -0700, Andy Lutomirski wrote:
> >>
> >> No. The logging daemon thinks it wants to know who the writer is, but
> >&
On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:12 AM, Vivek Goyal wrote:
> > On Thu, Apr 17, 2014 at 09:55:08AM -0700, Andy Lutomirski wrote:
> >> On Thu, Apr 17, 2014 at 9:48 AM, Simo Sorce wrote:
> >> > On Thu, 2014-04-17 a
On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> >>
> >> Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2)
> >
On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:12 AM, Vivek Goyal wrote:
> > On Thu, Apr 17, 2014 at 09:55:08AM -0700, Andy Lutomirski wrote:
> >> On Thu, Apr 17, 2014 at 9:48 AM, Simo Sorce wrote:
> >> > On Thu, 2014-04-17 a
On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> >>
> >> Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2)
> >
On Thu, 2014-04-17 at 11:04 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:52 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> >> On Thu, Apr 17, 2014 at 10:12 AM, Vivek Goyal wrote:
> >> > On Thu, Apr 17, 2014 at 09:
On Thu, 2014-04-17 at 12:06 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 11:57 AM, Vivek Goyal wrote:
> > On Thu, Apr 17, 2014 at 02:50:23PM -0400, Vivek Goyal wrote:
> >> On Thu, Apr 17, 2014 at 02:23:33PM -0400, Simo Sorce wrote:
> >> > On Thu, 2
On Thu, 2014-04-17 at 14:50 -0400, Vivek Goyal wrote:
> On Thu, Apr 17, 2014 at 02:23:33PM -0400, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
> > > On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
> > > > On Thu, 2014-04-17 a
http://vger.kernel.org/majordomo-info.html
I touched this code relatively recently, and this check looks correct.
Feel free to add Reviewed-by: Simo Sorce
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
On Fri, 2018-02-02 at 16:24 -0500, Paul Moore wrote:
> On Wed, Jan 10, 2018 at 2:00 AM, Richard Guy Briggs wrote:
> > On 2018-01-09 11:18, Simo Sorce wrote:
> > > On Tue, 2018-01-09 at 07:16 -0500, Richard Guy Briggs wrote:
> > > > Containers are a userspace concept
On Fri, 2018-02-02 at 18:24 -0500, Paul Moore wrote:
> On Fri, Feb 2, 2018 at 5:19 PM, Simo Sorce wrote:
> > On Fri, 2018-02-02 at 16:24 -0500, Paul Moore wrote:
> > > On Wed, Jan 10, 2018 at 2:00 AM, Richard Guy Briggs
> > > wrote:
> > > > On 2018-01-0
t; [120408.597734] ? nfsd_destroy+0x60/0x60 [nfsd]
> [120408.598626] ? kthread_park+0x90/0x90
> [120408.599448] ret_from_fork+0x22/0x30
>
> Fixes: 1d658336b05f "SUNRPC: Add RPC based upcall mechanism for
> RPCGSS auth"
> Cc: Simo Sorce
> Reported-by: Olga Kornievskaia
51 matches
Mail list logo
