Re: [PATCH v4 19/27] x86: assembly, make some functions local

[Mark Rutland]

On Wed, Oct 25, 2017 at 04:21:48PM +0200, Jiri Slaby wrote:
> Hi,
> 
> On 10/06/2017, 03:21 PM, Mark Rutland wrote:
> > If the aim of this series is to introduce something that architectures
> > use consistently, then can we please actually poke other architectures
> > about it? e.g. send this to linux-arch, with a cover letter explaining
> > the idea and asking maintainers to take a look.
> 
> Sure, with v5, I will.

Thanks; that's much appreciated, and I look forward to it!

Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 19/27] x86: assembly, make some functions local

[Jiri Slaby]

Hi,

On 10/06/2017, 03:21 PM, Mark Rutland wrote:
> If the aim of this series is to introduce something that architectures
> use consistently, then can we please actually poke other architectures
> about it? e.g. send this to linux-arch, with a cover letter explaining
> the idea and asking maintainers to take a look.

Sure, with v5, I will.

thanks,
-- 
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 19/27] x86: assembly, make some functions local

[Jiri Slaby]

On 10/06/2017, 04:01 PM, Ard Biesheuvel wrote:
> On 6 October 2017 at 13:53, Jiri Slaby  wrote:
>> On 10/04/2017, 09:33 AM, Ard Biesheuvel wrote:
>>> In arm64, we use ENTRY/ENDPROC for functions with external linkage,
>>> and the bare symbol name/ENDPROC for functions with local linkage. I
>>> guess we could add ENDOBJECT if we wanted to, but we never really felt
>>> the need.
>>
>> Yes and this is exactly the reason for the new macros. Now, it's a
>> complete mess. One arch does this, another does that. And we are in a
>> state to have reliable stacktraces, let objtool check functions, let
>> objtool generate annotations (e.g. for ORC unwinder), etc.
>>
> 
> You are implying that ENTRY/ENDPROC and 'bare symbol name'/ENDPROC
> prevent you from doing any of this, but this is simply not true.

If I understand correctly, you have not read the discussion behind the
link I sent you... So in sum:
Initially, I only used the current ENTRY/ENDPROC approach and augmented
it to fix up the mess in x86. But it was concluded that these old macros
are terrible and we rather want to avoid them. It was especially the bad
naming of these old macros. So we discussed what the new naming scheme
could be and this is what we ended up with.

>> Without knowing what is start, where is its end, what is function, what
>> is object (data) etc., it can barely check or even generate anything
>> automatically. Not speaking about impaired macros like your name/ENDPROC
>> above.
>>
> 
> What is the problem with impaired macros?

Obviously that they are impaired. That is the tools do not know where to
stop with reading of code or data.

This is quite usual:

foo:
  mov data,a
  call bar
  ret

data: .string "hello"

This makes the tools to choke on the data while thinking it is still code.

> So what is preventing people from using these new macros in the wrong way?

The tools. It is quite easy to check this during build by a linker and I
have such a patch here. It was not yet concluded (I think) whether we
are going to check this via objtool or by something like my patch.
Noteworthy, objtool can check much more in this respect, obviously.

thanks,
-- 
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

[joeyli]

Hi David, 

On Mon, Oct 23, 2017 at 03:49:44PM +0100, David Howells wrote:
> Alan Cox  wrote:
> 
> > There are a load of standard tools that use this so I think you are going
> > to need a whitelist. Can you at least log *which* MSR in the failing case
> > so a whitelist can be built over time ?
> 
> Will the attached change work for you?
> 

It's good to me.

Joey Lee

> ---
> diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
> index a05a97863286..f18cadbc31ce 100644
> --- a/arch/x86/kernel/msr.c
> +++ b/arch/x86/kernel/msr.c
> @@ -84,8 +84,10 @@ static ssize_t msr_write(struct file *file, const char 
> __user *buf,
>   int err = 0;
>   ssize_t bytes = 0;
>  
> - if (kernel_is_locked_down("Direct MSR access"))
> + if (kernel_is_locked_down("Direct MSR access")) {
> + pr_info("Direct access to MSR %x\n", reg);
>   return -EPERM;
> + }
>  
>   if (count % 8)
>   return -EINVAL; /* Invalid chunk size */
> @@ -135,6 +137,7 @@ static long msr_ioctl(struct file *file, unsigned int 
> ioc, unsigned long arg)
>   break;
>   }
>   if (kernel_is_locked_down("Direct MSR access")) {
> + pr_info("Direct access to MSR %x\n", reg[1]); /* 
> Display %ecx */
>   err = -EPERM;
>   break;
>   }
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set

[Ard Biesheuvel]

The UEFI memory map is a bit vague about how to interpret the
EFI_MEMORY_XP attribute when it is combined with EFI_MEMORY_RP and/or
EFI_MEMORY_WP, which have retroactively been redefined as cacheability
attributes rather than permission attributes.

So let's ignore EFI_MEMORY_XP if _RP and/or _WP are also set. In this
case, it is likely that they are being used to describe the capability
of the region (i.e., whether it has the controls to reconfigure it as
non-executable) rather than the nature of the contents of the region
(i.e., whether it contains data that we will never attempt to execute)

Reported-by: Stephen Boyd 
Tested-by: Stephen Boyd 
Cc: Matt Fleming 
Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/kernel/efi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 82cd07592519..f85ac58d08a3 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -48,7 +48,9 @@ static __init pteval_t 
create_mapping_protection(efi_memory_desc_t *md)
return pgprot_val(PAGE_KERNEL_ROX);
 
/* RW- */
-   if (attr & EFI_MEMORY_XP || type != EFI_RUNTIME_SERVICES_CODE)
+   if (((attr & (EFI_MEMORY_RP | EFI_MEMORY_WP | EFI_MEMORY_XP)) ==
+EFI_MEMORY_XP) ||
+   type != EFI_RUNTIME_SERVICES_CODE)
return pgprot_val(PAGE_KERNEL);
 
/* RWX */
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] efi/capsule-loader: pr_err() strings should end with newlines

[Ard Biesheuvel]

From: Arvind Yadav 

pr_err() messages should terminated with a new-line to avoid
other messages being concatenated onto the end.

Signed-off-by: Arvind Yadav 
Cc: Ard Biesheuvel 
Cc: Jan Kiszka 
Cc: Kweh Hock Leong 
Signed-off-by: Matt Fleming 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/capsule-loader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/capsule-loader.c 
b/drivers/firmware/efi/capsule-loader.c
index ec8ac5c4dd84..51d2874942a2 100644
--- a/drivers/firmware/efi/capsule-loader.c
+++ b/drivers/firmware/efi/capsule-loader.c
@@ -49,7 +49,7 @@ int __efi_capsule_setup_info(struct capsule_info *cap_info)
pages_needed = ALIGN(cap_info->total_size, PAGE_SIZE) / PAGE_SIZE;
 
if (pages_needed == 0) {
-   pr_err("invalid capsule size");
+   pr_err("invalid capsule size\n");
return -EINVAL;
}
 
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL 0/2] EFI updates for v4.15

[Ard Biesheuvel]

The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f:

  Linux 4.14-rc4 (2017-10-08 20:53:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git efi-next

for you to fetch changes up to c19611def8fd3f524bc945f0e8f9becace8fdf06:

  arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set 
(2017-10-16 16:21:26 +0100)


EFI changes for v4.15:
- ignore EFI_MEMORY_XP attributes on ARM if _RP/_WP are set as well
- a cosmetic pr_err() format string fix


Ard Biesheuvel (1):
  arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set

Arvind Yadav (1):
  efi/capsule-loader: pr_err() strings should end with newlines

 arch/arm64/kernel/efi.c   | 4 +++-
 drivers/firmware/efi/capsule-loader.c | 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] efi/efi_test: Prevent an Oops in efi_runtime_query_capsulecaps()

[Ard Biesheuvel]

From: Dan Carpenter 

If "qcaps.capsule_count" is ULONG_MAX then "qcaps.capsule_count + 1"
will overflow to zero and kcalloc() will return the ZERO_SIZE_PTR.  We
try to dereference it inside the loop and crash.

Fixes: ff6301dabc3c ("efi: Add efi_test driver for exporting UEFI runtime 
service interfaces")
Signed-off-by: Dan Carpenter 
Acked-by: Ivan Hu 
Cc: Ard Biesheuvel 
Signed-off-by: Matt Fleming 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/test/efi_test.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/firmware/efi/test/efi_test.c 
b/drivers/firmware/efi/test/efi_test.c
index 08129b7b80ab..41c48a1e8baa 100644
--- a/drivers/firmware/efi/test/efi_test.c
+++ b/drivers/firmware/efi/test/efi_test.c
@@ -593,6 +593,9 @@ static long efi_runtime_query_capsulecaps(unsigned long arg)
if (copy_from_user(, qcaps_user, sizeof(qcaps)))
return -EFAULT;
 
+   if (qcaps.capsule_count == ULONG_MAX)
+   return -EINVAL;
+
capsules = kcalloc(qcaps.capsule_count + 1,
   sizeof(efi_capsule_header_t), GFP_KERNEL);
if (!capsules)
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] efi/libstub: arm: don't randomize runtime regions when CONFIG_HIBERNATION=y

[Ard Biesheuvel]

Commit

  e69176d68d26 ef/libstub/arm/arm64: Randomize the base of the UEFI rt services 
region

implemented randomization of the virtual mapping that the OS chooses for
the UEFI runtime services. This was motivated by the fact that UEFI usually
does not bother to specify any permission restrictions for those regions,
making them prime real estate for exploitation now that the OS is getting
more and more careful not to leave any R+W+X mapped regions lying around.

However, this randomization breaks assumptions in the resume from
hibernation code, which expects all memory regions populated by UEFI to
remain in the same place, including their virtual mapping into the OS
memory space. While this assumption may not be entirely reasonable in the
first place, breaking it deliberately does not make a lot of sense either.
So let's refrain from this randomization pass if CONFIG_HIBERNATION=y.

Cc: James Morse 
Cc: Matt Fleming 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/libstub/arm-stub.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
b/drivers/firmware/efi/libstub/arm-stub.c
index 1cb2d1c070c3..a94601d5939e 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -238,7 +238,8 @@ unsigned long efi_entry(void *handle, efi_system_table_t 
*sys_table,
 
efi_random_get_seed(sys_table);
 
-   if (!nokaslr()) {
+   /* hibernation expects the runtime regions to stay in the same place */
+   if (!IS_ENABLED(CONFIG_HIBERNATION) && !nokaslr()) {
/*
 * Randomize the base of the UEFI runtime services region.
 * Preserve the 2 MB alignment of the region by taking a
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL 0/2] EFI fixes for v4.14

[Ard Biesheuvel]

The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f:

  Linux 4.14-rc4 (2017-10-08 20:53:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent

for you to fetch changes up to 8509c79af61fc8066fc21c01a0a9403ef2af7397:

  efi/libstub: arm: don't randomize runtime regions when CONFIG_HIBERNATION=y 
(2017-10-24 21:53:49 +0100)


Two EFI fixes for v4.14:
- avoid OOPSing on a capsule count overflow in the EFI test ioctl interface
- avoid crashing on UEFI runtime services invocations after resume from
  hibernation on ARM


Ard Biesheuvel (1):
  efi/libstub: arm: don't randomize runtime regions when 
CONFIG_HIBERNATION=y

Dan Carpenter (1):
  efi/efi_test: Prevent an Oops in efi_runtime_query_capsulecaps()

 drivers/firmware/efi/libstub/arm-stub.c | 3 ++-
 drivers/firmware/efi/test/efi_test.c| 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Статьи, способствующие раскрутке web-сайтов

[nkuztxt0044]

Приветствую Вас, коллеги!

Занимаюсь SEO-продвижением web-сайтов в выдаче поисковиков. Подготавливаю,  
способствующие этому, тексты.


Предоставить стоимость и примеры?
С уважением к Вам, Наталья
N�r��yb�X��ǧv�^�)޺{.n�+{�y^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down

[joeyli]

On Mon, Oct 23, 2017 at 03:53:00PM +0100, David Howells wrote:
> j...@suse.com wrote:
> 
> > hm... patch 4 only prevents write_mem() but not read_mem().
> > Or I missed anything?
> 
> Actually, yes, as it happens, patch 11 prevents you from even opening /dev/mem
> and /dev/kmem by locking down open of /dev/port.  So I've moved this bit to
> patch 4, simplified and posted a new variant for patch 4.
>

Thank you for pointing out!

Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html