Re: [OE-core] pseudo: host user contamination

On Sat, 24 Mar 2018, Andre McCurdy wrote: On Sat, Mar 24, 2018 at 5:09 PM, Victor Kamensky wrote: On Sat, 24 Mar 2018, Burton, Ross wrote: On 24 March 2018 at 20:12, Victor Kamensky wrote: Here is another crazy idea how to deal with it, just

Re: [OE-core] pseudo: host user contamination

On Sat, Mar 24, 2018 at 5:09 PM, Victor Kamensky wrote: > On Sat, 24 Mar 2018, Burton, Ross wrote: >> On 24 March 2018 at 20:12, Victor Kamensky wrote: >>> >>> Here is another crazy idea how to deal with it, just >>> brainstorming what options are on the

Re: [OE-core] pseudo: host user contamination

On Sat, 24 Mar 2018, Burton, Ross wrote: On 24 March 2018 at 20:12, Victor Kamensky wrote: Here is another crazy idea how to deal with it, just brainstorming what options are on the table: disable renameat2 with help of seccomp and force coreutils to use other calls.

Re: [OE-core] pseudo: host user contamination

On 24 March 2018 at 20:12, Victor Kamensky wrote: > Here is another crazy idea how to deal with it, just > brainstorming what options are on the table: disable > renameat2 with help of seccomp and force coreutils to > use other calls. Something along the lines that were >

Re: [OE-core] pseudo: host user contamination

On Sat, 24 Mar 2018 15:22:47 -0500 Joshua Watt wrote: > I don't think that is true. libc's syscall() must conform to the *C* > ABI for the system... if the kernel does things that aren't in line > with the C ABI (like return things in registers that aren't expected, > fail

Re: [OE-core] pseudo: host user contamination

On Sat, Mar 24, 2018 at 12:50 PM, Seebs wrote: > > pseudo's call sequence: > various_setup() > real_syscall() // sets a3 > other system calls // also set a3 > return You don't need to know that the kernel returns a result in any particular

Re: [OE-core] pseudo: host user contamination

On Sat, Mar 24, 2018 at 2:50 PM, Seebs wrote: > On Sat, 24 Mar 2018 12:42:45 -0700 > Andre McCurdy wrote: > >> Right. The musl example is to show how it's possible to transparently >> intercept and pass on any call to the syscall() ABI without >>

Re: [OE-core] pseudo: host user contamination

Here is another crazy idea how to deal with it, just brainstorming what options are on the table: disable renameat2 with help of seccomp and force coreutils to use other calls. Something along the lines that were suggested with intercept of syscall function call, but let kernel to do interception

Re: [OE-core] pseudo: host user contamination

On Sat, 24 Mar 2018 12:42:45 -0700 Andre McCurdy wrote: > Right. The musl example is to show how it's possible to transparently > intercept and pass on any call to the syscall() ABI without > interpreting anything. Yes, if you don't need to interpret things, and aren't

Re: [OE-core] pseudo: host user contamination

On Sat, Mar 24, 2018 at 12:24 PM, Seebs wrote: > > I didn't see a qualifier about it being only on a 32-bit architecture, > it just says "EABI". > > But in general, this is the reason that musl's ability to work doesn't > buy us guarantees; musl doesn't have to *interpret* the

Re: [OE-core] pseudo: host user contamination

On Sat, 24 Mar 2018 11:59:27 -0700 Andre McCurdy wrote: > The EABI example applies to 64bit values on 32bit architectures. Since > pointers are 32bit values on 32bit architectures the example doesn't > apply to renameat2 (which only passes int's and pointers - nothing >

[OE-core] X11 proto changes

Hello, It appears Xorg is deprecating most of it's proto header repos for a new all-in-1 repo xorgproto. This will most likely affect down stream layers. The question I have, is do we want this big churn to happen for Sumo or wait for 2.6 ? - armin These are now included in xorgproto, the

Re: [OE-core] pseudo: host user contamination

On Sat, Mar 24, 2018 at 11:22 AM, Seebs wrote: > > Every other function we wrap *has* a meaningful prototype, with > arguments in a knowable order. But look at the EABI example; if we want > to actually *process* renameat2(), it's not enough to pass arguments on > blindly, we

Re: [OE-core] pseudo: host user contamination

On Sat, 24 Mar 2018 11:12:20 -0700 Andre McCurdy wrote: > If you can successfully intercept the libc syscall() API and return > ENOTSUPP for the one specific case of renameat2 but pass on all other > callers transparently then haven't you've already solved the bulk of > the

Re: [OE-core] pseudo: host user contamination

On Sat, Mar 24, 2018 at 10:23 AM, Seebs wrote: > On Sat, 24 Mar 2018 17:10:47 + > "Burton, Ross" wrote: >> On 24 March 2018 at 12:36, Richard Purdie >> wrote: >> > I think, at least in principle, pseudo could wrap

[OE-core] [PATCH] python3-pycairo: update to version 1.16.3

Update to the latest stable release Changes in this update: Add the .pc file to the list of -dev files Move py3cairo header to -dev package Added a comment for why the .pc and .h file are re-installed Verified native build and dependency builds (python3-pygobject and bootchart2) Tested in

Re: [OE-core] pseudo: host user contamination

On Sat, 24 Mar 2018 17:10:47 + "Burton, Ross" wrote: > On 24 March 2018 at 12:36, Richard Purdie > wrote: > > I think, at least in principle, pseudo could wrap that and intercept > > this particular syscall, check syscall_number

Re: [OE-core] pseudo: host user contamination

On 24 March 2018 at 12:36, Richard Purdie wrote: > I think, at least in principle, pseudo could wrap that and intercept > this particular syscall, check syscall_number (the numbering having its > own set of issues) and then only handle the specific problem case

[OE-core] Bind update

Hello, While working on updating the current bind to the next patch level, I noticed our current version 9.10.6 will EOL June 2018. I know we are under feature freeze for the Sumo release. Could we make an exception and allow an update of bind to the ESV version 9.11.3 ?, it EOL's Dec 2021.

Re: [OE-core] pseudo: host user contamination

On Sat, 24 Mar 2018 12:36:28 + Richard Purdie wrote: > I think, at least in principle, pseudo could wrap that and intercept > this particular syscall, check syscall_number (the numbering having > its own set of issues) and then only handle the specific

[OE-core] [PATCH] python*-setuptools: update to 39.0.1

Update the python{3}-setuptools to the latest stable version Tested on the qemu with core-image-minimal Signed-off-by: Derek Straka --- meta/recipes-devtools/python/python-setuptools.inc| 4 ++-- .../{python-setuptools_39.0.0.bb =>

[OE-core] [PATCH] python3-pip: update to version 9.0.3

Update to the latest stable version Signed-off-by: Derek Straka --- .../python/{python3-pip_9.0.2.bb => python3-pip_9.0.3.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-devtools/python/{python3-pip_9.0.2.bb =>

Re: [OE-core] pseudo: host user contamination

On Fri, 2018-03-23 at 18:56 -0500, Seebs wrote: > On Fri, 23 Mar 2018 23:47:30 + > Richard Purdie wrote: > > > I... am really unsure whether it's possible to catch that, > > > because > > > I really, really, don't want to try to intercept raw syscall() > >