Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SHA-1 in-kernel hardware acceleration #11

Open
neagix opened this issue Aug 19, 2017 · 5 comments
Open

SHA-1 in-kernel hardware acceleration #11

neagix opened this issue Aug 19, 2017 · 5 comments
Labels
enhancement minor

Comments

@neagix
Copy link
Owner

neagix commented Aug 19, 2017

Likewise #10, it should be possible to implemented SHA-1 in-kernel hardware acceleration.

For reference: http://wiibrew.org/wiki/Hardware/SHA-1_Engine
And: http://wiibrew.org/wiki/Hextwelve

Cc @marcan
@neagix neagix changed the title SHA=1 in-kernel hardware acceleration SHA-1 in-kernel hardware acceleration Aug 19, 2017
@ghost
Copy link

ghost commented Oct 9, 2017

I don't think that will work. The Wii's SHA-1 engine isn't sane. It generates a completely different SHA-1 hash for a file than normal. It also sometimes generates a hash less than 40 bits long somehow.

@marcan
Copy link

marcan commented Oct 9, 2017 •
edited
Loading

Um, no, that's not the case. I have no idea where you've gotten that info from. The SHA-1 engine is completely compliant (though it does not perform padding, you have to do that yourself) and it always generates a correct 160-bit hash. Generating a smaller hash doesn't even make sense because the hash registers are 160 bits.

@neagix
Copy link
Owner Author

neagix commented Oct 9, 2017 •
edited
Loading

@Jasjar42 if you check the Hextwelve POC, it actually just runs a SHA1 unit test that verifies it's compliant

@ghost
Copy link

ghost commented Oct 10, 2017 •
edited by ghost
Loading

@marcan Sorry I was wrong. Can you please tell me where my info is wrong? As wiibrew says boot0 loads boot1 and verifies its SHA1 hash against that stored in OTP. But the only boot1 OTP hash that is 40 bits long is the one for boot1d. Boot1b's OTP hash is: EF3EF781968D56DF5679A6F92E13F78BBDDFDF which is only 38 bits long. I wasn't able to match any SHA-1 hashes to the corresponding OTP hash in any way, even with encrypted or decrypted versions. I came to that conclusion because of that. Thanks.

@marcan
Copy link

marcan commented Oct 10, 2017 •
edited
Loading

You're mixing up bits and nybbles. A SHA-1 hash is 160 bits or 40 nybbles. The truncated hashes on Wiibrew are just typos, they're all supposed to be 160 bits.

It's true, however, that boot1 hashes are not standard SHA-1 hashes because boot0 does not apply the standard padding. This is the only part of Wii firmware that does not do this. With proper padding the hashes would correspond to standard SHA-1 hashes.

ThatsItForTheOtherOne pushed a commit to Wii-Linux/wii-linux-ngx that referenced this issue Oct 16, 2023
@tamird
ACPICA: Avoid undefined behavior: applying zero offset to null pointer
d5822e7 
[ Upstream commit 05bb016 ]

ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e

Before this change we see the following UBSAN stack trace in Fuchsia:

  #0    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302
  #1.2  0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f
  #1.1  0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f
  #1    0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f
  #2    0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d
  #3    0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d
  #4    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302
  #5    0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369
  neagix#6    0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac
  neagix#7    0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2
  neagix#8    0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052
  neagix#9    0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8
  neagix#10   0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98
  neagix#11   0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac
  neagix#12   0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d
  neagix#13   0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603

Add a simple check that avoids incrementing a pointer by zero, but
otherwise behaves as before. Note that our findings are against ACPICA
20221020, but the same code exists on master.

Link: acpica/acpica@770653e3
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
techflashYT pushed a commit to Wii-Linux/wii-linux-ngx that referenced this issue Jun 29, 2024
@dhowells
fscache: fix race between enablement and dropping of object
c5a94f4 
It was observed that a process blocked indefintely in
__fscache_read_or_alloc_page(), waiting for FSCACHE_COOKIE_LOOKING_UP
to be cleared via fscache_wait_for_deferred_lookup().

At this time, ->backing_objects was empty, which would normaly prevent
__fscache_read_or_alloc_page() from getting to the point of waiting.
This implies that ->backing_objects was cleared *after*
__fscache_read_or_alloc_page was was entered.

When an object is "killed" and then "dropped",
FSCACHE_COOKIE_LOOKING_UP is cleared in fscache_lookup_failure(), then
KILL_OBJECT and DROP_OBJECT are "called" and only in DROP_OBJECT is
->backing_objects cleared.  This leaves a window where
something else can set FSCACHE_COOKIE_LOOKING_UP and
__fscache_read_or_alloc_page() can start waiting, before
->backing_objects is cleared

There is some uncertainty in this analysis, but it seems to be fit the
observations.  Adding the wake in this patch will be handled correctly
by __fscache_read_or_alloc_page(), as it checks if ->backing_objects
is empty again, after waiting.

Customer which reported the hang, also report that the hang cannot be
reproduced with this fix.

The backtrace for the blocked process looked like:

PID: 29360  TASK: ffff881ff2ac0f80  CPU: 3   COMMAND: "zsh"
 #0 [ffff881ff43efbf8] schedule at ffffffff815e56f1
 #1 [ffff881ff43efc58] bit_wait at ffffffff815e64ed
 #2 [ffff881ff43efc68] __wait_on_bit at ffffffff815e61b8
 #3 [ffff881ff43efca0] out_of_line_wait_on_bit at ffffffff815e625e
 #4 [ffff881ff43efd08] fscache_wait_for_deferred_lookup at ffffffffa04f2e8f [fscache]
 #5 [ffff881ff43efd18] __fscache_read_or_alloc_page at ffffffffa04f2ffe [fscache]
 neagix#6 [ffff881ff43efd58] __nfs_readpage_from_fscache at ffffffffa0679668 [nfs]
 neagix#7 [ffff881ff43efd78] nfs_readpage at ffffffffa067092b [nfs]
 neagix#8 [ffff881ff43efda0] generic_file_read_iter at ffffffff81187a73
 neagix#9 [ffff881ff43efe50] nfs_file_read at ffffffffa066544b [nfs]
neagix#10 [ffff881ff43efe70] __vfs_read at ffffffff811fc756
neagix#11 [ffff881ff43efee8] vfs_read at ffffffff811fccfa
neagix#12 [ffff881ff43eff18] sys_read at ffffffff811fda62
neagix#13 [ffff881ff43eff50] entry_SYSCALL_64_fastpath at ffffffff815e986e

Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: David Howells <dhowells@redhat.com>
techflashYT pushed a commit to Wii-Linux/wii-linux-ngx that referenced this issue Jun 29, 2024
@rikvanriel @torvalds
fork,memcg: fix crash in free_thread_stack on memcg charge fail
5eed6f1 
Commit 9b6f7e1 ("mm: rework memcg kernel stack accounting") will
result in fork failing if allocating a kernel stack for a task in
dup_task_struct exceeds the kernel memory allowance for that cgroup.

Unfortunately, it also results in a crash.

This is due to the code jumping to free_stack and calling
free_thread_stack when the memcg kernel stack charge fails, but without
tsk->stack pointing at the freshly allocated stack.

This in turn results in the vfree_atomic in free_thread_stack oopsing
with a backtrace like this:

#5 [ffffc900244efc88] die at ffffffff8101f0ab
 neagix#6 [ffffc900244efcb8] do_general_protection at ffffffff8101cb86
 neagix#7 [ffffc900244efce0] general_protection at ffffffff818ff082
    [exception RIP: llist_add_batch+7]
    RIP: ffffffff8150d487  RSP: ffffc900244efd98  RFLAGS: 00010282
    RAX: 0000000000000000  RBX: ffff88085ef55980  RCX: 0000000000000000
    RDX: ffff88085ef55980  RSI: 343834343531203a  RDI: 343834343531203a
    RBP: ffffc900244efd98   R8: 0000000000000001   R9: ffff8808578c3600
    R10: 0000000000000000  R11: 0000000000000001  R12: ffff88029f6c21c0
    R13: 0000000000000286  R14: ffff880147759b00  R15: 0000000000000000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 neagix#8 [ffffc900244efda0] vfree_atomic at ffffffff811df2c7
 neagix#9 [ffffc900244efdb8] copy_process at ffffffff81086e37
neagix#10 [ffffc900244efe98] _do_fork at ffffffff810884e0
neagix#11 [ffffc900244eff10] sys_vfork at ffffffff810887ff
neagix#12 [ffffc900244eff20] do_syscall_64 at ffffffff81002a43
    RIP: 000000000049b948  RSP: 00007ffcdb307830  RFLAGS: 00000246
    RAX: ffffffffffffffda  RBX: 0000000000896030  RCX: 000000000049b948
    RDX: 0000000000000000  RSI: 00007ffcdb307790  RDI: 00000000005d7421
    RBP: 000000000067370f   R8: 00007ffcdb3077b0   R9: 000000000001ed00
    R10: 0000000000000008  R11: 0000000000000246  R12: 0000000000000040
    R13: 000000000000000f  R14: 0000000000000000  R15: 000000000088d018
    ORIG_RAX: 000000000000003a  CS: 0033  SS: 002b

The simplest fix is to assign tsk->stack right where it is allocated.

Link: http://lkml.kernel.org/r/20181214231726.7ee4843c@imladris.surriel.com
Fixes: 9b6f7e1 ("mm: rework memcg kernel stack accounting")
Signed-off-by: Rik van Riel <riel@surriel.com>
Acked-by: Roman Gushchin <guro@fb.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement minor
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@marcan @neagix