Re: [OpenWrt-Devel] [PATCH] kernel: MIPS: math-emu Write-protect delay slot emulation pages

2018-12-21 Thread Rosen Penev
On Fri, Dec 21, 2018 at 8:05 PM Yousong Zhou  wrote:
>
> On Sat, 22 Dec 2018 at 01:21, Kevin 'ldir' Darbyshire-Bryant
>  wrote:
> >
> > Backport 
> > https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=adcc81f148d733b7e8e641300c5590a2cdc13bf3
> >
> > "Mapping the delay slot emulation page as both writeable & executable
> > presents a security risk, in that if an exploit can write to & jump into
> > the page then it can be used as an easy way to execute arbitrary code.
> >
> > Prevent this by mapping the page read-only for userland, and using
> > access_process_vm() with the FOLL_FORCE flag to write to it from
> > mips_dsemul().
> >
> > This will likely be less efficient due to copy_to_user_page() performing
> > cache maintenance on a whole page, rather than a single line as in the
> > previous use of flush_cache_sigtramp(). However this delay slot
> > emulation code ought not to be running in any performance critical paths
> > anyway so this isn't really a problem, and we can probably do better in
> > copy_to_user_page() anyway in future.
> >
> > A major advantage of this approach is that the fix is small & simple to
> > backport to stable kernels.
> >
> > Reported-by: Andy Lutomirski 
> > Signed-off-by: Paul Burton 
> > Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot 
> > instructions")"
> >
> > Without patch:
> >
> > cat /proc/self/maps
> > 0040-0047a000 r-xp  1f:03 1823   /bin/busybox
> > 00489000-0048a000 r-xp 00079000 1f:03 1823   /bin/busybox
> > 0048a000-0048b000 rwxp 0007a000 1f:03 1823   /bin/busybox
> > 77ec8000-77eed000 r-xp  1f:03 2296   /lib/libgcc_s.so.1
> > 77eed000-77eee000 rwxp 00015000 1f:03 2296   /lib/libgcc_s.so.1
> > 77eee000-77f81000 r-xp  1f:03 2470   /lib/libc.so
> > 77f9-77f92000 rwxp 00092000 1f:03 2470   /lib/libc.so
> > 77f92000-77f94000 rwxp  00:00 0
> > 7f946000-7f967000 rw-p  00:00 0  [stack]
> > 7fefb000-7fefc000 rwxp  00:00 0
> > 7ffac000-7ffad000 r--p  00:00 0  [vvar]
> > 7ffad000-7ffae000 r-xp  00:00 0  [vdso]
>
> Hi,
>
> I must miss something.  After reading another thread on mips security,
> I was thinking that all segments with w and x permission set were
> problematic:  the same attacker can write and execute shellcode there,
> right?  Sorry, if the answer is too apparent ;(
Right. This is a fix for one of those sections. Not all of them.

It will take quite a bit of work to fix all of them.
>
> Regards,
> yousong
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] kernel: MIPS: math-emu Write-protect delay slot emulation pages

2018-12-21 Thread Yousong Zhou
On Sat, 22 Dec 2018 at 01:21, Kevin 'ldir' Darbyshire-Bryant
 wrote:
>
> Backport 
> https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=adcc81f148d733b7e8e641300c5590a2cdc13bf3
>
> "Mapping the delay slot emulation page as both writeable & executable
> presents a security risk, in that if an exploit can write to & jump into
> the page then it can be used as an easy way to execute arbitrary code.
>
> Prevent this by mapping the page read-only for userland, and using
> access_process_vm() with the FOLL_FORCE flag to write to it from
> mips_dsemul().
>
> This will likely be less efficient due to copy_to_user_page() performing
> cache maintenance on a whole page, rather than a single line as in the
> previous use of flush_cache_sigtramp(). However this delay slot
> emulation code ought not to be running in any performance critical paths
> anyway so this isn't really a problem, and we can probably do better in
> copy_to_user_page() anyway in future.
>
> A major advantage of this approach is that the fix is small & simple to
> backport to stable kernels.
>
> Reported-by: Andy Lutomirski 
> Signed-off-by: Paul Burton 
> Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot 
> instructions")"
>
> Without patch:
>
> cat /proc/self/maps
> 0040-0047a000 r-xp  1f:03 1823   /bin/busybox
> 00489000-0048a000 r-xp 00079000 1f:03 1823   /bin/busybox
> 0048a000-0048b000 rwxp 0007a000 1f:03 1823   /bin/busybox
> 77ec8000-77eed000 r-xp  1f:03 2296   /lib/libgcc_s.so.1
> 77eed000-77eee000 rwxp 00015000 1f:03 2296   /lib/libgcc_s.so.1
> 77eee000-77f81000 r-xp  1f:03 2470   /lib/libc.so
> 77f9-77f92000 rwxp 00092000 1f:03 2470   /lib/libc.so
> 77f92000-77f94000 rwxp  00:00 0
> 7f946000-7f967000 rw-p  00:00 0  [stack]
> 7fefb000-7fefc000 rwxp  00:00 0
> 7ffac000-7ffad000 r--p  00:00 0  [vvar]
> 7ffad000-7ffae000 r-xp  00:00 0  [vdso]

Hi,

I must miss something.  After reading another thread on mips security,
I was thinking that all segments with w and x permission set were
problematic:  the same attacker can write and execute shellcode there,
right?  Sorry, if the answer is too apparent ;(

Regards,
yousong

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] kernel: MIPS: math-emu Write-protect delay slot emulation pages

2018-12-21 Thread Rosen Penev
On Fri, Dec 21, 2018 at 9:21 AM Kevin 'ldir' Darbyshire-Bryant
 wrote:
>
> Backport 
> https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=adcc81f148d733b7e8e641300c5590a2cdc13bf3
>
> "Mapping the delay slot emulation page as both writeable & executable
> presents a security risk, in that if an exploit can write to & jump into
> the page then it can be used as an easy way to execute arbitrary code.
>
> Prevent this by mapping the page read-only for userland, and using
> access_process_vm() with the FOLL_FORCE flag to write to it from
> mips_dsemul().
>
> This will likely be less efficient due to copy_to_user_page() performing
> cache maintenance on a whole page, rather than a single line as in the
> previous use of flush_cache_sigtramp(). However this delay slot
> emulation code ought not to be running in any performance critical paths
> anyway so this isn't really a problem, and we can probably do better in
> copy_to_user_page() anyway in future.
>
> A major advantage of this approach is that the fix is small & simple to
> backport to stable kernels.
>
> Reported-by: Andy Lutomirski 
> Signed-off-by: Paul Burton 
> Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot 
> instructions")"
>
> Without patch:
>
> cat /proc/self/maps
> 0040-0047a000 r-xp  1f:03 1823   /bin/busybox
> 00489000-0048a000 r-xp 00079000 1f:03 1823   /bin/busybox
> 0048a000-0048b000 rwxp 0007a000 1f:03 1823   /bin/busybox
> 77ec8000-77eed000 r-xp  1f:03 2296   /lib/libgcc_s.so.1
> 77eed000-77eee000 rwxp 00015000 1f:03 2296   /lib/libgcc_s.so.1
> 77eee000-77f81000 r-xp  1f:03 2470   /lib/libc.so
> 77f9-77f92000 rwxp 00092000 1f:03 2470   /lib/libc.so
> 77f92000-77f94000 rwxp  00:00 0
> 7f946000-7f967000 rw-p  00:00 0  [stack]
> 7fefb000-7fefc000 rwxp  00:00 0
> 7ffac000-7ffad000 r--p  00:00 0  [vvar]
> 7ffad000-7ffae000 r-xp  00:00 0  [vdso]
>
> Patch applied:
>
> cat /proc/self/maps
> 0040-0047a000 r-xp  1f:03 1825   /bin/busybox
> 00489000-0048a000 r-xp 00079000 1f:03 1825   /bin/busybox
> 0048a000-0048b000 rwxp 0007a000 1f:03 1825   /bin/busybox
> 77ed-77ef5000 r-xp  1f:03 2298   /lib/libgcc_s.so.1
> 77ef5000-77ef6000 rwxp 00015000 1f:03 2298   /lib/libgcc_s.so.1
> 77ef6000-77f89000 r-xp  1f:03 2474   /lib/libc.so
> 77f98000-77f9a000 rwxp 00092000 1f:03 2474   /lib/libc.so
> 77f9a000-77f9c000 rwxp  00:00 0
> 7fbed000-7fc0e000 rw-p  00:00 0  [stack]
> 7fefb000-7fefc000 r-xp  00:00 0
> 7fff6000-7fff7000 r--p  00:00 0  [vvar]
> 7fff7000-7fff8000 r-xp  00:00 0  [vdso]
>
> Note lack of write permission to 7fefb000-7fefc000
>
> This has received minimal testing on ath79 4.14 Archer C7 v2 only
>
> Signed-off-by: Kevin Darbyshire-Bryant 
This will make it in the stable kernels within a few releases. Might
as well add in in the meantime.

> ---
>  ...e-protect-delay-slot-emulation-pages.patch | 119 ++
>  ...e-protect-delay-slot-emulation-pages.patch | 119 ++
>  ...e-protect-delay-slot-emulation-pages.patch | 119 ++
>  3 files changed, 357 insertions(+)
>  create mode 100644 
> target/linux/generic/backport-4.14/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
>  create mode 100644 
> target/linux/generic/backport-4.19/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
>  create mode 100644 
> target/linux/generic/backport-4.9/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
>
> diff --git 
> a/target/linux/generic/backport-4.14/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
>  
> b/target/linux/generic/backport-4.14/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
> new file mode 100644
> index 00..f428285a64
> --- /dev/null
> +++ 
> b/target/linux/generic/backport-4.14/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
> @@ -0,0 +1,119 @@
> +From adcc81f148d733b7e8e641300c5590a2cdc13bf3 Mon Sep 17 00:00:00 2001
> +From: Paul Burton 
> +Date: Thu, 20 Dec 2018 17:45:43 +
> +Subject: MIPS: math-emu: Write-protect delay slot emulation pages
> +
> +Mapping the delay slot emulation page as both writeable & executable
> +presents a security risk, in that if an exploit can write to & jump into
> +the page then it can be used as an easy way to execute arbitrary code.
> +
> +Prevent this by mapping the page read-only for userland, and using
> +access_process_vm() with the FOLL_FORCE flag to write to it from
> +mips_dsemul().
> +
> +This will likely be less efficient due to copy_to_user_page() performing
> +cache maintenance on a whole page, rather than a single line as in the
> +previous use of flush_cache_sigtramp(). However this delay slot
> +emulation code ought not to be running in any performance critical 

[OpenWrt-Devel] [PATCH] kernel: MIPS: math-emu Write-protect delay slot emulation pages

2018-12-21 Thread Kevin 'ldir' Darbyshire-Bryant
Backport 
https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=adcc81f148d733b7e8e641300c5590a2cdc13bf3

"Mapping the delay slot emulation page as both writeable & executable
presents a security risk, in that if an exploit can write to & jump into
the page then it can be used as an easy way to execute arbitrary code.

Prevent this by mapping the page read-only for userland, and using
access_process_vm() with the FOLL_FORCE flag to write to it from
mips_dsemul().

This will likely be less efficient due to copy_to_user_page() performing
cache maintenance on a whole page, rather than a single line as in the
previous use of flush_cache_sigtramp(). However this delay slot
emulation code ought not to be running in any performance critical paths
anyway so this isn't really a problem, and we can probably do better in
copy_to_user_page() anyway in future.

A major advantage of this approach is that the fix is small & simple to
backport to stable kernels.

Reported-by: Andy Lutomirski 
Signed-off-by: Paul Burton 
Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot 
instructions")"

Without patch:

cat /proc/self/maps
0040-0047a000 r-xp  1f:03 1823   /bin/busybox
00489000-0048a000 r-xp 00079000 1f:03 1823   /bin/busybox
0048a000-0048b000 rwxp 0007a000 1f:03 1823   /bin/busybox
77ec8000-77eed000 r-xp  1f:03 2296   /lib/libgcc_s.so.1
77eed000-77eee000 rwxp 00015000 1f:03 2296   /lib/libgcc_s.so.1
77eee000-77f81000 r-xp  1f:03 2470   /lib/libc.so
77f9-77f92000 rwxp 00092000 1f:03 2470   /lib/libc.so
77f92000-77f94000 rwxp  00:00 0
7f946000-7f967000 rw-p  00:00 0  [stack]
7fefb000-7fefc000 rwxp  00:00 0
7ffac000-7ffad000 r--p  00:00 0  [vvar]
7ffad000-7ffae000 r-xp  00:00 0  [vdso]

Patch applied:

cat /proc/self/maps
0040-0047a000 r-xp  1f:03 1825   /bin/busybox
00489000-0048a000 r-xp 00079000 1f:03 1825   /bin/busybox
0048a000-0048b000 rwxp 0007a000 1f:03 1825   /bin/busybox
77ed-77ef5000 r-xp  1f:03 2298   /lib/libgcc_s.so.1
77ef5000-77ef6000 rwxp 00015000 1f:03 2298   /lib/libgcc_s.so.1
77ef6000-77f89000 r-xp  1f:03 2474   /lib/libc.so
77f98000-77f9a000 rwxp 00092000 1f:03 2474   /lib/libc.so
77f9a000-77f9c000 rwxp  00:00 0
7fbed000-7fc0e000 rw-p  00:00 0  [stack]
7fefb000-7fefc000 r-xp  00:00 0
7fff6000-7fff7000 r--p  00:00 0  [vvar]
7fff7000-7fff8000 r-xp  00:00 0  [vdso]

Note lack of write permission to 7fefb000-7fefc000

This has received minimal testing on ath79 4.14 Archer C7 v2 only

Signed-off-by: Kevin Darbyshire-Bryant 
---
 ...e-protect-delay-slot-emulation-pages.patch | 119 ++
 ...e-protect-delay-slot-emulation-pages.patch | 119 ++
 ...e-protect-delay-slot-emulation-pages.patch | 119 ++
 3 files changed, 357 insertions(+)
 create mode 100644 
target/linux/generic/backport-4.14/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
 create mode 100644 
target/linux/generic/backport-4.19/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
 create mode 100644 
target/linux/generic/backport-4.9/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch

diff --git 
a/target/linux/generic/backport-4.14/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
 
b/target/linux/generic/backport-4.14/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
new file mode 100644
index 00..f428285a64
--- /dev/null
+++ 
b/target/linux/generic/backport-4.14/096-mips-math-emu-Write-protect-delay-slot-emulation-pages.patch
@@ -0,0 +1,119 @@
+From adcc81f148d733b7e8e641300c5590a2cdc13bf3 Mon Sep 17 00:00:00 2001
+From: Paul Burton 
+Date: Thu, 20 Dec 2018 17:45:43 +
+Subject: MIPS: math-emu: Write-protect delay slot emulation pages
+
+Mapping the delay slot emulation page as both writeable & executable
+presents a security risk, in that if an exploit can write to & jump into
+the page then it can be used as an easy way to execute arbitrary code.
+
+Prevent this by mapping the page read-only for userland, and using
+access_process_vm() with the FOLL_FORCE flag to write to it from
+mips_dsemul().
+
+This will likely be less efficient due to copy_to_user_page() performing
+cache maintenance on a whole page, rather than a single line as in the
+previous use of flush_cache_sigtramp(). However this delay slot
+emulation code ought not to be running in any performance critical paths
+anyway so this isn't really a problem, and we can probably do better in
+copy_to_user_page() anyway in future.
+
+A major advantage of this approach is that the fix is small & simple to
+backport to stable kernels.
+
+Reported-by: Andy Lutomirski 
+Signed-off-by: Paul Burton 
+Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot 

[OpenWrt-Devel] [PATCH] kernel: Add compiler options to generic configuration

2018-12-21 Thread Hauke Mehrtens
With kernel 4.19 new configuration options for the compiler were added.
These are automatically selected and set, instead of having them in each
target configuration, put them into the generic configuration.

Signed-off-by: Hauke Mehrtens 
---
 target/linux/generic/config-4.19 | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/target/linux/generic/config-4.19 b/target/linux/generic/config-4.19
index 0fc5ce6621..030ea52724 100644
--- a/target/linux/generic/config-4.19
+++ b/target/linux/generic/config-4.19
@@ -743,6 +743,9 @@ CONFIG_CARDBUS=y
 # CONFIG_CB710_CORE is not set
 # CONFIG_CC10001_ADC is not set
 # CONFIG_CCS811 is not set
+CONFIG_CC_HAS_SANCOV_TRACE_PC=y
+CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
+CONFIG_CC_IS_GCC=y
 CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
 # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
 # CONFIG_CDROM_PKTCDVD is not set
@@ -798,6 +801,7 @@ CONFIG_CIFS_STATS=y
 # CONFIG_CIFS_WEAK_PW_HASH is not set
 # CONFIG_CIFS_XATTR is not set
 # CONFIG_CIO_DAC is not set
+CONFIG_CLANG_VERSION=0
 # CONFIG_CLEANCACHE is not set
 # CONFIG_CLKSRC_VERSATILE is not set
 # CONFIG_CLK_HSDK is not set
@@ -1527,6 +1531,7 @@ CONFIG_GACT_PROB=y
 # CONFIG_GAMEPORT is not set
 # CONFIG_GATEWORKS_GW16083 is not set
 # CONFIG_GCC_PLUGINS is not set
+CONFIG_GCC_VERSION=70400
 # CONFIG_GCOV is not set
 # CONFIG_GCOV_KERNEL is not set
 # CONFIG_GDB_SCRIPTS is not set
@@ -3685,6 +3690,7 @@ CONFIG_PINMUX=y
 # CONFIG_PLATFORM_MHU is not set
 # CONFIG_PLAT_SPEAR is not set
 # CONFIG_PLIP is not set
+CONFIG_PLUGIN_HOSTCC=""
 # CONFIG_PLX_HERMES is not set
 # CONFIG_PM is not set
 # CONFIG_PMBUS is not set
-- 
2.19.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] kernel: Fix KERNEL_STACKPROTECTOR on kernel 4.19

2018-12-21 Thread Hauke Mehrtens
The configuration option was renamed with kernel 4.19 from
CONFIG_CC_STACKPROTECTOR to CONFIG_STACKPROTECTOR adapt the code to set
both options.

CONFIG_STACKPROTECTOR now sets the regular stack protector and
CONFIG_STACKPROTECTOR_STRONG activates the additional protection of more
functions.

Signed-off-by: Hauke Mehrtens 
---
 config/Config-build.in   | 8 
 target/linux/generic/config-4.19 | 6 ++
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/config/Config-build.in b/config/Config-build.in
index a082a5e0e2..8cbc16b5c8 100644
--- a/config/Config-build.in
+++ b/config/Config-build.in
@@ -234,6 +234,14 @@ menu "Global build settings"
bool "Strong"
endchoice
 
+   config  KERNEL_STACKPROTECTOR
+   bool
+   default KERNEL_CC_STACKPROTECTOR_REGULAR || 
KERNEL_CC_STACKPROTECTOR_STRONG
+
+   config  KERNEL_STACKPROTECTOR_STRONG
+   bool
+   default KERNEL_CC_STACKPROTECTOR_STRONG
+
choice
prompt "Enable buffer-overflows detection (FORTIFY_SOURCE)"
default PKG_FORTIFY_SOURCE_1
diff --git a/target/linux/generic/config-4.19 b/target/linux/generic/config-4.19
index dc3d80b57f..0fc5ce6621 100644
--- a/target/linux/generic/config-4.19
+++ b/target/linux/generic/config-4.19
@@ -745,10 +745,6 @@ CONFIG_CARDBUS=y
 # CONFIG_CCS811 is not set
 CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
 # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
-# CONFIG_CC_STACKPROTECTOR is not set
-CONFIG_CC_STACKPROTECTOR_NONE=y
-# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
-# CONFIG_CC_STACKPROTECTOR_STRONG is not set
 # CONFIG_CDROM_PKTCDVD is not set
 # CONFIG_CEPH_FS is not set
 # CONFIG_CEPH_LIB is not set
@@ -1650,6 +1646,7 @@ CONFIG_HAVE_KERNEL_XZ=y
 CONFIG_HAVE_KPROBES=y
 CONFIG_HAVE_KRETPROBES=y
 CONFIG_HAVE_NMI=y
+CONFIG_HAVE_STACKPROTECTOR=y
 # CONFIG_HCALL_STATS is not set
 # CONFIG_HDC100X is not set
 # CONFIG_HDLC is not set
@@ -4942,6 +4939,7 @@ CONFIG_SSB_POSSIBLE=y
 # CONFIG_SSB_SILENT is not set
 # CONFIG_SSFDC is not set
 # CONFIG_STACKPROTECTOR is not set
+# CONFIG_STACKPROTECTOR_STRONG is not set
 # CONFIG_STACKTRACE is not set
 CONFIG_STACKTRACE_SUPPORT=y
 # CONFIG_STACK_TRACER is not set
-- 
2.19.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches

2018-12-21 Thread Thomas Endt



> -Ursprüngliche Nachricht-
> Von: openwrt-devel  Im Auftrag
> von James Feeney
> Gesendet: Donnerstag, 20. Dezember 2018 20:46
[...]

> There also seems to be a presumption that a "newbie" is, or should be,
> running luci.  I believe that that is also an inappropriate assumption.
> 
> Using some web interface is not necessarily any easier than using a
> command line interface.

I see quite some users in the forum which install a snapshot (w/o LuCI).
Their reaction:

1) I can not connect to the web interface! I need web interface! Please
help!
2) How can I go back to stock firmware?

Some users can perfectly live without LuCI, some others can't.

Thomas


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Removed target staging dir in SDK

2018-12-21 Thread Jo-Philipp Wich
Hi,

> Why did you remove this dir?

To save space on the download servers.

> If we want to build custom binaries using SDK, should we use something else?

Use the feeds mechanism within the SDK to build your required libaries
first, e.g.:

./scripts/feeds update
./scripts/feeds install libpcap

make package/libpcap/compile V=s

[then build custom software using libpcap].


Regards,
Jo



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] Removed target staging dir in SDK

2018-12-21 Thread Matej Kupljen
Hi,

in the commit 7dfbac8073e1f5fd47f85743b9ebead842ed3c70, signed of by
Felix Fietkau, you removed staging_dir/target_ directory from SDK
build.

In this folder all the libraries and header files need for compiling
custom binaries reside.

Why did you remove this dir?
If we want to build custom binaries using SDK, should we use something else?

Thanks,
Matej

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel