Hauke Mehrtens [2019-05-04 00:00:25]:
Hi,
> On 5/1/19 7:42 PM, Tomasz Maciej Nowak wrote:
> > Replace SoC names with vendors in device names, in few cases, and add
> > vendor to developemnt boards for easier identyfying potential firmware to
> > flash.
>
> Will sysupgrade still work after this
Hauke Mehrtens [2019-05-04 00:03:29]:
Hi,
> > diff --git a/target/linux/mvebu/base-files/lib/preinit/79_move_config
> > b/target/linux/mvebu/base-files/lib/preinit/79_move_config
> > index f7e23cc324..640fb5cdad 100644
> > --- a/target/linux/mvebu/base-files/lib/preinit/79_move_config
> > +++
On 5/1/19 7:42 PM, Tomasz Maciej Nowak wrote:
> This commit adds support for different iterations of ESPRESSObin.
> The added variants are:
>
> ESPRESSObin with soldered eMMC,
>
> ESPRESSObin V7, compared to V5 some passive elements changed and ethernet
> ports labels positions have been
On 5/1/19 7:42 PM, Tomasz Maciej Nowak wrote:
> Replace SoC names with vendors in device names, in few cases, and add
> vendor to developemnt boards for easier identyfying potential firmware to
> flash.
>
> Signed-off-by: Tomasz Maciej Nowak
> diff --git
On 5/1/19 7:42 PM, Tomasz Maciej Nowak wrote:
> Convert whole target to Device Tree based board detection instead of
> identifying devices by dts file name. With this we can drop mvebu.sh
> translation script and rely on common method for model detection.
>
> Signed-off-by: Tomasz Maciej Nowak
>
On 5/1/19 7:42 PM, Tomasz Maciej Nowak wrote:
> Replace SoC names with vendors in device names, in few cases, and add
> vendor to developemnt boards for easier identyfying potential firmware to
> flash.
Will sysupgrade still work after this rename? Isn't there some script
which checks if the
On 5/3/19 2:44 PM, Petr Štetiar wrote:
> Josef Schlehofer [2019-04-20 01:05:05]:
>
> Hi,
>
>> The driver is for the I2C mux.
>> Schematic available at https://doc.turris.cz/doc/_media/rtrom01-schema.pdf
>>
>> Signed-off-by: Josef Schlehofer
>> ---
>> target/linux/mvebu/image/cortex-a9.mk | 2
This removes support for executing old 32 bit applications on 64 bit ARM
and MIPS kernels.
On OpenWrt we normally compile all the user space applications on our
own and do not support third party binary only modules especial not 32
bit applications on 64 bit CPUs.
This reduces the attack surface
Some targets deactivated CONFIG_SYN_COOKIES, for unknown reasons, use
the default setting from the generic configuration which activates
CONFIG_SYN_COOKIES.
This should prevent SYN flooding.
Signed-off-by: Hauke Mehrtens
---
target/linux/at91/config-4.9 | 1 -
This activates "Supervisor Mode Access Prevention". modern CPUs will
prevent the kernel code from accessing any data from the userspace
without the usage of copy_to_user() or copy_from_user()
Signed-off-by: Hauke Mehrtens
---
target/linux/x86/config-4.14 | 2 +-
target/linux/x86/config-4.19 | 2
This adds additional checks to the copy_from_user() and copy_to_user()
functions. The details are described in this article:
https://lwn.net/Articles/695991/
This should only have a very small performance impact on system calls
and should not affect routing performance.
Signed-off-by: Hauke
This is deactivated by default and should be manually activated in the
OpenWrt kernel configuration
Signed-off-by: Hauke Mehrtens
---
target/linux/layerscape/armv7/config-4.14 | 2 --
target/linux/layerscape/armv8_32b/config-4.14 | 2 --
target/linux/layerscape/armv8_64b/config-4.14 | 1 -
This activates "Emulate Privileged Access Never using TTBR0_EL1
switching" on ARM64.
This should prevent the kernel from reading code from user space in
kernel context.
Signed-off-by: Hauke Mehrtens
---
target/linux/armvirt/64/config-default| 1 -
These were renamed to CONFIG_STRICT_KERNEL_RWX and CONFIG_STRICT_MODULE_RWX and
are
activated in kernel 4.14 and later by default.
Signed-off-by: Hauke Mehrtens
---
target/linux/generic/config-4.14 | 2 --
target/linux/generic/config-4.19 | 2 --
2 files changed, 4 deletions(-)
diff --git
This is activate for all other targets except gemini, also activate it
there.
Signed-off-by: Hauke Mehrtens
---
target/linux/gemini/config-4.14 | 2 --
target/linux/gemini/config-4.19 | 2 --
2 files changed, 4 deletions(-)
diff --git a/target/linux/gemini/config-4.14
This is already activated for all other ARM targets
Signed-off-by: Hauke Mehrtens
---
target/linux/cns3xxx/config-4.14 | 1 -
target/linux/cns3xxx/config-4.19 | 1 -
2 files changed, 2 deletions(-)
diff --git a/target/linux/cns3xxx/config-4.14 b/target/linux/cns3xxx/config-4.14
index
This activates and deactivates some of the options suggested on the
Kernel Self Protection Project/Recommended Settings wiki page
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
Hauke Mehrtens (10):
Kernel: Activate CONFIG_HARDENED_USERCOPY
kernel:
CONFIG_BINFMT_MISC allows it to add support for new executable formats
to the kernel from user space, the kernel will then detect for example a
java binary and call the java execution program automatically. I am not
aware that this feature is used in OpenWrt and this could be used to
exploit
Klaus Kudielka [2019-05-03 20:16:39]:
> Let me remind you that the common one *alone* breaks sysupgrade for those
> four targets, as Tomasz already pointed out earlier.
Well, how could I know what was wrong with v1 if you didn't included the
changes between v1 -> v2 in your v2 patch :-)
On Fri, May 3, 2019 at 11:55 AM, Petr Štetiar wrote:
Rosen Penev [2019-05-03 10:49:54]:
> On May 3, 2019, at 10:17, Petr Štetiar wrote:
>
> Rosen Penev [2019-05-01 10:04:45]:
>
>> The 8 year old file does not have any ARC definitions.
>
> I'm wondering if we need to cary another
Rosen Penev [2019-05-03 10:49:54]:
> > On May 3, 2019, at 10:17, Petr Štetiar wrote:
> >
> > Rosen Penev [2019-05-01 10:04:45]:
> >
> >> The 8 year old file does not have any ARC definitions.
> >
> > I'm wondering if we need to cary another patch forever, thus if it wouldn't
> > be
> >
On Fri, May 3, 2019 at 4:50 AM Petr Štetiar wrote:
>
> Rosen Penev [2019-05-01 10:08:10]:
>
> Hi,
>
> > Missing header for va_list.
>
> shouldn't this go through upstream first? Thanks.
Sent
>
> -- ynezz
___
openwrt-devel mailing list
On 03.05.19 19:05, Petr Štetiar wrote:
Klaus Kudielka [2019-04-24 21:14:38]:
Hi Klaus,
Remove workarounds for the old, inconsistent behaviour from the following
targets: apm821xx, brcm2708, omap, sunxi.
I'm willing to push the fix for mvebu (which the patch series is about), so
please don't
On Fri, May 3, 2019 at 10:12 AM Petr Štetiar wrote:
>
> Rosen Penev [2019-05-01 10:05:20]:
>
> Hi,
>
> > Probably glibc too. argp_help takes a char *. not const char *.
>
> I'm wondering if we need to cary another patch forever, thus if it wouldn't be
> better to backport upstreamed patch and/or
> On May 3, 2019, at 10:17, Petr Štetiar wrote:
>
> Rosen Penev [2019-05-01 10:04:45]:
>
> Hi,
>
>> The 8 year old file does not have any ARC definitions.
>
> I'm wondering if we need to cary another patch forever, thus if it wouldn't be
> better to backport upstreamed patch and/or bump to
Rosen Penev [2019-05-01 10:04:45]:
Hi,
> The 8 year old file does not have any ARC definitions.
I'm wondering if we need to cary another patch forever, thus if it wouldn't be
better to backport upstreamed patch and/or bump to fixed upstream version.
-- ynezz
> Signed-off-by: Rosen Penev
>
Rosen Penev [2019-05-01 10:05:20]:
Hi,
> Probably glibc too. argp_help takes a char *. not const char *.
I'm wondering if we need to cary another patch forever, thus if it wouldn't be
better to backport upstreamed patch and/or bump to fixed upstream version.
-- ynezz
> Signed-off-by: Rosen
Rosen Penev [2019-05-01 10:05:20]:
Hi,
> Probably glibc too. argp_help takes a char *. not const char *.
I'm wondering if we need to cary another patch forever, thus if it wouldn't be
better to backport upstreamed patch and/or bump to fixed upstream version.
-- ynezz
> Signed-off-by: Rosen
Klaus Kudielka [2019-04-24 21:14:38]:
Hi Klaus,
> Remove workarounds for the old, inconsistent behaviour from the following
> targets: apm821xx, brcm2708, omap, sunxi.
I'm willing to push the fix for mvebu (which the patch series is about), so
please don't touch other targets. This should go
Kristian Evensen [2019-05-03 16:58:52]:
Hi,
> In order to install OpenWRT, you first need to compile an initramfs
> (ramdisk)-image for the device.
if the ramdisk image is needed, then we probably should enable it for that
target and provide it, we shouldn't demand end users to build the
This commit makes three changes to the uci shell library:
* A check for UCI_CONFIG_DIR has been added to the command line when
adding anonymous sections. Without this change, adding anonymous
sections to configs not stored in /etc/config is not possible.
* Support for adding/removing items from
Head Weblink HDRM200 is a dual-sim router based on MT7620A. The detailed
specifications are:
- MT7620A (580MHz)
- 64MB RAM
- 16MB of flash (SPI NOR)
- 6x 10/100Mbps Ethernet (MT7620A built-in switch)
- 1x microSD slot
- 1x miniPCIe slot (only USB2.0 bus)
- 2x SIM slots (standard size)
- 1x USB2.0
Josef Schlehofer [2019-04-20 01:05:05]:
Hi,
> The driver is for the I2C mux.
> Schematic available at https://doc.turris.cz/doc/_media/rtrom01-schema.pdf
>
> Signed-off-by: Josef Schlehofer
> ---
> target/linux/mvebu/image/cortex-a9.mk | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Luis Araneda [2019-04-28 11:17:14]:
Hi,
> Make the device's title consistent by adding the manufacturer to their
> title, as the other boards on the target. Additionally, this creates a
> sorted by manufacturer board list on menuconfig
your changes, doesn't correspond with the commit
Stijn Segers [2019-04-27 18:23:21]:
Hi,
> Commit eae6cac6a3added support for the Fritz!Box 7362 SL, but one needs
> an initramfs image to flash OpenWrt from stock firmware (as described in
> the commit log). This patch has the initramfs image built by default.
I've just applied it to my
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
This is a resubmission of the garbled
https://patchwork.ozlabs.org/patch/1088433/
Jeff Kletsky
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
From: Jeff Kletsky
The GL.iNet AR750S is based around the QCA9563
and requires the QCA9887 firmware for operation.
Signed-off-by: Jeff Kletsky
---
target/linux/ath79/image/generic.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ath79/image/generic.mk
Rosen Penev [2019-05-01 10:08:10]:
Hi,
> Missing header for va_list.
shouldn't this go through upstream first? Thanks.
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 5/3/19 12:20 PM, Petr Štetiar wrote:
Jeff Kletsky [2019-05-03 12:11:48]:
That's strange -- perhaps another patch updated it?
no, if you look at the patchwork, the patch was simply sent out broken.
-- ynezz
My apologies, resend due to broken patch
(Only applies to and impacts `master`
Tomasz Maciej Nowak [2019-05-01 19:43:54]:
Hi,
> for better identification. Also create SUPPORTED_DEVICES string from it
> which corresponds to dts compatible string.
>
> Signed-off-by: Tomasz Maciej Nowak
...
> define U-Boot/trimslice
>NAME := CompuLab TrimSlice
> - BUILD_DEVICES :=
Jeff Kletsky [2019-05-03 12:11:48]:
> That's strange -- perhaps another patch updated it?
no, if you look at the patchwork, the patch was simply sent out broken.
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
On 5/3/19 11:19 AM, Petr Štetiar wrote:
Jeff Kletsky [2019-04-20 18:33:10]:
This patch corrects the firmware selection for the ath79 AR750S
The ar71xx AR750S already uses the QCA9887 firmware.
$ fgrep -A 3 Device/gl-ar750s target/linux/ar71xx/image/generic.mk
define Device/gl-ar750s
Jeff Kletsky [2019-04-20 18:33:10]:
> This patch corrects the firmware selection for the ath79 AR750S
>
> The ar71xx AR750S already uses the QCA9887 firmware.
>
> $ fgrep -A 3 Device/gl-ar750s target/linux/ar71xx/image/generic.mk
> define Device/gl-ar750s
> DEVICE_TITLE := GL.iNet GL-AR750S
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Jeffery To [2019-05-03 01:33:27]:
> When looping through a package's STAGING_FILES_LIST (a list of
> file/directory paths delimited by newlines), if the path contains
> spaces, then the path will be split by the while loops, and the
> file/directory will not be deleted/removed.
>
> This sets
Jeffery To [2019-05-03 00:47:06]:
> The default zlib.pc file generated by cmake contains absolute paths.
> This patches the file to use relative paths (relative to ${prefix} and
> ${exec_prefix}).
I can see that from the diff already, but I miss the information, why do you
need this change.
48 matches
Mail list logo
