Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимости в ядре Linux, позволяющие поднять свои привилегии через nf_tables и ksmbd"	+/–
Сообщение от opennews (??), 27-Мрт-24, 11:38
В Netfilter, подсистеме ядра Linux, используемой для фильтрации и модификации сетевых пакетов, выявлена уязвимость (CVE-2024-1086), позволяющая локальному пользователю выполнить код на уровне ядра и поднять свои привилегии в системе. Проблема вызвана двойным освобождением памяти (double-free) в модуле nf_tables, обеспечивающем работу пакетного фильтра nftables. Выявивший уязвимость исследователь безопасности разработал и опубликовал рабочий прототип эксплоита, применимый к ядрам Linux начиная с выпуска 3.15 и заканчивая 6.8-rc1... Подробнее: https://www.opennet.me/opennews/art.shtml?num=60860
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–9 +/–
Сообщение от Аноним (-), 27-Мрт-24, 11:38
>Работа эксплоита продемонстрирована в актуальных выпусках Debian и Ubuntu Потому что там нет SELinux.
Ответить | Правка | Наверх | Cообщить модератору

	2. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+14 +/–
	Сообщение от Аноним (2), 27-Мрт-24, 11:47
	И как SELinux поможет от дыры в _ядре_?
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 12:42
	Скачайте эксплойт и убедитесь сами.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (2), 27-Мрт-24, 16:29
	> Скачайте эксплойт и убедитесь сами. И как SELinux защитит модуль ksmbd в ядре от запуска удалённо атакующего эксплоита, скаченного и запущенного на моей системе, если после эксплуатации дыры он выполнит код на уровне ядра и получает полный контроль на уровне ядра, т.е. при желании может вообще отключить этот SELinux и загрузить своё ядро?
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 16:40
	В нормальных дистрибутивах отключение SELinux во время работы невозможно. Повторю совет попробовать эксплойт на Fedora и не выдумывать.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (2), 27-Мрт-24, 17:34
	> В нормальных дистрибутивах отключение SELinux во время работы невозможно. Повторю совет попробовать эксплойт на Fedora и не выдумывать. Эксплоита для ksmbd ещё нет, пробовать нечего. В эксплоите к netfilter достаточно ограничить доступ к netfilter, но не о нём речь.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 18:02
	Когда появится, тогда и проверяйте.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (162), 28-Мрт-24, 10:11
	> В нормальных дистрибутивах отключение SELinux Пример такого дистрибутива в студию с пруфами о неотключаемости selinux Так же в студию требуются пруфы о том, что selinux может в перехват сетевых пакетов, прилетающих извне
	Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

	164. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от pavlinux (ok), 28-Мрт-24, 12:13
	> Так же в студию требуются пруфы о том, что selinux может в перехват сетевых пакетов, прилетающих извне Так уж и быть,  опущу очередного васяна анонима static struct security_hook_list selinux_hooks[] __ro_after_init = {     LSM_HOOK_INIT(binder_set_context_mgr, selinux_binder_set_context_mgr),     LSM_HOOK_INIT(binder_transaction, selinux_binder_transaction),     LSM_HOOK_INIT(binder_transfer_binder, selinux_binder_transfer_binder),     LSM_HOOK_INIT(binder_transfer_file, selinux_binder_transfer_file),     LSM_HOOK_INIT(ptrace_access_check, selinux_ptrace_access_check),     LSM_HOOK_INIT(ptrace_traceme, selinux_ptrace_traceme),     LSM_HOOK_INIT(capget, selinux_capget),     LSM_HOOK_INIT(capset, selinux_capset),     LSM_HOOK_INIT(capable, selinux_capable),     LSM_HOOK_INIT(quotactl, selinux_quotactl),     LSM_HOOK_INIT(quota_on, selinux_quota_on),     LSM_HOOK_INIT(syslog, selinux_syslog),     LSM_HOOK_INIT(vm_enough_memory, selinux_vm_enough_memory),     LSM_HOOK_INIT(netlink_send, selinux_netlink_send),     LSM_HOOK_INIT(bprm_creds_for_exec, selinux_bprm_creds_for_exec),     LSM_HOOK_INIT(bprm_committing_creds, selinux_bprm_committing_creds),     LSM_HOOK_INIT(bprm_committed_creds, selinux_bprm_committed_creds),     LSM_HOOK_INIT(sb_free_mnt_opts, selinux_free_mnt_opts),     LSM_HOOK_INIT(sb_mnt_opts_compat, selinux_sb_mnt_opts_compat),     LSM_HOOK_INIT(sb_remount, selinux_sb_remount),     LSM_HOOK_INIT(sb_kern_mount, selinux_sb_kern_mount),     LSM_HOOK_INIT(sb_show_options, selinux_sb_show_options),     LSM_HOOK_INIT(sb_statfs, selinux_sb_statfs),     LSM_HOOK_INIT(sb_mount, selinux_mount),     LSM_HOOK_INIT(sb_umount, selinux_umount),     LSM_HOOK_INIT(sb_set_mnt_opts, selinux_set_mnt_opts),     LSM_HOOK_INIT(sb_clone_mnt_opts, selinux_sb_clone_mnt_opts),     LSM_HOOK_INIT(move_mount, selinux_move_mount),     LSM_HOOK_INIT(dentry_init_security, selinux_dentry_init_security),     LSM_HOOK_INIT(dentry_create_files_as, selinux_dentry_create_files_as),     LSM_HOOK_INIT(inode_free_security, selinux_inode_free_security),     LSM_HOOK_INIT(inode_init_security, selinux_inode_init_security),     LSM_HOOK_INIT(inode_init_security_anon, selinux_inode_init_security_anon),     LSM_HOOK_INIT(inode_create, selinux_inode_create),     LSM_HOOK_INIT(inode_link, selinux_inode_link),     LSM_HOOK_INIT(inode_unlink, selinux_inode_unlink),     LSM_HOOK_INIT(inode_symlink, selinux_inode_symlink),     LSM_HOOK_INIT(inode_mkdir, selinux_inode_mkdir),     LSM_HOOK_INIT(inode_rmdir, selinux_inode_rmdir),     LSM_HOOK_INIT(inode_mknod, selinux_inode_mknod),     LSM_HOOK_INIT(inode_rename, selinux_inode_rename),     LSM_HOOK_INIT(inode_readlink, selinux_inode_readlink),     LSM_HOOK_INIT(inode_follow_link, selinux_inode_follow_link),     LSM_HOOK_INIT(inode_permission, selinux_inode_permission),     LSM_HOOK_INIT(inode_setattr, selinux_inode_setattr),     LSM_HOOK_INIT(inode_getattr, selinux_inode_getattr),     LSM_HOOK_INIT(inode_setxattr, selinux_inode_setxattr),     LSM_HOOK_INIT(inode_post_setxattr, selinux_inode_post_setxattr),     LSM_HOOK_INIT(inode_getxattr, selinux_inode_getxattr),     LSM_HOOK_INIT(inode_listxattr, selinux_inode_listxattr),     LSM_HOOK_INIT(inode_removexattr, selinux_inode_removexattr),     LSM_HOOK_INIT(inode_set_acl, selinux_inode_set_acl),     LSM_HOOK_INIT(inode_get_acl, selinux_inode_get_acl),     LSM_HOOK_INIT(inode_remove_acl, selinux_inode_remove_acl),     LSM_HOOK_INIT(inode_getsecurity, selinux_inode_getsecurity),     LSM_HOOK_INIT(inode_setsecurity, selinux_inode_setsecurity),     LSM_HOOK_INIT(inode_listsecurity, selinux_inode_listsecurity),     LSM_HOOK_INIT(inode_getsecid, selinux_inode_getsecid),     LSM_HOOK_INIT(inode_copy_up, selinux_inode_copy_up),     LSM_HOOK_INIT(inode_copy_up_xattr, selinux_inode_copy_up_xattr),     LSM_HOOK_INIT(path_notify, selinux_path_notify),     LSM_HOOK_INIT(kernfs_init_security, selinux_kernfs_init_security),     LSM_HOOK_INIT(file_permission, selinux_file_permission),     LSM_HOOK_INIT(file_alloc_security, selinux_file_alloc_security),     LSM_HOOK_INIT(file_ioctl, selinux_file_ioctl),     LSM_HOOK_INIT(file_ioctl_compat, selinux_file_ioctl_compat),     LSM_HOOK_INIT(mmap_file, selinux_mmap_file),     LSM_HOOK_INIT(mmap_addr, selinux_mmap_addr),     LSM_HOOK_INIT(file_mprotect, selinux_file_mprotect),     LSM_HOOK_INIT(file_lock, selinux_file_lock),     LSM_HOOK_INIT(file_fcntl, selinux_file_fcntl),     LSM_HOOK_INIT(file_set_fowner, selinux_file_set_fowner),     LSM_HOOK_INIT(file_send_sigiotask, selinux_file_send_sigiotask),     LSM_HOOK_INIT(file_receive, selinux_file_receive),     LSM_HOOK_INIT(file_open, selinux_file_open),     LSM_HOOK_INIT(task_alloc, selinux_task_alloc),     LSM_HOOK_INIT(cred_prepare, selinux_cred_prepare),     LSM_HOOK_INIT(cred_transfer, selinux_cred_transfer),     LSM_HOOK_INIT(cred_getsecid, selinux_cred_getsecid),     LSM_HOOK_INIT(kernel_act_as, selinux_kernel_act_as),     LSM_HOOK_INIT(kernel_create_files_as, selinux_kernel_create_files_as),     LSM_HOOK_INIT(kernel_module_request, selinux_kernel_module_request),     LSM_HOOK_INIT(kernel_load_data, selinux_kernel_load_data),     LSM_HOOK_INIT(kernel_read_file, selinux_kernel_read_file),     LSM_HOOK_INIT(task_setpgid, selinux_task_setpgid),     LSM_HOOK_INIT(task_getpgid, selinux_task_getpgid),     LSM_HOOK_INIT(task_getsid, selinux_task_getsid),     LSM_HOOK_INIT(current_getsecid_subj, selinux_current_getsecid_subj),     LSM_HOOK_INIT(task_getsecid_obj, selinux_task_getsecid_obj),     LSM_HOOK_INIT(task_setnice, selinux_task_setnice),     LSM_HOOK_INIT(task_setioprio, selinux_task_setioprio),     LSM_HOOK_INIT(task_getioprio, selinux_task_getioprio),     LSM_HOOK_INIT(task_prlimit, selinux_task_prlimit),     LSM_HOOK_INIT(task_setrlimit, selinux_task_setrlimit),     LSM_HOOK_INIT(task_setscheduler, selinux_task_setscheduler),     LSM_HOOK_INIT(task_getscheduler, selinux_task_getscheduler),     LSM_HOOK_INIT(task_movememory, selinux_task_movememory),     LSM_HOOK_INIT(task_kill, selinux_task_kill),     LSM_HOOK_INIT(task_to_inode, selinux_task_to_inode),     LSM_HOOK_INIT(userns_create, selinux_userns_create),     LSM_HOOK_INIT(ipc_permission, selinux_ipc_permission),     LSM_HOOK_INIT(ipc_getsecid, selinux_ipc_getsecid),     LSM_HOOK_INIT(msg_queue_associate, selinux_msg_queue_associate),     LSM_HOOK_INIT(msg_queue_msgctl, selinux_msg_queue_msgctl),     LSM_HOOK_INIT(msg_queue_msgsnd, selinux_msg_queue_msgsnd),     LSM_HOOK_INIT(msg_queue_msgrcv, selinux_msg_queue_msgrcv),     LSM_HOOK_INIT(shm_associate, selinux_shm_associate),     LSM_HOOK_INIT(shm_shmctl, selinux_shm_shmctl),     LSM_HOOK_INIT(shm_shmat, selinux_shm_shmat),     LSM_HOOK_INIT(sem_associate, selinux_sem_associate),     LSM_HOOK_INIT(sem_semctl, selinux_sem_semctl),     LSM_HOOK_INIT(sem_semop, selinux_sem_semop),     LSM_HOOK_INIT(d_instantiate, selinux_d_instantiate),     LSM_HOOK_INIT(getselfattr, selinux_getselfattr),     LSM_HOOK_INIT(setselfattr, selinux_setselfattr),     LSM_HOOK_INIT(getprocattr, selinux_getprocattr),     LSM_HOOK_INIT(setprocattr, selinux_setprocattr),     LSM_HOOK_INIT(ismaclabel, selinux_ismaclabel),     LSM_HOOK_INIT(secctx_to_secid, selinux_secctx_to_secid),     LSM_HOOK_INIT(release_secctx, selinux_release_secctx),     LSM_HOOK_INIT(inode_invalidate_secctx, selinux_inode_invalidate_secctx),     LSM_HOOK_INIT(inode_notifysecctx, selinux_inode_notifysecctx),     LSM_HOOK_INIT(inode_setsecctx, selinux_inode_setsecctx),     LSM_HOOK_INIT(unix_stream_connect, selinux_socket_unix_stream_connect),     LSM_HOOK_INIT(unix_may_send, selinux_socket_unix_may_send),     LSM_HOOK_INIT(socket_create, selinux_socket_create),     LSM_HOOK_INIT(socket_post_create, selinux_socket_post_create),     LSM_HOOK_INIT(socket_socketpair, selinux_socket_socketpair),     LSM_HOOK_INIT(socket_bind, selinux_socket_bind),     LSM_HOOK_INIT(socket_connect, selinux_socket_connect),     LSM_HOOK_INIT(socket_listen, selinux_socket_listen),     LSM_HOOK_INIT(socket_accept, selinux_socket_accept),     LSM_HOOK_INIT(socket_sendmsg, selinux_socket_sendmsg),     LSM_HOOK_INIT(socket_recvmsg, selinux_socket_recvmsg),     LSM_HOOK_INIT(socket_getsockname, selinux_socket_getsockname),     LSM_HOOK_INIT(socket_getpeername, selinux_socket_getpeername),     LSM_HOOK_INIT(socket_getsockopt, selinux_socket_getsockopt),     LSM_HOOK_INIT(socket_setsockopt, selinux_socket_setsockopt),     LSM_HOOK_INIT(socket_shutdown, selinux_socket_shutdown),     LSM_HOOK_INIT(socket_sock_rcv_skb, selinux_socket_sock_rcv_skb),     LSM_HOOK_INIT(socket_getpeersec_stream,             selinux_socket_getpeersec_stream),     LSM_HOOK_INIT(socket_getpeersec_dgram, selinux_socket_getpeersec_dgram),     LSM_HOOK_INIT(sk_free_security, selinux_sk_free_security),     LSM_HOOK_INIT(sk_clone_security, selinux_sk_clone_security),     LSM_HOOK_INIT(sk_getsecid, selinux_sk_getsecid),     LSM_HOOK_INIT(sock_graft, selinux_sock_graft),     LSM_HOOK_INIT(sctp_assoc_request, selinux_sctp_assoc_request),     LSM_HOOK_INIT(sctp_sk_clone, selinux_sctp_sk_clone),     LSM_HOOK_INIT(sctp_bind_connect, selinux_sctp_bind_connect),     LSM_HOOK_INIT(sctp_assoc_established, selinux_sctp_assoc_established),     LSM_HOOK_INIT(mptcp_add_subflow, selinux_mptcp_add_subflow),     LSM_HOOK_INIT(inet_conn_request, selinux_inet_conn_request),     LSM_HOOK_INIT(inet_csk_clone, selinux_inet_csk_clone),     LSM_HOOK_INIT(inet_conn_established, selinux_inet_conn_established),     LSM_HOOK_INIT(secmark_relabel_packet, selinux_secmark_relabel_packet),     LSM_HOOK_INIT(secmark_refcount_inc, selinux_secmark_refcount_inc),     LSM_HOOK_INIT(secmark_refcount_dec, selinux_secmark_refcount_dec),     LSM_HOOK_INIT(req_classify_flow, selinux_req_classify_flow),     LSM_HOOK_INIT(tun_dev_free_security, selinux_tun_dev_free_security),     LSM_HOOK_INIT(tun_dev_create, selinux_tun_dev_create),     LSM_HOOK_INIT(tun_dev_attach_queue, selinux_tun_dev_attach_queue),     LSM_HOOK_INIT(tun_dev_attach, selinux_tun_dev_attach),     LSM_HOOK_INIT(tun_dev_open, selinux_tun_dev_open), #ifdef CONFIG_SECURITY_INFINIBAND     LSM_HOOK_INIT(ib_pkey_access, selinux_ib_pkey_access),     LSM_HOOK_INIT(ib_endport_manage_subnet,               selinux_ib_endport_manage_subnet),     LSM_HOOK_INIT(ib_free_security, selinux_ib_free_security), #endif #ifdef CONFIG_SECURITY_NETWORK_XFRM     LSM_HOOK_INIT(xfrm_policy_free_security, selinux_xfrm_policy_free),     LSM_HOOK_INIT(xfrm_policy_delete_security, selinux_xfrm_policy_delete),     LSM_HOOK_INIT(xfrm_state_free_security, selinux_xfrm_state_free),     LSM_HOOK_INIT(xfrm_state_delete_security, selinux_xfrm_state_delete),     LSM_HOOK_INIT(xfrm_policy_lookup, selinux_xfrm_policy_lookup),     LSM_HOOK_INIT(xfrm_state_pol_flow_match,             selinux_xfrm_state_pol_flow_match),     LSM_HOOK_INIT(xfrm_decode_session, selinux_xfrm_decode_session), #endif #ifdef CONFIG_KEYS     LSM_HOOK_INIT(key_free, selinux_key_free),     LSM_HOOK_INIT(key_permission, selinux_key_permission),     LSM_HOOK_INIT(key_getsecurity, selinux_key_getsecurity), #ifdef CONFIG_KEY_NOTIFICATIONS     LSM_HOOK_INIT(watch_key, selinux_watch_key), #endif #endif #ifdef CONFIG_AUDIT     LSM_HOOK_INIT(audit_rule_known, selinux_audit_rule_known),     LSM_HOOK_INIT(audit_rule_match, selinux_audit_rule_match),     LSM_HOOK_INIT(audit_rule_free, selinux_audit_rule_free), #endif #ifdef CONFIG_BPF_SYSCALL     LSM_HOOK_INIT(bpf, selinux_bpf),     LSM_HOOK_INIT(bpf_map, selinux_bpf_map),     LSM_HOOK_INIT(bpf_prog, selinux_bpf_prog),     LSM_HOOK_INIT(bpf_map_free_security, selinux_bpf_map_free),     LSM_HOOK_INIT(bpf_prog_free_security, selinux_bpf_prog_free), #endif #ifdef CONFIG_PERF_EVENTS     LSM_HOOK_INIT(perf_event_open, selinux_perf_event_open),     LSM_HOOK_INIT(perf_event_free, selinux_perf_event_free),     LSM_HOOK_INIT(perf_event_read, selinux_perf_event_read),     LSM_HOOK_INIT(perf_event_write, selinux_perf_event_write), #endif #ifdef CONFIG_IO_URING     LSM_HOOK_INIT(uring_override_creds, selinux_uring_override_creds),     LSM_HOOK_INIT(uring_sqpoll, selinux_uring_sqpoll),     LSM_HOOK_INIT(uring_cmd, selinux_uring_cmd), #endif     /*      * PUT "CLONING" (ACCESSING + ALLOCATING) HOOKS HERE      */     LSM_HOOK_INIT(fs_context_submount, selinux_fs_context_submount),     LSM_HOOK_INIT(fs_context_dup, selinux_fs_context_dup),     LSM_HOOK_INIT(fs_context_parse_param, selinux_fs_context_parse_param),     LSM_HOOK_INIT(sb_eat_lsm_opts, selinux_sb_eat_lsm_opts), #ifdef CONFIG_SECURITY_NETWORK_XFRM     LSM_HOOK_INIT(xfrm_policy_clone_security, selinux_xfrm_policy_clone), #endif     /*      * PUT "ALLOCATING" HOOKS HERE      */     LSM_HOOK_INIT(msg_msg_alloc_security, selinux_msg_msg_alloc_security),     LSM_HOOK_INIT(msg_queue_alloc_security,               selinux_msg_queue_alloc_security),     LSM_HOOK_INIT(shm_alloc_security, selinux_shm_alloc_security),     LSM_HOOK_INIT(sb_alloc_security, selinux_sb_alloc_security),     LSM_HOOK_INIT(inode_alloc_security, selinux_inode_alloc_security),     LSM_HOOK_INIT(sem_alloc_security, selinux_sem_alloc_security),     LSM_HOOK_INIT(secid_to_secctx, selinux_secid_to_secctx),     LSM_HOOK_INIT(inode_getsecctx, selinux_inode_getsecctx),     LSM_HOOK_INIT(sk_alloc_security, selinux_sk_alloc_security),     LSM_HOOK_INIT(tun_dev_alloc_security, selinux_tun_dev_alloc_security), #ifdef CONFIG_SECURITY_INFINIBAND     LSM_HOOK_INIT(ib_alloc_security, selinux_ib_alloc_security), #endif #ifdef CONFIG_SECURITY_NETWORK_XFRM     LSM_HOOK_INIT(xfrm_policy_alloc_security, selinux_xfrm_policy_alloc),     LSM_HOOK_INIT(xfrm_state_alloc, selinux_xfrm_state_alloc),     LSM_HOOK_INIT(xfrm_state_alloc_acquire,               selinux_xfrm_state_alloc_acquire), #endif #ifdef CONFIG_KEYS     LSM_HOOK_INIT(key_alloc, selinux_key_alloc), #endif #ifdef CONFIG_AUDIT     LSM_HOOK_INIT(audit_rule_init, selinux_audit_rule_init), #endif #ifdef CONFIG_BPF_SYSCALL     LSM_HOOK_INIT(bpf_map_alloc_security, selinux_bpf_map_alloc),     LSM_HOOK_INIT(bpf_prog_alloc_security, selinux_bpf_prog_alloc), #endif #ifdef CONFIG_PERF_EVENTS     LSM_HOOK_INIT(perf_event_alloc, selinux_perf_event_alloc), #endif };
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–1 +/–
	Сообщение от Аноним (162), 28-Мрт-24, 13:50
	> Так уж и быть,  опущу очередного васяна анонима Ты случайно гну линуксом не пользуешься? Слишком уж дегенеративные набросы от тебя В твоей портянке нет ни одного поля, запрещающего принятие запроса для обработчика ksmbd в составе ядра
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–2 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 13:07
	> И как SELinux поможет от дыры в _ядре_? Ну, как, атакующему придется аж отметериться - и взять стандартный эксплойт с отключкой этой пакости. Потратит аж на 2 минуты больше.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	56. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–4 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 13:30
	В Fedora нельзя отключить SELinux.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (2), 27-Мрт-24, 16:30
	> В Fedora нельзя отключить SELinux. Добившись выполнения кода на уровне ядра можно отключить что угодно.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–2 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 16:35
	Но с SELinux не получится добиться выполнения кода на уровне ядра.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (2), 27-Мрт-24, 16:38
	> Но с SELinux не получится добиться выполнения кода на уровне ядра. Почему? SELinux защищает исключительно user space, а ksmbd  работает в ядре, т.е. SELinux никак не помешает отправить ему пакет и добиться переполнения буфера в ядре.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 16:44
	Если я расскажу, вы не поверите. Установите в Boxes Fedora и убедитесь.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (2), 27-Мрт-24, 17:26
	> Если я расскажу, вы не поверите. Установите в Boxes Fedora и убедитесь. Похоже вы не понимайте, что добившись выполнения кода на уровне ядра, в полностью контролируйте SELinux.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 18:03
	Вы уже проверили?
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–1 +/–
	Сообщение от n00by (ok), 27-Мрт-24, 18:52
	>> В Fedora нельзя отключить SELinux. > Добившись выполнения кода на уровне ядра можно отключить что угодно. Не всё так просто, как кажется. Из этого тезиса прямо следует, что легитимный код ядра может отключить что угодно, включая посторонних. https://ru.wikipedia.org/wiki/Бой_в_памяти В ядре Windows эти бои шли годами с переменным успехом. Неуловимый Джо спокойно курил в сторонке, пока администраторы превентивно падали, подняв лапки, и учили тому остальных.
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	129. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от n00by (ok), 27-Мрт-24, 18:43
	> И как SELinux поможет от дыры в _ядре_? В общем случае, при проектировании подобных систем ставится целью свести к нулю возможности исполняющегося в системе вредоносного кода. Из этого вопроса следует сделать какой вывод? 1. SELinux не справляется с задачей. 2. Эксперт не понимает назначение. 3. ?
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	13. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от myster (ok), 27-Мрт-24, 12:04
	То что уже работает на сервере и разрешено правилами SELinux, тоже может отправить определенным образом пакет, чтобы заэкспойтить подобную уязвимость. Взламывают, как правило, ПО торчащее наружу, которому ты уже дал карт-бланш почти на любые действия в рамках его функционала.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	141. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (141), 27-Мрт-24, 21:13
	apparmor есть
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	146. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 21:51
	В Ubuntu он как раз и есть, но не защитил.
	Ответить | Правка | Наверх | Cообщить модератору

3. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–4 +/–
Сообщение от ryoken (ok), 27-Мрт-24, 11:48
>>>До этого присовение CVE мдя... Вот нутром чуял, что таскание вендотехнологий в ядро - зло. Ну и чтоб 2 раза не вставать... "РЕШЕТО!!!" :D
Ответить | Правка | Наверх | Cообщить модератору

	15. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–1 +/–
	Сообщение от iPony129412 (?), 27-Мрт-24, 12:06
	99.9% уязвимостей ядра - покерфейс тут Samsung криво-косо в режиме сро/аки горят реализовал протоколы MS - "вендотехнологий - зло"
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+5 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 13:12
	> тут Samsung криво-косо в режиме сро/аки горят реализовал протоколы MS - "вендотехнологий - зло" Конечно безопасная реалиазция smb без вулнов - это еще поискать, но перегруженый замордованый кодер с самсунговской галеры - таки насажал багов везде где мог. И даже не потому что плохой програмер или злодей. А потому что с 4 здоровыми проектами на 1 тушке без особой помощи от других так кто угодно зашьется. А в ядро это приняли чтобы совместынми усилиями, вот, разгрести за ними, ибо фича то нужная. Ну вот и разгребают.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+3 +/–
	Сообщение от User (??), 27-Мрт-24, 14:59
	Никто, кроме microsoft'а и, немного, samsung'а не виноват - а "технологическое отверстие"(ТМ) тысячаглаз за тысячулет многаждыуспешно заполняет - или я что-то не так перевел?
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 16:18
	Ну так это вопрос не к самсунгу и не к кодеру. А сообществу которое жадничает скинуться деньгами на зарплаты программерам. Хотя... у нас же ГКУ во все поля, а при коммунизме прогрмаммист денег должне получать немного, если вообще сможет выпросить в виде пожертвований.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	115. Скрыто модератором	–1 +/–
	Сообщение от glad_valakas (-), 27-Мрт-24, 17:12
	> ибо фича то нужная. ksmbd - нужная ????!!!111 очень сомневаюсь.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	159. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Sw00p aka Jerom (?), 28-Мрт-24, 08:56
	>кодер с самсунговской самсунг вообще-то на багах зарабатывает, это его источник дохода. И предзаказы принимает :)
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

4. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–11 +/–
Сообщение от 12yoexpert (ok), 27-Мрт-24, 11:48
с тех пор, как мелкомягкие популяризовали линукс (а до них - космонавт), случился наплыв непрофпригодных домохозяек, которые теперь засирают своими якобы CVE всё на свете
Ответить | Правка | Наверх | Cообщить модератору

	7. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–2 +/–
	Сообщение от iPony129412 (?), 27-Мрт-24, 11:56
	ты хотел написать про RedHat? так-то был линукс на локалхосте у студента - и никаких CVE
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+4 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 12:03
	Ну так пошел бы и показал как нужно писать код. А то ты только языком треплешь на форуме. > засирают своими якобы CVE всё на свете Тебе уже готовый эксплойт принесли, но ты все равно не доволен
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	17. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 12:06
	> с тех пор, как мелкомягкие популяризовали линукс (а до них - космонавт) Да ладно тебе! Диды овнокодили в ядро еще 20 лет назад! И это периодически выгребают до сих пор.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	21. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+2 +/–
	Сообщение от iPony129412 (?), 27-Мрт-24, 12:09
	Надо найти первую уязвимость в ядре и огласить виноватого Вот весь линукс испортил
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (142), 27-Мрт-24, 21:27
	Уверен, что это оказался бы Линус Наш Торвальдс. Просто в первых версиях ядра баги не искали. Искали, что на нем может запуститься.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Мухорчатый (?), 27-Мрт-24, 12:31
	А в жизни линуксойда случается хоть что-то, в чем не мелкомягкие виноваты?..
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	117. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+2 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 17:13
	> А в жизни линуксойда случается хоть что-то, в чем не мелкомягкие виноваты?.. Конечно! В системД виноват космонавт! В веланде шапка! А в 4% - бсдшники!
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (151), 28-Мрт-24, 07:21
	В Systemd виноват Поцтерринг... Э, снова Шапка и Мелкомягкие.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Слава Линуксу (?), 27-Мрт-24, 17:14
	Правильно! Надо отправить этот Линукс обратно в прошлое, когда им пользовались полтора человека и тогда заживём!
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	138. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от нах. (?), 27-Мрт-24, 20:09
	Я - за! (можно не в прошлое, а на марс куда-нибудь)
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (151), 28-Мрт-24, 07:26
	А обратно-обратно выбрать ему другую мировую линию развития, без systemd, Wayland, "и всё в /usr".
	Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

5. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+3 +/–
Сообщение от Аноним (5), 27-Мрт-24, 11:51
>Выявивший уязвимость исследователь безопасности разработал и опубликовал рабочий прототип эксплоита, применимый к ядрам Linux начиная с выпуска 3.15 и заканчивая 6.8-rc1. Появятся новые рутуемые и перешиваемые устройства?
Ответить | Правка | Наверх | Cообщить модератору

	18. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+6 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 12:08
	Тут главное чтобы рутовал ты, а не тебя) А то понапишут дыр в ядре, потом 100500 роутеров превращаются в ботнет.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (23), 27-Мрт-24, 12:24
	Ну так сначала рутануть, а потом — перешить/брикнуть (в зависимости от разблокируемости загрузчика, не знаю, как с этим) через dd.
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (151), 28-Мрт-24, 07:29
	Чаще таки ботнеты из роутеров появляются от банального admin:admin, оставленного по умолчанию.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

6. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+2 +/–
Сообщение от Аноним (-), 27-Мрт-24, 11:53
> Проблема вызвана двойным освобождением памяти (double-free) И как обычно дыряшечные проблемы! > в актуальных выпусках Debian и Ubuntu с ядрами Linux 5.14 - 6.6 Linux 5.14 - 30 авг. 2021 г Т.е. свои три+ года бекдор отработал)) > Уязвимость проявляется начиная с версии ядра Linux 3.15 Релиз - 8 June 2014. А они умеют играть в долгую. Бекдоры начали делать двухкомпонентными. И чск ни один из тыщщи глаз не заметил бажину за целых 10 лет!
Ответить | Правка | Наверх | Cообщить модератору

	14. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от сщта (?), 27-Мрт-24, 12:04
	10 лет назад носились с pie,чтоб рандомно было в памяти. Теперь это вот модно.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (121), 27-Мрт-24, 17:39
	Модно то, что безопасно: https://www.opennet.me/openforum/vsluhforumID3/129886.html#309
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–1 +/–
	Сообщение от Аноним (20), 27-Мрт-24, 12:08
	Бэкдоры надо полагать были заложены сознательными инженерами с совестью, наш респект борцам.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	45. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 13:01
	> наш респект борцам Борцам за зарплату от АНБ? Не, ну ребята конечно молодцы, но достойно ли это наших респектов?.. Хотя если бы АНБ приходилось платить за каждую дыру, сделанную си погромистом, то они бы давно уже разорились бы.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (20), 27-Мрт-24, 13:11
	За откаты АНБ работают индусы Майкрософт и Эпл, там никакой борьбы нет и всё на потоке. Тут борцы сражаются с корпорациями и их желанием всех посадить в клетку, к тому же, в отличие от уязвимостей проприетари, не эксплуатируется удалённо, так что совесть чиста. Всю историю его существования овнили линукс через netfilter, поэтому все, кому надо, найдут.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Пряник (?), 27-Мрт-24, 14:38
	Это всё из-за тебя! Ты должен был коммиты проверять!
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	32. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (32), 27-Мрт-24, 12:37
	10 лет - это ничего вообще-то.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	39. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (39), 27-Мрт-24, 12:43
	И за 10 лет никто ей не воспользовался.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от вася (??), 27-Мрт-24, 13:01
	Пользовались в течении 10 лет, просто никому не говорили. А сейчас внедрили новый бэкдор и старый оказался не нужен, вот его и "обнаружили"
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (32), 27-Мрт-24, 13:09
	Ну так ты не пользуешься ОС, написанной исключительно тобой, ты пользуешься чужим продуктом - ядром линукс нахаляву, какие могут быть претензии с твоей стороны?
	Ответить | Правка | Наверх | Cообщить модератору

	61. Скрыто модератором	+1 +/–
	Сообщение от Аноним (39), 27-Мрт-24, 13:48
	Кто пользовался? Пришельцы с Нибиру и они лично тебе об этом сообщили? Какую инфу через уязвимость выудил, надеюсь не ту что про госдолг?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

9. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
Сообщение от сщта (?), 27-Мрт-24, 11:57
cifs хоть в самом ядре больше нет,а также зря с айпитэбл слез на этот прогрессив.) Не сиделось чухану как олдам на том что норм работает...
Ответить | Правка | Наверх | Cообщить модератору

10. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–1 +/–
Сообщение от Аноним (10), 27-Мрт-24, 11:58
Снова nftables
Ответить | Правка | Наверх | Cообщить модератору

16. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
Сообщение от Аноним (20), 27-Мрт-24, 12:06
netfilter: bridge: replace physindev with physinif in nf_bridge_info     netfilter: nfnetlink_log: use proper helper for fetching physinif     netfilter: nf_queue: remove excess nf_bridge variable     netfilter: nf_tables: check if catch-all set element is active in next generation     netfilter: nf_tables: do not allow mismatch field size and set key length     netfilter: nf_tables: mark newset as dead on transaction abort     netfilter: nf_tables: reject invalid set policy     netfilter: nf_tables: reject NFT_SET_CONCAT with not field length description     netfilter: nf_tables: skip dead set elements in netlink dump     netfilter: nf_tables: validate chain type update if available     netfilter: nft_limit: do not ignore unsupported flags     netfilter: propagate net to nf_bridge_get_physindev в следующем обновлении было     netfilter: nf_tables: reject QUEUE/DROP verdict parameters     netfilter: nf_tables: restrict anonymous set and map names to 16 bytes     netfilter: nf_tables: validate NFPROTO_* family     netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain     netfilter: nft_limit: reject configurations that cause integer overflow а потом     netfilter: conntrack: correct window scaling with retransmitted SYN     netfilter: nf_log: replace BUG_ON by WARN_ON_ONCE when putting logger     netfilter: nf_tables: restrict tunnel object to NFPROTO_NETDEV     netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations и     netfilter: nft_compat: narrow down revision to unsigned 8-bits     netfilter: nft_compat: reject unused compat flag     netfilter: nft_compat: restrict match/target protocol to u16     netfilter: nft_ct: reject direction for ct id     netfilter: nft_set_pipapo: add helper to release pcpu scratch area     netfilter: nft_set_pipapo: remove scratch_aligned pointer     netfilter: nft_set_pipapo: store index in scratch maps     netfilter: nft_set_rbtree: skip end interval element from gc следом     netfilter: ipset: fix performance regression in swap operation     netfilter: ipset: Missing gc cancellations fixed а потом уже     netfilter: conntrack: check SCTP_CID_SHUTDOWN_ACK for vtag setting in sctp_new     netfilter: nf_tables: register hooks last when adding new chain/flowtable     netfilter: nf_tables: set dormant flag on hook register failure     netfilter: nf_tables: use kzalloc for hook allocation     netfilter: nft_flow_offload: release dst in case direct xmit path is used     netfilter: nft_flow_offload: reset dst in route object after setting up flow и теперь уже     netfilter: bridge: confirm multicast packets before passing them up the stack     netfilter: nf_tables: allow NFPROTO_INET in nft_(match/target)_validate() ну и конечно     netfilter: nf_tables: do not compare internal table flags on updates     netfilter: nf_tables: Fix a memory leak in nf_tables_updchain     netfilter: nft_set_pipapo: release elements in clone only from destroy path и это получается всё бэкпортировано в 6.6 и не было сделано раньше
Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–2 +/–
Сообщение от Аноним (19), 27-Мрт-24, 12:08
как хорошо, что на моем диване ведро 5.10
Ответить | Правка | Наверх | Cообщить модератору

	35. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (32), 27-Мрт-24, 12:39
	https://www.opennet.me/opennews/art.shtml?num=50434 смешно
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (66), 27-Мрт-24, 14:11
	ну не у всех же всё хорошо с чувством юмора как у тебя
	Ответить | Правка | Наверх | Cообщить модератору

	67. Скрыто модератором	+/–
	Сообщение от Аноним (32), 27-Мрт-24, 14:15
	Ну так мне смешно, что разрабы девуана - клоуны как минимум, глупо им доверять, а тем более хвастаться диваном.
	Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+2 +/–
Сообщение от Аноним (-), 27-Мрт-24, 12:21
1. CVE-2024-1086 - double-free и поднять свои привилегии в системе. 2. CVE-2024-26592 - выполнения своего кода с правами ядра; вызвана состоянием гонки 3. CVE-2023-52440 - переполнение буфера из-за отсутствия должной проверки размера данных 4,5,6. CVE-2024-26594, CVE-2023-52442 и CVE-2023-52441 возвращение данных из области за границей буфера, отсутствие проверки входных данных, отсутствие необходимой проверки входных данных при обработке запросов SMB2. Из всей кучи дыр, можно только 2 отнести к логическим (и то если дать скидку на качество кода ядра). Остальные это "просто какой-то позор". Тебе пришли данные, ну проверь их размеры /_-
Ответить | Правка | Наверх | Cообщить модератору

	29. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (39), 27-Мрт-24, 12:35
	У тебя комплексы или что? Какая разница что там за уязвимости? Если надо тебя всё равно взломают.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 13:03
	"У тебя комплексы или что? Какая разница что там за замки? Если надо тебя всё равно взломают." Поэтому просто выкинь все замки и защелки с дверей, окна тоже можно не закрывать. Всем расскажи какой у тебя номер банковской карты, пин и циферки на обороте! Ключи от тачки можно хранить прямо в бардачке, а еще лучше вешать на зеркало заднего вида. Откуда в такие вообще беретесь /_-
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+2 +/–
	Сообщение от Аноним (39), 27-Мрт-24, 13:46
	Не очевидно что твоя замена понятий эквивалента. Попробуй ещё раз. В твоих замках тоже уязвимостей выше крыши и даже в окне. Поплач что твоё окно небезопасно. При том что даже к переписанной на р_ст двери отмычка подбирается за минуту. Ор с тебя выше гор.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 15:50
	>Не очевидно что твоя замена понятий эквивалента. Попробуй ещё раз. Зато очевидно, что ты не очень умный. Советую почитать побольше книжек. Ты сам пишешь > Какая разница что там за уязвимости? Если надо тебя всё равно взломают. Так что теперь их не фиксить? Или не обновлять ядро на новое? Или просто продолжать овнокодить, не добавлять проверок входных данных и лезть за границы буфера? Фигли, все равно взломают! Ты это имеешь в виду? > При том что даже к переписанной на р_ст двери отмычка подбирается за минуту. Пруфы, Билли! Тут нужны пруфы. А без них это просто пердеж в лужу. > Ор с тебя выше гор. Не удивительно, что такой недалекий как ты, все сводит к ору) А лучше бы почитал "как писать на дыряшке и не делать тупых ошибок"
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 27-Мрт-24, 14:46
	Ты не понимаешь. Если на С писать правильно и со всеми проверками, он станет медленнее раста, в котором эти проверки вшиты и хорошо оптимизируются компилятором. А скорость сишки это последний бастион, за который цепляются деды.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	150. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (150), 28-Мрт-24, 06:20
	>Если на С писать правильно и со всеми проверками, он станет медленнее раста, в котором эти проверки вшиты и хорошо оптимизируются компилятором. ага, проверит размер поступивших токенов SMB2 Mech прям во время компиляции, и другие о%y№тельные истории от растаманов, о которых невозможно молчать. А если проверяет это в рантайме прям во время компиляции, лол, то зачем эти проверки кроме того что вшиты еще и оптимизируются компилятором? :-D
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 29-Мрт-24, 23:32
	> проверит размер токенов SMB2 Mech Вот тут ты прав, токены не проверит, а вот надо бы! Сишникам надо под каждую CVE новую версию компилятора выпускать, а то у них с первого раза не получается фиксить. А уж про всякие буферы и освобождение и говорить не приходится - для матёрого сишника это как насморк - лечить не надо, само пройдет. > в рантайме ... во время компиляции Непонятно, то ли ты только школу закончил, то ли на старости лет таблетки забыл выпить. > эти проверки кроме того что вшиты еще и оптимизируются компилятором? Даже не знаю что тебе посоветовать в такой тяжёлой ситуации. Ну почитай что-нибудь базовое, "компиляторы для домохозяек" например. Там не сложно, даже для школьников!
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (150), 30-Мрт-24, 03:19
	>> проверит размер токенов SMB2 Mech > Вот тут ты прав, токены не проверит, а вот надо бы! тогда придётся подождать пока сиплюсплюсники запилят вам AILLVM. > Сишникам надо под каждую CVE новую версию компилятора выпускать, а то у > них с первого раза не получается фиксить. > А уж про всякие буферы и освобождение и говорить не приходится - > для матёрого сишника это как насморк - лечить не надо, само > пройдет. столько слов ниочем. :-D >> в рантайме ... во время компиляции > Непонятно, то ли ты только школу закончил, то ли на старости лет > таблетки забыл выпить. столько слов ниочем. >> эти проверки кроме того что вшиты еще и оптимизируются компилятором? > Даже не знаю что тебе посоветовать в такой тяжёлой ситуации. Ну почитай > что-нибудь базовое, "компиляторы для домохозяек" например. Там не сложно, даже для > школьников! столько слов ниочем. Ну вот скажи, и стоило так рвать дупу если нечего ответить?
	Ответить | Правка | Наверх | Cообщить модератору

24. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
Сообщение от Аноним (24), 27-Мрт-24, 12:24
Вопрос к экспертам русского языка. Вот это: > Уязвимости в ядре Linux, позволяющие поднять свои привилегии через nf_tables и ksmbd для меня звучит как уязвимости, которым нужно/задействуют _одновременно _ "nf_tables и ksmbd". Будет ли более правильным написать: "Уязвимости в ядре Linux, позволяющие поднять свои привилегии через nf_tables или ksmbd" ?
Ответить | Правка | Наверх | Cообщить модератору

	26. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (19), 27-Мрт-24, 12:31
	лучше "по желанию поднять" Например, мне лень и я не буду поднимать, а кому-то может не лень...
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–2 +/–
	Сообщение от Аноним (20), 27-Мрт-24, 12:34
	Нет, "и" вполне корректно, "или" выдаёт неносителя.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	43. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (24), 27-Мрт-24, 13:00
	Родился русским, у русских родителей, живу в России всю жизнь, но хочется написать "или".
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 16:57
	Ну, страна большая, куча национальностей и местного колорита. Меня например забавляло как акают москвичи, а их как говорил мой коллега с кубани. А ведь есть еще кавказ, и восток, республика саха и тд. Ну и солевые со своими поребриками, гречей и парадным)) На язык стандарт вроде есть, но на него все забивают... Что-то мне это напоминает :D
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (39), 27-Мрт-24, 12:38
	Почему или, а не "а так же ksmbd". Но даже с "и" смысл понятен.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	132. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от n00by (ok), 27-Мрт-24, 19:12
	"Уязвимости в модулях ядра nf_tables и ksmbd позволяют получить неограниченные права." Одновременно оба надо эксплуатировать или раздельно - не важно; кому это действительно надо, тот сам разберётся.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

27. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
Сообщение от Аноним (27), 27-Мрт-24, 12:33
> Исправление уязвимости предложено в выпуске ядра Linux 6.8-rc1 Это когда дерево упало и отключило электричество у Линуса и релиз 6.8-rc1 задержался. Т.е. они тихой цаплей думали как исправить дыры? Вот интересно, с прошлого релиза в linux-stable прошло 2 недели. Сейчас разом выкатили по всем веткам. Но 502 мешает затянуть изменения. Что в этот раз?
Ответить | Правка | Наверх | Cообщить модератору

	36. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от ryoken (ok), 27-Мрт-24, 12:39
	>>тихой цаплей Хорошее выражение :).
	Ответить | Правка | Наверх | Cообщить модератору

30. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+4 +/–
Сообщение от Аноним (32), 27-Мрт-24, 12:36
Не понимаю недовольства. Можно подумать, опеннетные эксперты в состоянии написать аналогичное ПО без уязвимостей.
Ответить | Правка | Наверх | Cообщить модератору

	37. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (39), 27-Мрт-24, 12:41
	Нет софта, нет уязвимостей. Так языком можно самое безопасное ПО делать. Только будет готово оно в следующем квартале. И так каждый квартал.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (44), 27-Мрт-24, 13:01
	Надо только подождать, затяните пояса.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Sw00p aka Jerom (?), 28-Мрт-24, 09:48
	>Так языком можно самое безопасное ПО делать. перед тем как даже языком делать, надо еще умом пошевелить немного, или вы сторонник "сначала сделаем, потом подумаем"? Если у вас нет механизмов верификации, о чем речь? Промолчу про, где эталон.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	160. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Sw00p aka Jerom (?), 28-Мрт-24, 09:44
	экспертные системы ничего не исполняют и тем более не реализуют, они дают оценки исполнителям и реализациям!
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

40. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+2 +/–
Сообщение от Аноним (40), 27-Мрт-24, 12:51
https://www.opennet.me/opennews/art.shtml?num=60436 double-free : Умные указатели помогли бы.
Ответить | Правка | Наверх | Cообщить модератору

	57. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+2 +/–
	Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 13:39
	Чем дольше живу, тем более странным мне кажется отказ от использования С++ в ядре. Я не знаю, что там было, когда всё это начиналось. Вполне возможно, что существовали веские причины. Но сейчас, по крайней мере с технической точки зрения, всё это выглядит, мягко говоря, глупо. С++ позволяет многое делать в разы проще (для программиста). При этом, там где нужно написать что-то в условном С стиле - никаких проблем. Опять же есть ассемблерные вставки. Но вместо С++ зачем-то начали пихать Rust. Который якобы позволяет избегать ошибок с памятью. Хотя С++ позволяет делать ровно тоже самое, при правильном использовании. Одновременно оставляя возможность работать на более "низком уровне". Причём, с Rust ещё и лицензионные заморочки могу возникнуть, насколько я понимаю.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+2 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 13:45
	> Я не знаю, что там было, когда всё это начиналось. Вполне возможно, что существовали веские причины. А поискал бы лучше. Там был убогий "си с классами". Который никаких плюсов (бадумтц) не давал, но добавлял нехилый оверхед в те темные времена первопней. > Хотя С++ позволяет делать ровно тоже самое, ... Нет, нельзя. С++ лучше по memory management чем си, но до раста ему топать и топать. В плюсах то что раст рассчитывает во время компиляции переносится в рантайм, а то что раст проверяет в рантайме в плюсах и так там живет. > ... при правильном использовании. А это вторая (или может быть даже первая?) проблема. Ты можешь использовать плюсы неправильно... и тебе за это ничего не будет. Ну может ворнинг вылезет.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 14:09
	> А поискал бы лучше. Там был убогий "си с классами". Потому и написал - я не знаю. Да и какая, по большому счёту разница, что там было. Важно то, что имеем сегодня. > В плюсах то что раст рассчитывает во время компиляции переносится в рантайм, > а то что раст проверяет в рантайме в плюсах и так > там живет. Ну во-первых, лично мне например и нужно, чтобы это было в рантайме, т.е. под моим, как программиста, контролем. Во-вторых, по итогу всё преобразуется в одни и те же машинные инструкции. При этом в случае с Rust - это дольше в разы, а выигрыш весьма сомнительный. В том плане, что его позиционируют, как более безопасный. Но на поверку - это лишь маркетинговая уловка. Потому что можно или самому код соответствующим образом писать, или добавить дополнительный модуль к компилятору того же С++, с ровно теми же функциями. Сделав при этом его опциональным. Однако вместо этого видим пропихивание Rust. С его мутными лицензионными ограничениями. Не говоря уж о том, что для того же С++ существуют международные стандарты. Которые до некоторой степени гарантируют, что программа будет вести себя +/- одинаково при использовании разных компиляторов. Или при компиляции для разных архитектур. > А это вторая (или может быть даже первая?) проблема. > Ты можешь использовать плюсы неправильно... и тебе за это ничего не будет. > Ну может ворнинг вылезет. Ну так это проблема не языка, а квалификации программистов. И тут вариантов на самом деле нет - или вы учите людей нормально работать, а также создаёте нормальные условия работы, или они вам всё равно устроят "весёлую жизнь". Как вы их не ограничивайте. Всё это уже было, не один раз.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+3 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 14:27
	> Важно то, что имеем сегодня. А сегодня мы имеем монстроспеку на 2к+ страниц)) > лично мне например и нужно, чтобы это было в рантайме, т.е. под моим, как программиста, контролем И жрет лишние время проца и оперативу. > При этом в случае с Rust - это дольше в разы, а выигрыш весьма сомнительный. Выигрыш как раз в том, что компиляешь ты один раз, а запускаешь софт - на порядки чаще. > Но на поверку - это лишь маркетинговая уловка. Голословное утверждение без пруфов которое подается как факт. Всё как я и люблю на опеннете)) > или добавить дополнительный модуль к компилятору того же С++, с ровно теми же функциями Но таких модулей еще нет. Вот когда появятся, тогда и поговорим. > Сделав при этом его опциональным И все будут его отключать потому что "а чаво оно ругается!" > С его мутными лицензионными ограничениями. Пруфы в студию. Уже второй раз пишешь про это. > программа будет вести себя +/- одинаково при использовании разных компиляторов Ахаха)) Ваши +/- это +/- километр. А потом люди спрашивают в интернетах "почему один и тот же код посла gcc и clang выдает различный результат" А потому что стандарт овно. "для того же С++ существуют международные стандарты" - и что, помогли они тебе?)) А у раста один компилятор. Который гарантировано будет работать как... как он сам. Круто же?)) > Ну так это проблема не языка, а квалификации программистов. Это проблема языка. Если язык, при некой степени сложности программы, начинает требовать от мясного мешка больше внимания к деталям, чем тот может позволить - то этот язык неприменим как надежный инструмент. С сишкой именно так и происходить. Писать хеллоуворды на нем легко и приятно. Но как только софт усложняется, то погромисты не в состоянии контролировать происходящее. И лучших ты не найдешь, потому что их не существует. Поэтому получается то что описано в этой новости. И решения тут условно два - или упрощать софт (что малореально), или автоматизировать валидации.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–1 +/–
	Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 15:21
	> А сегодня мы имеем монстроспеку на 2к+ страниц)) И что? Если хотите, чтобы всё было просто - добро пожаловать в каменный век. От там было всё просто. И никаких компьютеров. Правда, и медицины например тоже. И с едой было всё интересно - она внезапно могла люлей отвесить. А то и самого едока скушать. Если не устраивает - значит учитесь и читайте. > И жрет лишние время проца и оперативу. А при использовании Rust не жрёт? Машинные инструкции в конечном итоге одни и те же. А то, что можно проверить при компиляции, и так проверяется. > Выигрыш как раз в том, что компиляешь ты один раз, а запускаешь > софт - на порядки чаще. Простите, но это глупость. Потому что, как уже написал выше - машинные инструкции везде одни и те же. А более сложные проверки не спасут ни от чего - всегда можно написать такой код, который с точки зрения автоматической проверки будет абсолютно верным, но при этом сотворит вам не пойми что. > Голословное утверждение без пруфов которое подается как факт. > Всё как я и люблю на опеннете)) Эм... Ну ладно)) "Гляжу в книгу - вижу фигу". Точнее то, что удобно. "Умные" указатели, вектора и тип std::array с их итераторами - нет не оно? Ну ладно.     > Но таких модулей еще нет. Вот когда появятся, тогда и поговорим. Их не "ещё" нет, а их просто нет. За ненадобностью. Были бы нужны - давно бы уже написали. > И все будут его отключать потому что "а чаво оно ругается!" Ну так это опять же проблемы не языка программирования, а квалификации программистов. > Пруфы в студию. Уже второй раз пишешь про это. Потому и пишу, что мне вот непонятно, чего от меня захотят в будущем. А С и С++ - как бы всё кристально ясно. > Ахаха)) Ваши +/- это +/- километр. > А потом люди спрашивают в интернетах "почему один и тот же код > посла gcc и clang выдает различный результат" А "пруфы" (пользуясь вашей же терминологией) будут?)) Впрочем, можете не приводить. И так понятно, что в 99% случаев использовали специфичные для компилятора вещи, а потом оказалось, сюрприз - они для другого компилятора не работают. > А потому что стандарт овно. Откровенный бред. Стандарты как раз нормальные (по крайней мере те, что я видел). Весь вопрос в реализации. > "для того же С++ существуют международные стандарты" - и что, помогли они > тебе?)) Ещё как, вы не поверите. Поэтому кое-какие мои программы например работают как под Linux, так и под Windows. > А у раста один компилятор. Который гарантировано будет работать как... как он > сам. Круто же?)) Ложь. Для Rust уже больше одного компилятора. > Это проблема языка. > Если язык, при некой степени сложности программы, начинает требовать от мясного мешка > больше внимания к деталям, чем тот может позволить - то этот > язык неприменим как надежный инструмент. > С сишкой именно так и происходить. Писать хеллоуворды на нем легко и > приятно. > Но как только софт усложняется, то погромисты не в состоянии контролировать происходящее. И снова чушь. Всё можно, было бы желание. Тем более, что любая автоматическая проверка тоже написана людьми. А значит в ней в свою очередь могут быть ошибки. Или например альтернативный взгляд на "прекрасное". Т.е. полагаться на неё нельзя. > И решения тут условно два - или упрощать софт (что малореально), или > автоматизировать валидации. Нет. Потому что всегда можно написать код, который с точки зрения автоматической валидации будет абсолютно корректным, а по факту сотворит не пойми что.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 16:17
	> Если хотите, чтобы всё было просто - добро пожаловать в каменный век. Не передергивайте. Мы сравниваем потенциальные плюсы и минусы замены сишки на один из двух языков. Мы как раз не хотим попасть в каменный век из-за одного залетевшего дятла. > А при использовании Rust не жрёт? Машинные инструкции в конечном итоге одни и те же. Нет, инструкции разные. Просто чтобы добиться эквивалентного кода в с++ вы напр. должны присвоить переменной null  после освобождения памяти, чтобы потом не сделать double free. А в расте эту проверку сделает компилятор, который гарантирует что вы не сделаете double free. И присваивание не потребуется. И так еще в куче мест. > как уже написал выше - машинные инструкции везде одни и те же. То что вы так написали выше совсем не значит что инструкции одни и те же)) > "Умные" указатели это рантайм сущность. В расте они тоже есть. Но вам ничего не мешает в с++ читать и писать с любого потока просто в переменную. Ну будет пару рейсов, делов-то. А раст это не позволит - будет ошибка компиляции, где вам прозрачно намекнут что "или ты ошибся, или используй соответствующие примитивы синхронизации" > Впрочем, можете не приводить. Ну чего же вы так! Мне не сложно привести примеры)) codeproject.com/Questions/5331052/Cplusplus-different-output-on-different-compilers learn.microsoft.com/en-us/answers/questions/119430/different-results-in-different-compilers-c stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code qna.habr.com/q/1320980 ru.stackoverflow.com/questions/1508112/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82-%D1%80%D0%B0%D0%B7%D0%BD%D1%8B%D0%B9-%D0%BF%D1%80%D0%B8-%D0%BE%D0%B4%D0%B8%D0%BD%D0%B0%D0%BA%D0%BE%D0%B2%D1%8B%D1%85-%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%B0%D1%85-%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0-%D0%A1 и тыщщи их А всё потому, что в распрекрасный стандарт с++ напихали undefined behaviour и implementation defined behaviour. Что гарантировано стреляет на лобой маломальски большой программе. Кроме того, погромисту нужно учить не только стандарт, но и все безумные реализации конкретных компиляторов. Вот поэтому стандарт плохой. > Для Rust уже больше одного компилятора. Насколько я знаю - нет. gccrs только разрабатывают и он еще не релизился. mrustc еще не релизился и это не generic compiler, а просто чтобы бустрапит раста. Ferrocene просто надстройка для rustc. > Всё можно, было бы желание. Значит у сишников нет желания?)) > любая автоматическая проверка тоже написана людьми. Да, но проверка будет занимать напр. 1000 строк кода. И проверять сотни тысяч строк с одинаковым качеством. А теперь посади погромиста вычитывать 100к сорцов. Посмеемся))
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–1 +/–
	Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 17:13
	> Не передергивайте. Мы сравниваем потенциальные плюсы и минусы замены сишки на один > из двух языков. > Мы как раз не хотим попасть в каменный век из-за одного залетевшего > дятла. Так не я передёргиваю, а вы. Речь шла о том, что в С++ большой объём документации. Или я вас неправильно понял? Тогда - поясняйте, что имеете ввиду. > Нет, инструкции разные. Интересно, каким образом. Или я чего-то не знаю о работе процессоров?)) > Просто чтобы добиться эквивалентного кода в с++ вы напр. > должны присвоить переменной null  после освобождения памяти, чтобы потом не > сделать double free. Зачем? Я просто ничего не буду присваивать. Совершенно сознательно. И, затем, совершенно сознательно не сделаю double free. Как раз сэкономив те самые такты процессора. Что на компиляции, что во время исполнения. > То что вы так написали выше совсем не значит что инструкции одни > и те же)) Ну т.е. один и тот же процессор способен выполнять... непредусмотренные изначально инструкции? О_о > это рантайм сущность. В расте они тоже есть. > Но вам ничего не мешает в с++ читать и писать с любого > потока просто в переменную. > Ну будет пару рейсов, делов-то. > А раст это не позволит - будет ошибка компиляции, где вам прозрачно > намекнут что "или ты ошибся, или используй соответствующие примитивы синхронизации" Ну и? Где нужно, я совершенно сознательно использую std::atomic или std::mutex и иже с ними. При этом опять же совершенно сознательно, где нужно (а бывает и такое), для ускорения работы не буду использовать примитивы синхронизации. Зачем мне лишние проблемы с слишком "умным" компилятором и лишние нагромождения скомпилированных инструкций? > Ну чего же вы так! Мне не сложно привести примеры)) > codeproject.com/Questions/5331052/Cplusplus-different-output-on-different-compilers > learn.microsoft.com/en-us/answers/questions/119430/different-results-in-different-compilers-c > stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code > qna.habr.com/q/1320980 > ru.stackoverflow.com/questions/1508112/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82-%D1%80%D0%B0%D0%B7%D0%BD%D1%8B%D0%B9-%D0%BF%D1%80%D0%B8-%D0%BE%D0%B4%D0%B8%D0%BD%D0%B0%D0%BA%D0%BE%D0%B2%D1%8B%D1%85-%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%B0%D1%85-%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0-%D0%A1 > и тыщщи их По вашей ссылке - пустота. > А всё потому, что в распрекрасный стандарт с++ напихали undefined behaviour и > implementation defined behaviour. Что-то я их там особо не видел, за исключением тех случаев, когда речь идёт о работе того, что напрямую завязано на особенности железа. Это раз. А два - собственно, в чём проблема то? Ну раз поведение не определено, значит нужно действовать по-другому. У меня за плечами уже не одна сотня тысяч строк кода на С++, и что-то каких-то особых проблем с этим я не видел. Т.е. - это очередная маркетинговая уловка, не более того. > Насколько я знаю - нет. > gccrs только разрабатывают и он еще не релизился. > mrustc еще не релизился и это не generic compiler, а просто чтобы > бустрапит раста. > Ferrocene просто надстройка для rustc. Ну... Я под Rust не писал и не собираюсь, так что вам виднее. Но gccrs на сколько я знаю, может и не готов для "повседневного" использования, но в принципе уже рабочий. > Значит у сишников нет желания?)) Именно так. Любой ЯП - это просто инструмент. Как вы его используете, зависит полностью от вас. И речь опять таки изначально шла не про С, а про С++ - просьба не менять тему. > Да, но проверка будет занимать напр. 1000 строк кода. И проверять сотни > тысяч строк с одинаковым качеством. > А теперь посади погромиста вычитывать 100к сорцов. Посмеемся)) А чего смеяться то? Можно и не вычитывать, а запустить и посмотреть - где валится. И работать уже по месту. Тем более, что тестировать всё равно надо, независимо от ЯП. Или вы валите всё в релиз без тестирования?))
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 17:47
	> в С++ большой Стандарт. Плюс он написан так, что часть вещей просто UB, часть отдана на откуп реализатором компиляторов. Это всё нужно держать в голове при написании даже самого просто кода. И на это тратится время и внимание (которое тоже ресурс) программиста. > И, затем, совершенно сознательно не сделаю double free. О, как самоуверенно. Ну или у нас тут человек, который не совершает ошибок. Или кто-то что-то недоговаривает. > Ну т.е. один и тот же процессор способен выполнять... непредусмотренные изначально инструкции Вы ушли куда-то далеко. Мы говорим про инструкции самой программы. Что у вас для гарантии должна быть проверка на null, и если вы ее добавляете, то она будет в результирующем бинарнике. А в расте при тех же гарантиях проверка не нужна. А если вы на проверку забьете - то это ваше дело. > При этом опять же совершенно сознательно, где нужно (а бывает и такое), для ускорения работы не буду использовать примитивы синхронизации. А как вы гарантируете что к этой переменной не будет обращения с другого потока? Дайте угадаю - вы просто все продумали и пришли к выводу что эта ситуация невозможна? (т.е. по факту "мамой клянусь!") Но тут есть ваш коллега, у которого другое мнение на этот счет)) А потом Сaptain "That should never happen" strikes! Again... и у нас очередная уязвимость из-за гонки. > может и не готов для "повседневного" использования, но в принципе уже рабочий. Это немного не так. Но раз вы не в контексте, то нет смысла это обсуждать. Когда они его допилят, тогда вернемся к этой теме. > По вашей ссылке - пустота. По всем четырем?? Надо же. Вот тогда вам еще одна stackoverflow.com/questions/71010294/different-results-between-clang-gcc-and-msvc-for-templated-constructor-in-base-c Результат работы msvc отличается от gcc и clang. Получается вы берете рабочий код, компилируете под другую платформу и он начинает работать неправильно. Странно что вы не видите в этом проблемы. > У меня за плечами уже не одна сотня тысяч строк кода на С++ Вы же понимаете, что личный опыт так себе аргумент. >  И речь опять таки изначально шла не про С, а про С++ - просьба не менять тему. Да, простите. С++ники тоже не сделали такой инструмент. Может потому что им нравится делать, а потом исправлять уязвимости (мозила и хром передают). А может потому что они не видят в этом проблемы. А может задача слишком сложная с теми вольностями что позволяют плюсы. Кто знает. > а запустить и посмотреть - где валится. И работать уже по месту. А валится оно где попало и в рандомных местах. Потому что память в этот момент уже испортил кто-то другой просто выйдя за границы буфера. И какую именно память он попортит в след. раз никто угадать не может. А еще это повторяется отнюдь не всегда. Ну удачи, расчехляйте санитайзеры. Несмотря на то что сейчас я не с++ программист, мне доводилось исправлять такие баги. И больше не хочется))
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 19:18
	> Стандарт. Плюс он написан так, что часть вещей просто UB, часть отдана > на откуп реализатором компиляторов. > Это всё нужно держать в голове при написании даже самого просто кода. А это бывает как-то по-другому?)) Оно UB не просто так, а потому что где-то напрямую зависит от работы конкретного процессора, а где-то - реально без разницы, как оно там внутри устроено, лишь бы результат был нужный. Если же конечный результат не соответствует ожиданиям - то это уже проблема конкретной реализации, а не стандарта. Т.е., иными словами - баг, или просто недоработка. > И на это тратится время и внимание (которое тоже ресурс) программиста. Программист для того и существует, чтобы тратить своё время именно на такие вещи. > О, как самоуверенно. > Ну или у нас тут человек, который не совершает ошибок. > Или кто-то что-то недоговаривает. Всё куда проще. Я в своё время тоже напрыгался с подобными вещами. А потом просто выработал для себя несколько простых правил, которые позволяют подобных ошибок избегать. В частности например, "пишешь delete - дважды проверь, что именно". Пока что работает. Иными словами, смысла в Rust нет никакого на мой взгляд, потому что всё, что преподносится, как его преимущество, в С++ достигается применением определённого стиля программирования. При этом всегда остаётся возможность поступить как-то иначе, если вдруг в этом возникнет необходимость. > Вы ушли куда-то далеко. Мы говорим про инструкции самой программы. А какая собственно разница, что там в инструкциях программы? Меня интересует, сколько и на что будет потрачено тактов процессора. Всё. Остальное - значения не имеет никакого. > А как вы гарантируете что к этой переменной не будет обращения с > другого потока? > Дайте угадаю - вы просто все продумали и пришли к выводу что > эта ситуация невозможна? (т.е. по факту "мамой клянусь!") Нет, на такие вещи я не полагаюсь никогда. А вот на знание, как именно работает моя программа - да, полагаюсь. И не просто так, а протестировав предварительно все возможные варианты. > А потом Сaptain "That should never happen" strikes! Again... > и у нас очередная уязвимость из-за гонки. Не знаю, возможно я что-то делаю не так, но мне ещё ни разу не удалось вызвать состояние гонки. Если только специально к этому не стремился)) Понятно, что всё бывает впервые. Ну так и в Rust наверняка повылазит много приколов когда (если) его начнут массово применять. Хотя лично я очень надеюсь, что до этого не дойдёт)) Иначе говоря, не существует никакой гарантии, кроме той, что дают ваши опыт и квалификация. Независимо от ЯП. Не ошибётесь в указателях или в синхронизации потоков - ошибётесь в другом месте. > По всем четырем?? Надо же. > Вот тогда вам еще одна stackoverflow.com/questions/71010294/different-results-between-clang-gcc-and-msvc-for-templated-constructor-in-base-c Насчёт трёх - не разглядел, извините. Вы бы их хоть как-то разделили что ли. По существу же вопроса - ответ в последней вашей ссылке. Там собственно сказано, что описанное поведение - это баг MSVC. Который вроде бы даже исправили уже. Т.е. тут вопрос не к стандарту, а к его реализации, как и говорил. Остальное мне разбирать лень - наверняка там будет тоже самое. > Вы же понимаете, что личный опыт так себе аргумент. Да, понимаю. Но вы сознательно упускаете остальную часть моего ответа, а она немного меняет смысл сказанного. В частности, я говорил, что если вы видите UB, то ничто вам не мешает его обойти. Т.е. это совершенно не аргумент. Более того, свободность стандартов в части конкретных реализаций - это скорее плюс, чем минус. Потому что позволяет из нескольких выбрать наилучшую с точки зрения поставленных задач.   >>  И речь опять таки изначально шла не про С, а про С++ - просьба не менять тему. > Да, простите. С++ники тоже не сделали такой инструмент. > Может потому что им нравится делать, а потом исправлять уязвимости (мозила и > хром передают). > А может потому что они не видят в этом проблемы. > А может задача слишком сложная с теми вольностями что позволяют плюсы. > Кто знает. Я думаю - из-за "они не видят в этом проблемы". Потому что это действительно так. Как уже неоднократно написал - вопрос в квалификации программистов, а не в ЯП. > А валится оно где попало и в рандомных местах. Потому что память > в этот момент уже испортил кто-то другой просто выйдя за границы > буфера. И какую именно память он попортит в след. раз никто > угадать не может. А еще это повторяется отнюдь не всегда. > Ну удачи, расчехляйте санитайзеры. > Несмотря на то что сейчас я не с++ программист, мне доводилось исправлять > такие баги. И больше не хочется)) Мне тоже доводилось. Грамотное применение дебагера чаще всего помогает)) Ну и для избежания дальнейшего непонимания - резюмирую свою позицию. Rust - это по факту чуть более высокий вид абстракции, что на мой взгляд не нужно совершенно. В ядре я имею ввиду (с чего собственно весь разговор начался). Для прикладных задач - да пожалуйста, пользуйтесь сколько угодно. Это ваше личное дело. Если получится что-то годное - лично я только за. Для себя же лично особого смысла в нём не вижу - меня не напрягает внимательно проверять свои delete (за пределы массива в С++ выйти - это ещё постараться надо). Напрягает же что Rust пихают усиленно везде, где только можно и нельзя, хотя  на поверку все его расписываемые достоинства оказываются не такими уж и достоинствами. Потому что всё это легко достигается в других ЯП просто применением соответствующего стиля программирования. А вот недостатки вполне просматриваются - например отсутствие стандартизации или явно бОльшее количество инструкций как на этапе компиляции, так и на этапе исполнения. Пропихивание же говорит, что это кому-то надо. Зачем? Ну... Мы сегодня живём при капитализме. Пропихивают, значит кто-то увидел свой личный денежный интерес (на самом деле там чётко понятно, кто, что и зачем, но достоверных данных у меня нет, искать - лень, поэтому будем считать это моими домыслами). Если бы это было хоть как-то оправдано с технической точки зрения - я бы ещё понял. Но в нынешнем виде - извините, но нет.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 23:59
	Ворвусь как я в тред, если никто не против) > Если же конечный результат не соответствует ожиданиям - то это уже проблема конкретной реализации, а не стандарта. Т.е., иными словами - баг, или просто недоработка. Можно ли считать, что "согласно стандарту C++ порядок вычисления аргументов функции не специфицирован" это баг, или просто недоработка? Я беру одинаковый код, но на разных компиляторах я получаю разный результат. Можно ли говорить о корректности кода и "стандартизованности" стандарта. > Программист для того и существует, чтобы тратить своё время именно на такие вещи. Но такие вещи как автоматизация позволяет тратить эти вещи на сложные задачи и не тратить на рутинные. Например автотесты или санитайзеры упрощают жизнь, ускоряют разработку и уменьшают шанс ошибится. > Всё куда проще. Я в своё время тоже напрыгался с подобными вещами. > А потом просто выработал для себя несколько простых правил, которые позволяют подобных ошибок избегать. В частности например, "пишешь delete - дважды проверь, что именно". Пока что работает. Судя по всему, у вас очень большой опыт разработки. Но, к сожалению вас нельзя клонировать, скопировать и тд. А для производства больших проектов нужны сотни таких как вы. > Иными словами, смысла в Rust нет никакого на мой взгляд, потому что всё, что преподносится, как его преимущество, в С++ достигается применением определённого стиля программирования. Да, но для этого нужно очень большая дисциплина (что в опенсорсном проекте вообще редкость). Я видел как люди уходили из открытых проектов просто по причине "я не хочу ждать пока на пулл реквесте пробегут автотесты! я же профи, ты что не доверяешь мне?!" > При этом всегда остаётся возможность поступить как-то иначе, если вдруг в этом возникнет необходимость. Как и в расте. Магическое слово unsafe открывает дверь в волшебный мир "делаю что хочу") > А какая собственно разница, что там в инструкциях программы? Меня интересует, сколько и на что будет потрачено тактов процессора. Всё. Остальное - значения не имеет никакого. Ну, меня тут еще интересуют другие вещи: среднее время работы до критичной ошибки, как быстро в коде разберется новый человек и тд. Возможно это связано с тем что я работал в больших проектах с немаленькими командами. > Нет, на такие вещи я не полагаюсь никогда. А вот на знание, как именно работает моя программа - да, полагаюсь. И не просто так, а протестировав предварительно все возможные варианты. Предположу, что в некоторых проектах это работает. Особенно если весь код написал сам. А в некоторых нет. Т.к ты можешь делать свой модуль, а в это время еще десять человек пилят пяток других. И ты их код увидешь или на код ревью, или когда полезешь там что-то исправлять. > В частности, я говорил, что если вы видите UB, то ничто вам не мешает его обойти. Гораздо хуже, когда программист не видит UB) Т.к запомнить все особенности всех компиляторов. Можно конечно говорить "нам нужны люди с 20 годами опыта, вот тогда и приходите", но работает это плохо. > Ну и для избежания дальнейшего непонимания - резюмирую свою позицию. Rust - это по факту чуть более высокий вид абстракции, что на мой взгляд не нужно совершенно. В ядре я имею ввиду (с чего  собственно весь разговор начался). Но к сожалению в ядре у нас, не современный С++, с умными указателями и прочими благами цивилизации, а С11, причем на него они перешли только ЕМНИП в 22году. > Для прикладных задач - да пожалуйста, пользуйтесь сколько угодно. Это ваше личное дело. Если получится что-то годное - лично я только за. К сожалению он для совсем прикладных приложение не очень подходит, тк UI на нем писать непросто. > Напрягает же что Rust пихают усиленно везде, где только можно и нельзя Люди всегда мечтают от серебрянной пуле, даже если она немного ржавая) > хотя  на поверку все его расписываемые достоинства оказываются не такими уж и достоинствами. Потому что всё это легко достигается в других ЯП просто применением соответствующего стиля программирования. ... для чего нужно воспитать целые поколения программистов, заставить их следовать стилю и надеяться что стиль подойдет под задачу. > А вот недостатки вполне просматриваются - например отсутствие стандартизации или явно бОльшее количество инструкций как на этапе компиляции, так и на этапе исполнения. По стравнению с ASM любые языки высокого уровня генерировали "лишние" инструкции. Но на них почему-то перешли. Особенно если время компиляции стоит N денег, а 10 часов поиска EXC_BAD_ACCESS стоят M денег, и при этом N < M. > Пропихивание же говорит, что это кому-то надо. Зачем? Ну... Мы сегодня живём при капитализме. Пропихивают, значит кто-то увидел свой личный денежный интерес Напомню что СИ был разработан как потомок языка Би (который разработали AT&T, корпорация кстати) и был сделан в лаборатории Bell Labs (тоже корпорация) для абсолютно денежного интереса. И в этом (для меня) нет ничего плохого. Ада писалась по заказу Министерства обороны США. И плохим это ее не сделает А раст для меня похож на токарник с ЧПУ, он умеет часть вещей делать автоматически, но если нужно - можно управлять им в ручном режиме. И сейчас программист - это почти как слесарь или инжинер в 70-80 (куча народу работает над ) На дороге человек тоже может ехать аккуратно, но ему зачем-то вешают знаки, светофоры и даже ставят отбойники. А техника безопасности, например электрики (которая ПУЭ) вообще написана кровью. Так что я за вещи, которые позволят сделать код надежнее.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от n00by (ok), 28-Мрт-24, 08:04
	> Ворвусь как я в тред, если никто не против) >> Если же конечный результат не соответствует ожиданиям - то это уже проблема конкретной реализации, а не стандарта. Т.е., иными словами - баг, или просто недоработка. > Можно ли считать, что "согласно стандарту C++ порядок вычисления аргументов функции не > специфицирован" это баг, или просто недоработка? Тут не считать, а понимать надо, от чего именно так сделано. Понимать, что такое ABI и конвенции вызовов. Иметь представление, что на одном процессоре аргументы передаются через стек, в таком случае естественный порядок вычисления оказывается - справа налево. В другой архитектуре аргументы передаются через регистры процессора, при этом при вызове функций одни регистры сохраняются, а другие нет; здесь с порядком возникают неоднозначности. Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно. А кто не знает, что такое конвенция вызовов - тому в ядре делать вообще-то и нечего. Сотня таких разнесут проект к чертям.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 28-Мрт-24, 12:43
	> Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно. А вот и нет. Всё звучит логично если бы не маааленький нюанс: Eval order в стандарте undefined behavior только до C++17. https://en.cppreference.com/w/cpp/language/eval_order А потом ВНЕЗАПНО это поведение стандартизировали! Как же так получилось, что все предыдущие версии оно жило как UB, а потом вдруг это смогли пофиксить? Может это таки проблема в стандарте, а фича?)
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от n00by (ok), 28-Мрт-24, 14:03
	>> Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно. > А вот и нет. > Всё звучит логично если бы не маааленький нюанс: Eval order в стандарте > undefined behavior только до C++17. > https://en.cppreference.com/w/cpp/language/eval_order > А потом ВНЕЗАПНО это поведение стандартизировали! Где стандартизировали и что? Мне по этой ссылке самому надо искать? "The initialization of a parameter ... is indeterminately sequenced" ISO/IEC JTC1 SC22 WG21 N 4860 7.6.1.2 Function call 1 A function call is a postfix expression followed by parentheses ... ... 8 The postfix-expression is sequenced before each expression in the expression-list and any default argument. The initialization of a parameter, including every associated value computation and side effect, is indeterminately sequenced with respect to that of any other parameter. [Note: All side effects of argument evaluations are sequenced before the function is entered (see 6.9.1). — end note] > Как же так получилось, что все предыдущие версии оно жило как UB, > а потом вдруг это смогли пофиксить? > Может это таки проблема в стандарте, а фича?) Что "оно"? Сначала я посмотрел последний черновик стандарта, потом написал комментарий #158. Мне пора качать новый черновик?
	Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

	166. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 28-Мрт-24, 12:53
	> Тут не считать, а понимать надо, от чего именно так сделано. Понимание мне никак не поможет в случае "а в этом компиляторе разработчики захотели выпендрится" Придется читать доку на каждую версию каждого компилятора в надежде, что в мире есть хоть где-то стабильность. > Понимать, что такое ABI и конвенции вызовов. Иметь представление, что ... здесь с порядком возникают неоднозначности. > Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно. Я об этом в курсе, но в примере с которого все началось, человек запускает один и тот же код, на одной машине с одним процессором. (stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code) И получает разный результат. Потому что создатели компилятор решили сделать по разному. Это говорит о том, что для того чтобы программа работала предсказуемо, нужно фиксировать тип компилятора и даже его версию. А ситуация "вот вам код, найдите именно GCC и версию компилятора 7.1.5 тк оно гарантировано работает только на нем" это просто дрмовая ситуация. Но вполне укладывается в Stable is nonsense идеологию. > А кто не знает, что такое конвенция вызовов - тому в ядре делать вообще-то и нечего. Сотня таких разнесут проект к чертям. И кто тогда будет писать ядро? Будем делать экзамен на проф пригодность? Попросим корпов нанимать только самых лучших, а что если они скажут 'неа, нам лучшие нужны себе'? А других программеров у тебя просто нет)
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от n00by (ok), 28-Мрт-24, 14:26
	>> Тут не считать, а понимать надо, от чего именно так сделано. > Понимание мне никак не поможет в случае "а в этом компиляторе разработчики > захотели выпендрится" > Придется читать доку на каждую версию каждого компилятора в надежде, что в > мире есть хоть где-то стабильность. Ну вообще доку хорошо бы иногда читать. Но в данном случае это зачем? Полагаться на поведение нельзя, значит принимаются другие меры. >> Понимать, что такое ABI и конвенции вызовов. Иметь представление, что ... здесь с порядком возникают неоднозначности. >> Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно. > Я об этом в курсе, но в примере с которого все началось, > человек запускает один и тот же код, на одной машине с > одним процессором. (stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code) > И получает разный результат. > Потому что создатели компилятор решили сделать по разному. Этот пример не имеет отношения к ядру. В ядре такое чудо не работает по нескольким другим причинам. > Это говорит о том, что для того чтобы программа работала предсказуемо, нужно > фиксировать тип компилятора и даже его версию. Это говорит о том, что происходит попытка натянуть сову на глобус. И если ProfessorNavigator никогда ничего не писал для ядра, он может растекаться водой по дереву в ответах, создавая ложное впечатление, что эта дискуссия имеет хоть какой-то смысл. > А ситуация "вот вам код, найдите именно GCC и версию компилятора 7.1.5 > тк оно гарантировано работает только на нем" это просто дрмовая ситуация. > Но вполне укладывается в Stable is nonsense идеологию. >> А кто не знает, что такое конвенция вызовов - тому в ядре делать вообще-то и нечего. Сотня таких разнесут проект к чертям. > И кто тогда будет писать ядро? Будем делать экзамен на проф пригодность? Этот вопрос к чему? Писать будут те, кого посчитают нужным принимающее решение. > Попросим корпов нанимать только самых лучших, а что если они скажут 'неа, > нам лучшие нужны себе'? > А других программеров у тебя просто нет) Софтскиллзами так и прёт.
	Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

	167. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от ProfessorNavigator (ok), 28-Мрт-24, 13:46
	> Ворвусь как я в тред, если никто не против) Площадка публичная, почему кто-то должен быть против?)) > Можно ли считать, что "согласно стандарту C++ порядок вычисления аргументов функции не > специфицирован" это баг, или просто недоработка? > Я беру одинаковый код, но на разных компиляторах я получаю разный результат. > Можно ли говорить о корректности кода и "стандартизованности" стандарта. Стандарт такой, какой он есть. Если он кому-то не нравится - нужно вносить предложения  по изменению (если таковой механизм доступен) или создавать альтернативу. "На разных компиляторах" в случае с С++ обычно выливается в "а на MSVC не так". Что как бы намекает, что проблема отнюдь не в стандарте... > Но такие вещи как автоматизация позволяет тратить эти вещи на сложные задачи > и не тратить на рутинные. > Например автотесты или санитайзеры упрощают жизнь, ускоряют разработку и уменьшают шанс > ошибится. Смотря что вы подразумеваете под автотестами. Если некие автоматические проверки кода - то нет, на самом деле не упрощают. Потому что всегда остаётся вероятность, что в соответствующем ПО тоже есть ошибки (и я их, кстати, достаточно регулярно вижу). Поэтому всей автоматикой допустимо пользоваться уже после того, как вы провели тестирование самой программы на все возможные варианты её использования. Если в процессе тестирования что-то сработало не так, как ожидалось. В противном случае - нет. В том числе и потому, что присутствует психологический фактор - вы сами не заметите, как всё больше начнёте полагаться на автоматику, т.е. постепенно начнёте терять квалификацию. Кроме того автоматика нормально работает только в стандартных случаях, а программист нужен в том числе для того, чтобы придумывать нестандартные решения. Иначе его можно заменить той же автоматикой (что в общем-то и наблюдаем). > Судя по всему, у вас очень большой опыт разработки. > Но, к сожалению вас нельзя клонировать, скопировать и тд. > А для производства больших проектов нужны сотни таких как вы. Не то чтобы прям большой, но кое-какой имеется. И не так уж много людей нужно на самом деле. У вас скорее всего такое впечатление сложилось из-за геймдева. Над играми действительно работает много народу, но далеко не все они - программисты. Большинство там всякие художники, сценаристы, дизайнеры, аниматоры и т.д. Когда пишется что-то прикладное, то там обычно много людей не нужно. Особенно, если им обеспечить нормальные условия труда и грамотно распределить задачи.   > Да, но для этого нужно очень большая дисциплина (что в опенсорсном проекте > вообще редкость). > Я видел как люди уходили из открытых проектов просто по причине "я > не хочу ждать пока на пулл реквесте пробегут автотесты! я же > профи, ты что не доверяешь мне?!" А без дисциплины - никуда. Окружающей реальности нет дела до наших проблем. Потому что она неживая. И действует по своим законам. Мы или можем ей противостоять, и под неё подстраиваться, либо умираем. Подобные проблемы на самом деле сегодня актуальны вообще во всех сферах человеческой деятельности. Просто потому, что мы подошли к условной кризисной точке в своём развитии. И либо мы изменим своё отношение буквально ко всему, либо вымрем. C'est la vie. > Как и в расте. > Магическое слово unsafe открывает дверь в волшебный мир "делаю что хочу") Так зачем в таком случае плодить лишние сущности, если всё и так есть?)) Хотя в случае с Rust как раз понятно - зачем. Но, повторюсь, я не против него как такового - от появления ещё одного ЯП никому ни холодно, ни жарко. Нравится кому-то - пусть пользуются, это их личное дело. Я в данном случае против технически неоправданных решений, которые к тому же затрагивают большое количество людей по всему миру. И против попытки нажиться на общественном достоянии (Линукс уже им дефакто стал). > Ну, меня тут еще интересуют другие вещи: среднее время работы до критичной > ошибки, как быстро в коде разберется новый человек и тд. > Возможно это связано с тем что я работал в больших проектах с > немаленькими командами. Всё это вопросы организации рабочего процесса. Если вы усложняете программу только потому, что у вас люди не в состоянии работать с кодом, то это говорит о том, что вам лучше заняться чем-то другим, а не программированием. Или гнать организатора рабочего процесса в шею за полную профнепригодность. > Предположу, что в некоторых проектах это работает. Особенно если весь код написал > сам. > А в некоторых нет. Т.к ты можешь делать свой модуль, а в > это время еще десять человек пилят пяток других. > И ты их код увидешь или на код ревью, или когда полезешь > там что-то исправлять. Опять же - это вопрос организации рабочего процесса. Ну и инкапсуляцию придумали как раз вот для таких случаев. Если вы пишите некий отдельный модуль программы или библиотеки, то вам, как программисту, должны поставить чёткую задачу: на входе будут такие-то параметры, на выходе должен получиться такой-то результат. Дальше вы всё это реализуете полностью автономно. Если вам для написания модуля требуется видеть чужой код - это признак неправильной архитектуры программы или неграмотного руководства проектом. Или и того и другого сразу. > Гораздо хуже, когда программист не видит UB) > Т.к запомнить все особенности всех компиляторов. > Можно конечно говорить "нам нужны люди с 20 годами опыта, вот тогда > и приходите", но работает это плохо. Зачем вам запоминать всё? Документацию как раз и придумали на такие вот случаи. Не знаю, как и чему учили вас, нас же учили так: "Ты можешь чего-то не знать. Но где это можно найти - ты знать обязан". Правда я по образованию ни разу не программист)) Что, впрочем, не отменяет верность описанного выше принципа для любых ситуаций. > Но к сожалению в ядре у нас, не современный С++, с умными > указателями и прочими благами цивилизации, а С11, причем на него они > перешли только ЕМНИП в 22году. Да не вопрос - если посмотрите, с чего всё началось, то я о том и говорил в общем-то. Мне реально странно видеть, что в ядре Линукс не используют С++. На заре появления языка вполне возможно, что для этого были объективные причины. Но в текущих реаиях с технической точки зрения подобное решение выгляди неоправданным. Опять же - я могу чего-то не знать. Но всё, что я видел по этому поводу от непосредственных участников проекта, выглядит, как глупое упрямство. Причём, не обязательно ведь переписывать всё и сразу. С++ благодаря своим свойствам позволяет сделать процесс постепенным. > К сожалению он для совсем прикладных приложение не очень подходит, тк UI > на нем писать непросто. Вот собственно ещё один недостаток языка. Вполне объективный. > Люди всегда мечтают от серебрянной пуле, даже если она немного ржавая) Ну... Я об этом уже написал выше. Немного перефразирую сказанное - людям пора повзрослеть. И понять наконец, что магии не существует. Любые преимущества достигаются за счёт того, что в чём-то другом проседание. У всего есть свои преимущества и недостатки. Да, С/С++ позволяют допускать ошибки. Однако об этом известно (точнее - должно быть известно) любому, кто начинает с ними работать. И такое поведение необходимо учитывать. Но взамен мы получаем существенное снижение нагрузки на процессор и память как в процессе компиляции, так и в процессе работы программы. А также очень гибкий инструмент, позволяющий делать буквально всё, что угодно практически на любом оборудовании. И это главное. Недостатки Rust тут уже обсуждали, и не раз, поэтому повторяться не буду. Суть в том, что его применение с технической точки зрения - неоправданно. А все проблемы, которые он якобы решает, могут быть устранены уже имеющимися средствами, причём без особых на то усилий - достаточно лишь понимать, что происходит, и иметь желание сделать всё правильно. > ... для чего нужно воспитать целые поколения программистов, заставить их следовать стилю > и надеяться что стиль подойдет под задачу. Заставить кого-то делать что-то невозможно в принципе. Можно лишь чётко и внятно объяснить человеку, почему нужно поступать так или иначе. Чтобы он сам захотел делать вещи правильно. Или убить. Собственно именно поэтому я тут словоблудием и занимаюсь - до второго варианта доводить не хотелось бы)) Надеяться тоже ни на что не нужно. Нужно решать поставленную задачу в рамках имеющихся средств. Предварительно выработав общий план работ. > По стравнению с ASM любые языки высокого уровня генерировали "лишние" инструкции. > Но на них почему-то перешли. Особенно если время компиляции стоит N денег, > а 10 часов поиска EXC_BAD_ACCESS стоят M денег, и при этом > N < M. Всё очень просто. Ассемблеров больше одного - они индивидуальны для каждой архитектуры процессоров. И в такой ситуации появление некой абстракции в виде языков более высокого уровня как раз вполне оправданно. Потому что позволяет разделить задачи: если делать всё по уму, то создатель процессора той или иной архитектуры должен вместе с ним выпустить спецификацию команд, а также компилятор для того или иного языка высокого уровня. Какого именно - тут опять же по уму нужно всем собраться и решить, что мы используем. Потому что любой ЯП высокого уровня - это просто текст, который преобразуется компилятором в команды. Компилятор можно настроить как угодно, поэтому здесь нужно смотреть на удобство и лаконичность именно текста. На мой взгляд С++ - в данном случае вполне оптимальный вариант. Но это уже решать не  только мне. При этом спецификация всего этого дела должна быть полностью открытой, чтобы любой мог создать нечто своё - вдруг получится лучше? Но при этом решение об использовании нового ЯП, как стандарта, должно приниматься ВСЕМИ УЧАСТНИКАМИ ПРОЦЕССА. Как программистами, так и пользователями. Потому что это затронет всех. > Напомню что СИ был разработан как потомок языка Би (который разработали AT&T, > корпорация кстати) и был сделан в лаборатории Bell Labs (тоже корпорация) > для абсолютно денежного интереса. > И в этом (для меня) нет ничего плохого. > Ада писалась по заказу Министерства обороны США. И плохим это ее не > сделает Здесь нужно разбираться индивидуально по каждому случаю. Но при этом стоит учитывать несколько факторов. Первое - С/С++ стандартизированы на международном уровне, что сильно затрудняет любые попытки подмять всё это дело под себя для получения исключительно личной выгоды. Второе - для С/С++ существует открытый компилятор, который опять же с юридической точки зрения будет практически невозможно подмять под себя. О его качестве можно спорить, не суть, главное - он есть. Т.е. кому-либо будет достаточно сложно создать монополию. По крайней мере легально. Почему монополизация в условиях капитализма - это плохо, надеюсь, объяснять не нужно? > А раст для меня похож на токарник с ЧПУ, он умеет часть > вещей делать автоматически, но если нужно - можно управлять им в > ручном режиме. > И сейчас программист - это почти как слесарь или инжинер в 70-80 > (куча народу работает над ) > На дороге человек тоже может ехать аккуратно, но ему зачем-то вешают знаки, > светофоры и даже ставят отбойники. > А техника безопасности, например электрики (которая ПУЭ) вообще написана кровью. > Так что я за вещи, которые позволят сделать код надежнее. Надёжнее код может сделать только одно - повышение квалификации программистов. Никаких других путей для этого не существует.
	Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

	108. Скрыто модератором	+/–
	Сообщение от C00l_ni66a (ok), 27-Мрт-24, 16:47
	>А сегодня мы имеем монстроспеку на 2к+ страниц)) Ну да, не то, что в хрyсте... ой, а у него ведь вообще спеки нет, вот незадача! >И жрет лишние время проца и оперативу. А в р*cте будто не жрёт, ага. Волшебство, не иначе. >компиляешь ты один раз Дальше можно не читать. Уже и так ясно, что к разработке ты имеешь такое-же отношение, как cargo-культисты к инфобезу. >Вот когда появятся, тогда и поговорим. Вот когда в хрустяшке исправят 25860, протекающий унсейф контекст в сейф через лямбды и прочие "ньюансы" - тогда и поговорим. А пока что этот кривой кусок ржавчины для чего-то серьёзного не годится. >И все будут его отключать >>Голословное утверждение без пруфов которое подается как факт. >А потом люди спрашивают в интернетах "почему один и тот же код посла gcc и clang выдает различный результат" Потому что ЯП учить надо, а не раскидываться баззвордами. >А потому что стандарт овно. >>Голословное утверждение без пруфов >А у раста один компилятор. Именно. Один компилятор, от которого ты зависишь. И если разрабы вдруг решат, что им срочно нужна телеметрия или платное DLC, в которое вынесут борроучекер - то тебе придётся смиренно кушать, что дают. Это называется "вендорлок", если ты вдруг не знал. >Который гарантировано будет работать как... ...кусок кривой ржавчины, поддерживающий аж полторы архитектуры. Кстати, а RCE в кодовом анализаторе тебя не смущает? То самое, про которое все знают, но фиксить будут *потом*? >Если язык, при некой степени сложности программы, начинает требовать от мясного мешка больше внимания к деталям, чем тот может позволить >С сишкой именно так и происходить. >Но как только софт усложняется, то погромисты не в состоянии контролировать происходящее. >И лучших ты не найдешь, потому что их не существует. >>Голословное утверждение без пруфов
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	124. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 17:54
	> А пока что этот кривой кусок ржавчины для чего-то серьёзного не годится. Спасибо C00l_ni66a! Ты открыл нам всем глаза! Не забудь написать Торвальдсу что-то вроде "Товарищ Линус, произошла чудовищная ошибка!" А то красношапка уже не этом кривом куске начала дрова писать для невидии)) > Потому что ЯП учить надо, а не раскидываться баззвордами. Потому чтj стандарт должен быть стандартом, а не куском "нуянеуверенсамиразберетесь" овна. > И если разрабы вдруг решат, что им срочно нужна телеметрия или платное DLC Мда... сходи к наркологу, что ли.... > тебе придётся смиренно кушать, что дают. Компилятор открыт под свободной лицензией MIT. Форкаешь компилятор и вперед. > Это называется "вендорлок", если ты вдруг не знал. Вендерлок - это огороженные гнутые экстеншены в ядре линукса. Чтобы не дай бог кто-то не скомпилил ядро другим компилятором. > поддерживающий аж полторы архитектуры Все архитектуры, которые поддерживает llvm > То самое, про которое все знают, но фиксить будут *потом*? Не, не смущает. Пофиксим сразу после того как сишники и плюсовики все UB уберут.
	Ответить | Правка | Наверх | Cообщить модератору

	131. Скрыто модератором	+/–
	Сообщение от C00l_ni66a (ok), 27-Мрт-24, 19:10
	>Не забудь написать Торвальдсу На кой? Он уже давно заложник корпорастов и никому факи показывать не может. Это скорее контр-пример, потому что ярко демонстрирует, кто и как обычно пытается пропихнуть ржавое поделие и кто с этим соглашается. >А то красношапка уже не этом кривом куске начала дрова писать для невидии)) А ещё на нём хелловорлды отменные есть. Что меняет-то? Когда будет результат - будет и разговор, а пока что кроме агитаций к RIIR особо ничего и нету. >Потому чтj стандарт должен быть стандартом, а не ...инструкцией "как кaкaть" для самых маленьких. Ты либо конкретику вноси, либо прекращай газировать лужу. >Мда... сходи к наркологу, что ли.... Слив засчитан. >Форкаешь компилятор и вперед. Так вон, crab уже есть. Был, точнее, потому что всем стало всё равно на этот проект ещё до того, как хруст фундейшен пошёл на попятную. В том и дело, что одиночка или малая команда энтузиастов ничего не сможет противопоставить в прямом столкновении с корпорасами. В этом и суть вендорлока, *формально* ты можешь попытаться что-то сделать, но на практике ты не вывезешь, потому что у твоих конкурентов есть деньги, власть и неограниченное число кодеров, в отличии от. >Вендерлок - это огороженные гнутые экстеншены в ядре линукса. Съезд с темы засчитан. >Все архитектуры, которые поддерживает llvm Ложь, LLVM сам по себе тут не причём. Хотя, даже при этом, LLVM поддерживает действительно не так уж и много, в сравнении с тем-же GCC. >Пофиксим сразу после О чём и речь, "потом". Твои набросы про UB никого не волнуют, когда пруфы предоставишь (в том числе к тому, во что я ткнул ранее) - тогда и поговорим.
	Ответить | Правка | Наверх | Cообщить модератору

	134. Скрыто модератором	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 19:22
	> Это скорее контр-пример, потому что ярко демонстрирует, кто и как обычно пытается пропихнуть ржавое поделие и кто с этим соглашается. В фантазиях таких фанатиков-параноиков как ты)) > ...инструкцией "как кaкaть" для самых маленьких. Ты либо конкретику вноси, либо прекращай газировать лужу. Конкретику? Да хотя бы определитесь как должен вести себя signed overflow. > Слив засчитан. Я не собираюсь обсуждать твой бред. Пиши конструктив, а свои маняфантазии засунь себе... куда подальше в общем. > В этом и суть вендорлока, *формально* ты можешь попытаться что-то сделать, но > на практике ты не вывезешь, потому что у твоих конкурентов есть > деньги, власть и неограниченное число кодеров, в отличии от. GCC контролируется корпами чуть больше чем полностью: gcc.gnu.org/steering.html Там одни корпы - IBM, Red Hat, SUSE, Google,... Вот что ты сделаешь, если они сделают вышеперечисленный тобой бред в след. версии компилятора GCC? А ничего, ты точно также утрешься как и с компилятором раста. Поэтому прекрати гнать дичЪ про вендорлок. > Ложь, LLVM сам по себе тут не причём. Хотя, даже при этом, > LLVM поддерживает действительно не так уж и много, в сравнении с тем-же GCC. Вам нужно старые маргинальные и некроархитектуры, которые тянет GCC - ВОТ САМИ И ПИШИТЕ)) Нам не нужно, Линуксу тоже. > О чём и речь, "потом". Твои набросы про UB никого не волнуют Вот когда пофиксят, тогда и предоставлю)) Твои набросы на раст тем более никого не волнуют. Ты мне напоминаешь Скалнета, только в контексте раста. Ты ходишь в каждую тему, cpешь и ноешь. Но твое нытье не изменит НИЧЕГО. Раст УЖЕ в ядре. Уже написаны дрова для видяхи М1, уже пишутся дрова для нвидии. И дальше будет больше))
	Ответить | Правка | Наверх | Cообщить модератору

	139. Скрыто модератором	–1 +/–
	Сообщение от C00l_ni66a (ok), 27-Мрт-24, 20:25
	>В фантазиях таких фанатиков-параноиков как ты)) Фанатик называет меня фанатиком? Ультимативный уровень лицемерия, однако. Пруфов, впрочем, не будет. Как и в прошлый раз. Как и в позапрошлый раз. Ты вообще ни разу не подтвердил свои набросы пруфами, но фанатики, безусловно, это те, кто у тебя эти пруфы требует, конечно. >Конкретику? Да хотя бы определитесь как должен вести себя signed overflow. Слив засчитан. Мне определять ничего не надо, я к стандартизации С++ отношения не имею. >Я не собираюсь обсуждать твой бред. Пиши конструктив, а свои маняфантазии засунь себе... куда подальше в общем. Слабая стрелка. Маняфантазиями обмазываешь секцию комментариев тут только ты. Про фанатиков, про плохой стандарт, про плохой C и C++, съезды с темы всяческие, то на ядро, то на Линуса, и так далее. Ты тут обсуждаешь именно что *свой* бред, который ничем не подкреплён кроме твоих фантазий, а иногда и вовсе отношения к топику не имеет. >Вот что ты сделаешь, если они сделают вышеперечисленный тобой бред в след. версии компилятора GCC? Перейду на другой компилятор, очевидно. Но дело в том, что они не сделают, это не имеет смысла, когда есть конкуренты, к которым, в случае чего, перейдут юзеры и мейнтейнеры. >А ничего, ты точно также утрешься как и с компилятором раста. Ложь. Ситуация с компилятором раста как раз не проецируема на ситуацию с GCC, шлангом или чем-то ещё. Именно потому что C++ - это стандартизированный ЯП, имеющий разные имплементации, а не вендорлокнутый кусок ржавчины в единственном экземпляре. >Вам нужно >Нам не нужно Съезд засчитан. Про то, что мне нужно - речи не шло. Также как и не идёт речи, что нужно *тебе*. (А не абстрактным "вам", которых у тебя в палате вообще-то нету. Ты тут один.) Речь про конкретные, объективные достоинства и недостатки. И вторые в хрустяшке вполне себе перевешивают первые, особенно в сравнении с другими технологиями, но адепты продолжают отрицать. >ВОТ САМИ И ПИШИТЕ)) Вот сам и попробуй хоть строчку кода на своём любимом куске ржавчины написать. А то пока что твои утверждения типа "компилировать нужно лишь единожды, а значит скорость компиляции ниважна" ничего кроме испанского стыда не вызывают. >Вот когда пофиксят, тогда и предоставлю)) Так фундаментальные "неприятные моменты" в архитектуре ржавого вряд ли пофиксят, так что пруфов от тебя ждать точно не приходится, получается. >Твои набросы на раст тем более никого не волнуют. >Ты мне напоминаешь Скалнета, только в контексте раста. >Ты ходишь в каждую тему, cpешь и ноешь. Но твое нытье не изменит НИЧЕГО. Очередная ультимативная проекция. Тут только ты ходишь по комментариям и ноешь/набрасываешь про "дыpяшку", "пroклятых сишников", "плахой стандарт", "ужасный UB" и прочие штампы адептов. А я лишь подлавливаю тебя на лжи, маняпуляциях и пустом балабольстве, не более. >И дальше будет больше)) Больше балабольства и набросов от адептов? Ну, возможно. Но это всё пустое, тренды сменяются, а на рынке остаётся лишь то, что на практике доказало свою пригодность, изредка пугая легасятиной, которую вынуждены тянуть те, кто решил в своё время хайпануть на очередном выстрелившем смузи-поделии.
	Ответить | Правка | Наверх | Cообщить модератору

	143. Скрыто модератором	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 21:30
	> я к стандартизации С++ отношения не имею Да ты вообще ни к чему не имеешь отношения. И к ядру линукса тоже. > Тут только ты ходишь по комментариям и ноешь/набрасываешь про "дыpяшку" Напомню, что мы сейчас комментируем очередную новость про очередную дыряшечную CVE в ядре линукса с получением рута. Причем с рабочим прототипом эксплоита)) Потому что эти рукоопы дважды очистили память. Как и год назад. Как и два. Как и тридцать. Потому что дыряшечники как не умели в память, так и не умеют. Разве после такого вообще нужно набрасывать?? Но нет, конечно дыряшка не дыряшка, а погромисты не рукоопы! Это все набросы! И новость тоже врет! Боже, какой же ты клоун!)) >  А я лишь подлавливаю тебя на лжи, маняпуляциях и пустом балабольстве, не более. Пока что ты меня еще ни на чем не подловил. Так что старайся лучше)
	Ответить | Правка | Наверх | Cообщить модератору

	173. Скрыто модератором	+/–
	Сообщение от C00l_ni66a (ok), 29-Мрт-24, 15:04
	>И к ядру линукса тоже. Верно. Что в лишний раз подтверждает, что твои регулярные попытки съехать с темы на ведро - обоснованы чуть менее, чем никак, ведь разговор начинался с твоего наброса про ЯПы. >Напомню, что мы сейчас комментируем очередную новость про очередную дыряшечную CVE в ядре линукса с получением рута. Напомню, что сейчас я отвечаю на комментарии хрустоадепта, регулярно размазывающего софистику по секции комментариев на тему языков программирования и робуст сафети. Таким нехитрым образом, ты привёл контраргумент к своему-же доводу про то, что кто-то там "ходит в каждую тему" и "ноет", ведь получается, что не в каждую, а в вполне конкретную/-ые. Молодец, люблю, когда фанатики проявляют самостоятельность и сливают себя сами. >Потому что эти рукоопы дважды очистили память. >Как и год назад. Как и два. Как и тридцать. Фанатик открывает тайну мироздания о том, что людям свойственно допускать ошибки. Фото в цвете. >Потому что дыряшечники как не умели в память, так и не умеют. >>голословное утверждение без пруфов (и, вдобавок, маняпуляция, выдача частного за общее) >Разве после такого вообще нужно набрасывать?? Набрасывать вообще не нужно, но тебе это не мешает делать то под каждой новостью где хоть как-то упоминается си или хруст. >Но нет, конечно дыряшка не дыряшка, а погромисты не рукоопы! Конкретные погромисты мб и вполне себе рукопoпы. Если ты воспользуешься памятью или историей комментариев, то увидишь, что в прошлый раз я писал именно об этом, т.е. о том, что низкая квалификация конкретных лиц при использовании конкретной технологии - говорит в первую очередь об этих лицах, а не о технологии. Опять сам себя слил, подтвердив мой тезис, красава. >Это все набросы! То, что ты пишешь - однозначно набросы. >И новость тоже врет! И вот это - тоже наброс, софистики на вентилятор. >Боже, какой же ты клоун!)) Проекция. >Пока что ты меня еще ни на чем не подловил. Странно, почему-то история комментариев говорит об обратном. За стандарт ты не пояснил; кучу съездов с темы не обосновал; в теме UB и IDB до сих пор не разобрался, но в этом треде уже накинул; по топику вендорлока слился почти "всухую" (ну или "мокрую", если учитывать твоё измазывание); а на тычки в фактические, конкретные "неприятные моменты" в основной реализации хрустяшки - вообще ничего по существу не написал. И это всё не учитывая множество других, более мелких обосрамсов, маняпуляций, софистики и прочих набросов. Прочный у тебя манямиpoк, однако, впрочем, на реальность никак не влияющий.
	Ответить | Правка | Наверх | Cообщить модератору

	175. Скрыто модератором	+/–
	Сообщение от Аноним (-), 29-Мрт-24, 15:59
	> Фанатик открывает тайну мироздания о том, что людям свойственно допускать ошибки. Фото в цвете. О, какой жижкий обсер /_- Если Человек Разумный пользуется интрументом, который создан так что позволяет допускать ошибки, что он делает? Он его улучшает! Так появляются кожухи на болгарке, изоляция клещей которыми лезут в электрощиток, для профи всякие изолирующие коврики. Для станков добавляют датчики отключающие его, когда в опасную зону заходит человек, а у преса появляются 2 кнопки которые нужно нажать одновременно (именно одновременно), дабы твою руку не отрезало. Что делают упоротые фанатики? Они отказываются от прогреса и совершают одни и те же ошибки и года в год. > Набрасывать вообще не нужно, но тебе это не мешает делать то под каждой новостью где хоть как-то упоминается си или хруст. Но это же весело! Во-первых можно тыкать носом любителей дыряшки в каку которую они написали. Во-вторых иногда в комментах бывают нормальные обсуждения каких-то сложных материй (но чаще конечно срч и оскорбления) > Конкретные погромисты мб и вполне себе рукопoпы. Если ты воспользуешься памятью или историей комментариев, то увидишь, что в прошлый раз я писал именно об этом, т.е. о том, что низкая квалификация конкретных лиц при использовании конкретной технологии - говорит в первую очередь об этих лицах, а не о технологии. Опять сам себя слил, подтвердив мой тезис, красава. Неа, у нас разное определение "низкой квалификации". У тебя - те кто не могут писать без ошибок. А у меня - те кто не могут найти инструмаен позволяющий писать без ошибок. Возьми условного рабочего и дай ему какой-то инстумент, например перфоратор, у которого нет двойной изоляции, или бур может вылететь из крепления кому-то в голову, или шестеренки открыты - то скорее всего тебе скажут "что за х!" и "не буду этим овном пользоваться". И это определит его квалификацию. Но для дыряшечников - это достоинство, можно же столько раз засверлиться себе в ногу)) Я уже насмотрелся на таких которые "не вижу проблемы делать пескоструйку без сиз", а потом "что-то дышать тяжко" > Странно, почему-то история комментариев говорит об обратном. За стандарт ты не пояснил; кучу съездов с темы не обосновал; в теме UB и IDB до сих пор не разобрался, но в этом треде уже накинул; А разве это "стандарт", если один и тот же код может работать по разному? Ну ладно, так и быть буду называть это "стандартом" > по топику вендорлока слился почти "всухую" (ну или "мокрую", если учитывать твоё измазывание); Лол, ты просто наложил кучу типа "если они завендорлочат, то мы сами не сможем". Так раст для гцц пишут, пока не готов, но если вдруг закончал, то как ты тогда будешь извиваться? Посмотри сколько было успешных форков. Один только ХОрг чего стоит. > это всё не учитывая множество других, более мелких обосрамсов, маняпуляций, софистики и прочих набросов. Ты опять проецируешь? Может тебе лучше стоит пойти штанишки сменить? > Прочный у тебя манямиpoк, однако, впрочем, на реальность никак не влияющий. Полность согласен. У тебя полное отрицание и проблем дыряшки, и того факта, что Раст уже в ядре и дальше будет больше. Некоторые успешные опенсорс компании - например Гугл, новый код андроида стараются писать исключительно на расте. И делают поблажки только для совсем древник кодов. Возможно через лет десять новые кода в ядре будут только на расте. И тогда от сишников модно будет избавиться)
	Ответить | Правка | Наверх | Cообщить модератору

	176. Скрыто модератором	+/–
	Сообщение от C00l_ni66a (ok), 29-Мрт-24, 18:07
	>О, какой жижкий обсер /_- Снова проекция. >который создан так что позволяет допускать ошибки Инструмента, который *не позволяет* допускать ошибки - существовать не может, чисто концептуально. И в хрустящем """софте""" встречаются всё те-же выходы за границы массива, переполнение сигнедов (тебе ссылку уже кидали, ага), но так как хрустяшку позиционируют как мегасафети - её адепты расслабляются и могут не заметить, что из-за ужасного дизайна язычка там может *случайно* протечь унсейф контекст в сейф через лямбды, например. И да, напомню, что аналогия - это НЕ аргумент. >Он его улучшает! Да, логичным итогом улучшения сишки стал C++. Который, в отличии от куска ржавчины, именно что решает проблемы, а не предлагает БДСМ-пати под предлогом мнимой бищапащности. >Что делают упоротые фанатики? Они отказываются от прогреса и совершают одни и те же ошибки и года в год. Именно! Они отказываются принимать тот факт, что прогресс и его направление объективны, ввиду чего получают ржавую мазню, вместо вменяемых инструментов. >Во-первых можно тыкать носом любителей дыряшки в каку которую они написали. Не фантазируй, разработчики ведра вряд-ли сидят на опеннете. >Во-вторых иногда в комментах бывают нормальные обсуждения каких-то сложных материй Причём тут "нормальные обсуждения" к твоим шизонабросам? Тебе учебник логики посоветовать? >Неа, у нас разное определение "низкой квалификации". "Вас" тут нет, напоминаю, а вот у тебя вряд-ли вообще хоть какие-то определения есть. >инструмаен позволяющий писать без ошибок. Т.е. чисто воображаемая ересь? Держи в курсе. >А разве это "стандарт", если один и тот же код может работать по разному? Демагогию не разводи. Если вдруг забыл - иди перечитывай, либо приводи конкретные аргументы, а не в очередной раз газируй лужу. >Лол, ты просто наложил кучу Проекция. > "если они завендорлочат, то мы сами не сможем". Кто "мы" и с чего-бы? Фантазируешь. Аргументация была иная, перечитывай иди, демагог. >Так раст для гцц пишут, пока не готов >>пока не готов Вот когда будет готов - тогда и приходите. А я говорю про положение дел *сейчас*, а не когда-то там в будущем, которое легко может ещё и не наступить. >Посмотри сколько было успешных форков. Посмотри, сколько было успешных форков проектов, по размерам и комплексности сопоставимым с компилятором хруста. Опять маняпулируешь, уже не интересно. >Ты опять проецируешь? Если пытаться проецировать свою тягу к проекциям - от того твои высеры обоснованней не станут. Слабая стрелка, попробуй ещё раз. >Полность согласен. Тогда зачем ты его сюда публикуешь? Любишь золотой дождь? >У тебя полное отрицание Донная стрелка, не интересно. >проблем дыряшки Ты пока что ни разу не указал на "проблемы дыряшки", всё что ты тут намазал - это фантазёрство и баззворды про "ужасный UB" без толики конкретики. > того факта, что Раст уже в ядре Пруфай, что я это отрицал. >и дальше будет больше. Пруфай, что дальше будет "больше". (больше чего? Твоих набросов? Хотя, про это я уже писал выше) >Некоторые успешные опенсорс компании - например Гугл "Опенсорс-компания" это только в пределах твоего манямирка. В реальности у гугла огромное число проектов имеют закрытые исходники. >новый код андроида стараются писать исключительно на расте Никого не волнует, что они там "стараются", ты факты давай, что там, где и в каком количестве написали/переписали. >Возможно через лет десять новые кода в ядре будут только на расте А возможно, что через десять лет в землю врежется метеорит и уничтожит человечество. Твои спекуляции по прежнему не интересны и в высшей степени не нужны.
	Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

	177. Скрыто модератором	+/–
	Сообщение от Аноним (-), 29-Мрт-24, 18:56
	> Инструмента, который *не позволяет* допускать ошибки - существовать не может, чисто концептуально. Но есть который позволяет их избегать) > И в хрустящем """софте""" встречаются всё те-же выходы за границы массива, переполнение сигнедов (тебе ссылку уже кидали, ага), но так как хрустяшку позиционируют как мегасафети - её адепты расслабляются и могут не заметить, что из-за ужасного дизайна язычка там может *случайно* протечь унсейф контекст в сейф через лямбды, например. О, ты ты наверное из тех кто "сгорел сарай, гори и хата". У гугла как-то получается уменьшить кол-во ошибок памяти при использовании раста, а у тебя нет. Даже удивительно! > И да, напомню, что аналогия - это НЕ аргумент. Естествено! ©  Но с тупенькими приходится применять аналогии, тк факты они не очень впоспринемают. А вот то что 1. раст приняли в ядро 2. на нем уже написали драйвер под м1 который прошел сертификацию 3. его внедряют в андроид и винду это говорит о том, что его преимущества работают. > Да, логичным итогом улучшения сишки стал C++. Который, в отличии от куска ржавчины, именно что решает проблемы, Хахаха, только оно не сработало. Приходится обмазываться санитайзерами, фаззингом. Дабе когда добавили МираклПТРы, то оказалось что оно жрет ресурсы, а выхлопа 50% > а не предлагает БДСМ-пати под предлогом мнимой бищапащности. Меня мало волнуют твои сексуальные фантазии, но осуждать тебя не буду) > Именно! Они отказываются принимать тот факт, что прогресс и его направление объективны, ввиду чего получают ржавую мазню, вместо вменяемых инструментов. Если для тебя прогресс это древние кривый инструменты от дидиов, то можешь ими пользоваться. Но не жалуйся если караван уйдет и ты останешь за бортом прогресса. > Не фантазируй, разработчики ведра вряд-ли сидят на опеннете. Думаешь в ядро так сложно сделать хотя бы один коммит? На самом деле нет. > Демагогию не разводи. Если вдруг забыл - иди перечитывай, либо приводи конкретные аргументы, а не в очередной раз газируй лужу. Кажется у тебя просто шизофрения /_- Аргумент: написанный код должен одинаково работать на одной и той же платформе. Если это не так - это баг. >>Лол, ты просто наложил кучу > Проекция. Аргументы в стиле "нет ты"? Значит аргументы закончились) > Кто "мы" и с чего-бы? Фантазируешь. Аргументация была иная, перечитывай иди, демагог. Опять обосратушки? Ты там штанишки почаще меняй. > Вот когда будет готов - тогда и приходите. А я говорю про положение дел *сейчас*, а не когда-то там в будущем, которое легко может ещё и не наступить. Положение дел сейчас - рас добавили а в ядро, растохейтеры идут на Хурд. > Посмотри, сколько было успешных форков проектов, по размерам и комплексности сопоставимым с компилятором хруста. Опять маняпулируешь, уже не интересно. Какой же ты тупой... Я тебе привел форк xfree86, который сейчас используется на половине десктопных линуксов в виде ХОрга. Хочень сказать что реализация Х11 это проще чем компилятор? > Тогда зачем ты его сюда публикуешь? Любишь золотой дождь? О... ты опять начинаешь свои половые фантазии. Ну зачем? Мне ж оно не интересно. > Ты пока что ни разу не указал на "проблемы дыряшки", всё что ты тут намазал - это фантазёрство и баззворды про "ужасный UB" без толики конкретики. То что стабильно раз в пару недель читаем "уязвимость из-за UB которая позволяет получать рут". Для умственно отсталых это конечно не проблема. > "Опенсорс-компания" это только в пределах твоего манямирка. В реальности у гугла огромное  число проектов имеют закрытые исходники. И? я что привел в пример проект с закрытым кодом? Хватит обделываться на ровном месте! У IBM тоже есть закрытые проекты, но это не уменьшает их заслуг в опенсорс проектах.
	Ответить | Правка | К родителю #176 | Наверх | Cообщить модератору

	185. Скрыто модератором	+/–
	Сообщение от C00l_ni66a (ok), 30-Мрт-24, 16:07
	>Но есть который позволяет их избегать) Помимо учебника логики - тебе ещё и учебник по русскому языку нужен, вестимо. Пруфай, короче. >О, ты ты наверное из тех кто "сгорел сарай, гори и хата". О, ты опять фантазируешь. >У гугла как-то получается уменьшить кол-во ошибок памяти при использовании раста, а у тебя нет. "Уменьшить кол-во <класс-ошибок-нейм>" != "избегать ошибок". Ты писал именно про второе, лжец и маняпулятор. Более того, ты снова фантазируешь, переходя на личности: "улучшать мемори сафети с помощью раста" у меня "не получается" исключительно потому, что ржавчину я не юзаю. Впрочем, твоё личное решение действительно прогрессивно, ведь если не писать софт вообще - то и ошибок не будет. Более того, без конкретного сравнения профита от использования анализаторов, санитайзеров и следованию положительным паттернам разработки на тех-же крестах и профита от использования растишки - твоя апелляция не имеет смысла, см. "систематическая ошибка выжившего". >Естествено! ©  Но с тупенькими приходится применять аналогии, тк факты они не очень впоспринемают. Предлагаешь начинать писать тебе 150 аналогий, чтобы уж точно дошло? Ну, окей, попробую. >это говорит о том, что его преимущества работают. Ложь. Это говорит о том, что какие-то конкретные эффективные менеджеры *считают*, что преимущества есть и они работают. Например: небезызвестный австрийский художник считал, что жизни достойна лишь белая раса арыйцев. Но что-то утверждений про "преимущества нац. соц." я от тебя не вижу. >Хахаха, только оно не сработало. Пруфы? >Приходится обмазываться санитайзерами, фаззингом. Также, как и в случае с хрустом. Потому что "memory leaks are considered memory safe", а фаззинг это куда более широкая техника, чем считают некоторые скудоумные адепты. >Дабе когда добавили МираклПТРы То есть, добавили не нужную ересь, цель которой не столько "мемори сафети", сколько поддержка красивых сообщениях об ошибках. Очередной пруф, что к тебе применима поговорка "слышу звон, да не знаю, где он". >то оказалось что оно жрет ресурсы А в хрусте Arc типа ресурсы не жрёт, ага. Фантазируй больше, неуч. >а выхлопа 50% Так там и перевели на эти шизоПТРы лишь какую-то часть кодовой базы, а далеко не всю и даже не половину (ЕМНИП). То есть, получается, что даже от такой костыльной ереси есть существенный профит. >Меня мало волнуют твои сексуальные фантазии Так это ведь фантазии адептов, а не мои. Я-то как раз предпочитаю более традиционное времяпровождение и пустыми лозунгами про бищапащность меня в вашу пати не затащить. >Если для тебя прогресс это древние кривый инструменты от дидиов >>кривый инструменты Пруфай. >Думаешь в ядро так сложно сделать хотя бы один коммит? На самом деле нет. То есть, разработчики ведра всё-же сидят на опеннете? И даже конкретные разработчики, последствия действий которых упоминаются в статьях? Пруфай, в таком случае. >Кажется у тебя просто шизофрения /_- Проекция. Пока что в регулярных противоречиях самому себе был уличён лишь ты. >Аргумент: написанный код должен одинаково работать на одной и той же платформе. Не должен. У каждой платформы есть множество своих особенностей, которые мешают "работать одинаково". Как минимум потому, что запускаешь ты не "код", а "машинный код, полученный путём трансляции из кода на ЯП, сделанный как можно более совместимым с различными архитектурами". Повторяю в четвёртый раз: иди учить матчасть, не позорься. >Если это не так - это ...некомпетентность очередного хрустоадепта в комментариях. >Аргументы в стиле "нет ты"? Значит аргументы закончились) Про себя что-ли пишешь? Или ты неиронично предлагаешь отвечать на твоё пустое балабольство чем-то кроме указанием на факт твоего балабольства? Мань, это так не работает, ты либо пруфаешь свои голословные утверждения, либо по факту являешься балаболкой и тихо-мирно продолжаешь стекать в канаву. >Опять обосратушки? А разве был хоть один раз, когда ты *не* обосрался? Напомни-ка. >Ты там штанишки почаще меняй. Я не буду менять тебе штаны, это задача твоего лечащего врача. >Какой же ты тупой... Проекция. >Я тебе привел форк xfree86 Сопоставление размера проекта и комплексности будет? Если нет, то это очередное пустое балабольство и ложный пример. >Хочень сказать что реализация Х11 это проще чем компилятор? Хочу сказать, что ты игнорируешь множество факторов и переносишь ответственность за пояснение к *твоим* словам на левого человека. >О... ты опять начинаешь свои половые фантазии. Проекция и очередной съезд с темы. Хотя, с таким прокаченным двоемыслием ты мб действительно противоречий в своих высepaх не видишь. >Положение дел сейчас ... растохейтеры идут на Хурд. Фантазёрство и съезд с темы. >"уязвимость из-за UB которая позволяет получать рут". Пруфай, что "уязвимость ИЗ-ЗА UB". Про эти баззворды и пустые набросы я и писал, ты высираешь какой-то тезис, но заходить чуть дальше, чем пустое утверждение - даже не пытаешься. Другие адепты мб и будут тебе верить, но в общем случае люди твоё балабольство на веру брать не обязаны. Ты либо пруфаешь, либо балабол. >Для умственно отсталых ...бывает очень трудно поискать в интернете информацию на тему, зачем существует UB. >И? я что привел в пример проект с закрытым кодом? Хватит обделываться на ровном месте! Назвал гугл "опенсорс-компанией" ты, а обделался я? Это немного не так работает, тебе объяснить? >У IBM тоже есть закрытые проекты, но это не уменьшает их заслуг в опенсорс проектах. Маняпуляция. "Наличие заслуг в опенсос проектах" не пруфает, что это "опенсорс-компания", лгунишка.
	Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

	70. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–1 +/–
	Сообщение от Аноним (40), 27-Мрт-24, 14:22
	Что значит неправильно использовать? Использовать так, как уместно в конкретном случае. Да, это вам не растофашизм.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	74. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 14:30
	> Использовать так, как уместно в конкретном случае. Вот погромист из этой новости посчитал, что вполне уместно в том конкретном случае очистить память дважды. Почему? А потому что ему так захотелось. И в с++ можно сделать тоже самое. Никто же не запретит. Это вам не растофашизм))
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–1 +/–
	Сообщение от Аноним (39), 27-Мрт-24, 16:29
	Раст ему никак не помешает сделать таких же unsafe глупостей. Без unsafe растовикр писать пока что не научились.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 16:32
	За unsafe тебя спросят на первом же кодревью. Ты можешь пройтись поиском и легко найти все места где есть unsafe. Это тебе сократит область поиска в десятки раз. > Без unsafe растовикр писать пока что не научились. Есть целая категория либ unsafe forbidden, где его вообще запрещено использовать. Как же интересно они их написали?
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–2 +/–
	Сообщение от C00l_ni66a (ok), 27-Мрт-24, 16:53
	>Есть целая категория либ unsafe forbidden, где его вообще запрещено использовать. Либы это, конечно, замечательно, а *софт* есть? Ну, то есть, тот, где меньше двух сотен лефтпадов и в этих лефтпадах тоже нет ансейфов?
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (142), 27-Мрт-24, 21:50
	Андроид. В нем уже дофига раст-кода в системных компонентах
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от C00l_ni66a (ok), 29-Мрт-24, 15:08
	А конкретнее? Что это за "системные компоненты"? Тебя про это уже вроде спрашивали, но ничего осмысленного ты не ответил, просто продолжил ссылаться на какую-то шизоагитку от гулага.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (92), 27-Мрт-24, 16:25
	> но до раста ему топать и топать Почему вы все тогда компиляете свой расто-код компилятором, написанным на C++?
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	112. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от C00l_ni66a (ok), 27-Мрт-24, 16:55
	Там даже не просто "написанным", сама хрустяшка дёргает именно ПЛЮСОВЫЙ фронтенд ллвм апи. Что как бы намекает.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Пряник (?), 27-Мрт-24, 14:16
	Не всегда мудрость приходит с возрастом.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	69. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (32), 27-Мрт-24, 14:20
	Плюсы сложнее сишки во всём, с чего это они должны быть в ядре? Лучше уж сишка, хоть и старьё.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	75. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 14:30
	> Плюсы сложнее сишки во всём, с чего это они должны быть в > ядре? Лучше уж сишка, хоть и старьё. Вы мыслите какими-то странными категориями. "Сложнее/проще", "легче/тяжелее", "лучше/хуже" - это всё относительные понятия. Т.е. при их употреблении нужно сразу уточнять - для кого? Иными словами, всё это вообще никакой роли не играет, поскольку - сугубо индивидуально. Возраст языка программирования тоже не играет вообще никакой роли. Имеют значения лишь его технические особенности.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 16:03
	> это всё относительные понятия. Т.е. при их употреблении нужно сразу уточнять - для кого? Именно! Не думал что скажу это, но согласен. Напрмер Раст - он 'проще' для тех кто не сильно знаком с СИ или плюсами, и 'сложнее' для Сишников. Он 'легче' в том смысле что у него меньше UB/IB и тд, но 'тяжелее' в том что нужно освоить новые концепции типа borrow. Он 'лучше' для кода, тк практически убирает ошибки памяти и дает программерам возможность сосредоточиться на например логических, но при этом он убирает возможность сидеть на поддержке СИшного овнокода десятилетиями, и для программистов это 'хуже' тк согласно религии секты бородатой антилопы, зарабатывать деньги можно только на поддержке кода. > Возраст языка программирования тоже не играет вообще никакой роли. Имеют значения лишь его технические особенности. А вот тут не соглашусь. Старые языки содержат в себе концепты и подходы своего времени. И обычно приходится тянуть обратную совместимость, что не позволяет выкинуть весь старый хлам и добавить новые подходы. Например создать класс Error и перестать прокидывать результат функции/ошибки интами.(положильными результат, отрицательными ошибки.. или наоборот? и не дай бор получить переполнение и сменить знак!). Или добавить pattern matching. А если авторы таки решаются поломать совместимость, то это происходит ну очень болезнено и с кучей проблем.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 16:23
	> Он 'лучше' для кода, тк практически убирает ошибки памяти и дает программерам > возможность сосредоточиться на например логических, но при этом он убирает возможность > сидеть на поддержке СИшного овнокода десятилетиями, и для программистов это 'хуже' > тк согласно религии секты бородатой антилопы, зарабатывать деньги можно только на > поддержке кода. Извините, но чушь. Не валите всё в одну кучу. Зарабатывание денег можно обсудить в другой плоскости, и Rust снова проиграет, но уже совершенно по другим причинам. Но это разговор о-очень долгий и к IT относящийся лишь косвенно. И, если что, напомню - изначально речь шла о С++, а не о С. > А вот тут не соглашусь. > Старые языки содержат в себе концепты и подходы своего времени. > И обычно приходится тянуть обратную совместимость, что не позволяет выкинуть весь старый > хлам и добавить новые подходы. > Например создать класс Error и перестать прокидывать результат функции/ошибки интами.(положильными > результат, отрицательными ошибки.. или наоборот? и не дай бор получить переполнение > и сменить знак!). > Или добавить pattern matching. > А если авторы таки решаются поломать совместимость, то это происходит ну очень > болезнено и с кучей проблем. Ну так всё описанное и есть технические особенности. Возраст тут совершенно ни при чём.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 16:53
	> Извините, но чушь. Не валите всё в одну кучу. Зарабатывание денег можно обсудить в другой плоскости, и Rust снова проиграет, но уже совершенно по другим причинам. Ладно, давайте отложим тему денег, предположим что у нас есть заадча написать какой-то код, для простоты пусть это будет либа. Она будет работать на миллионах устройств и поэтому для нее есть требования "максимальной надежности". Какой язык программирования вы бы выбрали? > Ну так всё описанное и есть технические особенности. Возраст тут совершенно ни при чём. Странное утверждение. Это как говорить что "старые люди, обычно двигаются тяжелее, их реакции более замедленные, а имунная система менее активная не из-за возрачта, а просто у них такие тхенические особенности". Ведь для языков программирования эти технические особенности практически прямое следствие от возраста.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 17:47
	>> Извините, но чушь. Не валите всё в одну кучу. Зарабатывание денег можно обсудить в другой плоскости, и Rust снова проиграет, но уже совершенно по другим причинам. > Ладно, давайте отложим тему денег, > предположим что у нас есть заадча написать какой-то код, для простоты пусть > это будет либа. Она будет работать на миллионах устройств и поэтому > для нее есть требования "максимальной надежности". > Какой язык программирования вы бы выбрали? С++. В силу его гибкости прежде всего, а также поддержки компиляторами большинства существующих архитектур процессоров. А обеспечение надёжности целиком и полностью зависит от реализации, а не от языка. > Странное утверждение. > Это как говорить что "старые люди, обычно двигаются тяжелее, их реакции более > замедленные, а имунная система менее активная не из-за возрачта, а просто > у них такие тхенические особенности". > Ведь для языков программирования эти технические особенности практически прямое следствие > от возраста. Совершенно неуместная аналогия. Языки программирования напрямую связаны с особенностями железа. Больше ни с чем. И они не стареют, как люди. Биологическое старение - это явление другой природы. И, кстати говоря, не обязательно связанное с возрастом))
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (86), 27-Мрт-24, 16:04
	Технические особенности плюсов таковы, что язык не востребован за пределами геймдева. И дальше дискуссию можно не продолжать.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	87. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 16:13
	> Технические особенности плюсов таковы, что язык не востребован за пределами геймдева. И > дальше дискуссию можно не продолжать. Да что вы говорите)) Настолько не востребован, что на нём аж компилятор gсс написан. Которым С программы собирают)) Это я уже молчу про кучу разного прикладного.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 16:21
	Технические особенности сишки таковы, что на ней: - или тянут древние проекты вроде ядра линукса, которым десятилетия. - или используют для лютой ембедщины. Потому что плюс для прикладного программирования лучше сишки во всем. Особенно последние редакции от с++17 и выше. А сишка вообще остановилась в развитии.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	103. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 16:38
	Хмм.. а на чем там у соседей написан оффтопик? Удивительно, но их графическая система написана таки на с++. Самый популярный в мире браузер (и по совместительству самое популятное DE для ядра линукс) - chromium тоже написан на плюсах. Я могу еще вспомнить фотошоп, но тк тут форум любителей полуфа/bрикатов, то скажу что гимп частично написан на плюсах. А еще есть Open/LibreOffice, WxWidgets, 7-Zip и даже Haiku. Тысячи их!
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	136. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от n00by (ok), 27-Мрт-24, 19:23
	Технические особенности плюсов таковы, что в неправильной ОС, где нужен "антивирус", большинство драйверов тех самых HIPS написано на плюсах. И некоторые из них помешали бы исполняться аналогу героя сегодняшней новости.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	179. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 29-Мрт-24, 23:41
	> С++ позволяет многое делать в разы проще С[++] также позволяет и НЕ делать. > Но вместо С++ зачем-то начали > пихать Rust. Если чего-то не понимаешь, то есть два варианта: попытаться разобраться или свалить на масонов. > С++ позволяет ... при правильном использовании Ну вот видишь, ты сам и разобрался в чём причина. Согласись, было просто.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	180. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от ProfessorNavigator (ok), 30-Мрт-24, 00:08
	> С[++] также позволяет и НЕ делать. Да. И? > Если чего-то не понимаешь, то есть два варианта: попытаться разобраться или свалить > на масонов. А при чём здесь масоны?)) > Ну вот видишь, ты сам и разобрался в чём причина. Согласись, было > просто. Сказать то чего хотели, уважаемый?
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Карлос Сношайтилис (ok), 30-Мрт-24, 14:12
	> Сказать то чего хотели, уважаемый? Ты задал вопрос, сам же на него ответил. Я тебе на это указал. Или надо расжевать? Мне не сложно, давай. Можно ли на расте писать безопасный код? Можно. Можно ли на плюсах писать безопасный код? Можно. Можно ли на расте писать небезопасный код? Можно. Можно ли на плюсах писать небезопасный код? Можно. Почему при этом когда выбирают Раст, аппелируют к безопасности? Ты на этот вопрос ответил. Теперь вопрос к тебе - зачем ты задаёшь вопрос, ответ на который тебе известен?
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от ProfessorNavigator (ok), 30-Мрт-24, 14:53
	>[оверквотинг удален] > Или надо расжевать? > Мне не сложно, давай. > Можно ли на расте писать безопасный код? Можно. > Можно ли на плюсах писать безопасный код? Можно. > Можно ли на расте писать небезопасный код? Можно. > Можно ли на плюсах писать небезопасный код? Можно. > Почему при этом когда выбирают Раст, аппелируют к безопасности? > Ты на этот вопрос ответил. > Теперь вопрос к тебе - зачем ты задаёшь вопрос, ответ на который > тебе известен? Да, так стало немного яснее, но не до конца. Зачем вы пишите комментарий? Я так полагаю, чтобы выразить свою позицию и высказать мнение. И из ваших высказываний мне пока что непонятно - что конкретно вы пытаетесь до меня донести. Нужен/не нужен С++ в ядре? Нужен/не нужен Rust в ядре? Почему? Знаете ли вы конкретные причины, по которым C++ не используется в ядре, а Rust там появился? Может быть вы видели какие-то конкретные высказывания от самих участников проекта? Или быть может вы согласны с моей позицией по данному вопросу? Тогда не проще ли было так и написать? Чтобы не вызывать лишние вопросы.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Пряник (?), 27-Мрт-24, 14:25
	Можно при освобождении присваивать указателю NULL и проверять его на NULL.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

41. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
Сообщение от Аноним (41), 27-Мрт-24, 12:53
C ksmbd даже не удивлен. По дырам там поле не паханое.
Ответить | Правка | Наверх | Cообщить модератору

42. Скрыто модератором	+/–
Сообщение от Аноним (-), 27-Мрт-24, 12:57
А ведь этой ошибки можно было избежать, использовав язык V.
Ответить | Правка | Наверх | Cообщить модератору

48. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
Сообщение от вася (??), 27-Мрт-24, 13:04
Сколько придется ждать, когда это исправление появится в моём xiaomi redmi 8?
Ответить | Правка | Наверх | Cообщить модератору

	53. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (32), 27-Мрт-24, 13:12
	Логично предположить, ответить на этот вопрос может исключительно производитель xiaomi redmi 8...
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от сщта (?), 27-Мрт-24, 13:15
	Это с распродажи который приехал? Сам теперь пили или тут поплач с полгодика.(иногда помогает)
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	55. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 13:20
	Дольше, чем для PinePhone.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	58. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (-), 27-Мрт-24, 13:39
	> Сколько придется ждать, когда это исправление появится в моём xiaomi redmi 8? На redmi 8 ставится Lineage OS 21 (Android 14). Используется ядро 4.19. Получается как только бекпортнут фикс в 4.19 и линейка обновится. Не такой уж плохой расклад.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	77. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (40), 27-Мрт-24, 14:33
	Авось, повезёт когда-либо и твой Xiaomi Redmi 8 появится в PostmarketOS. Вот тогда и будет исправление.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

62. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
Сообщение от bOOster (ok), 27-Мрт-24, 14:02
Шикарно, оголтелые вчера рвали пер..ки в теме про FreeBSD а сегодня огребли проблем на порядок больше с уязвимостью.
Ответить | Правка | Наверх | Cообщить модератору

	63. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Аноним (44), 27-Мрт-24, 14:09
	важно рвать и тут и там
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от Tron is Whistling (?), 27-Мрт-24, 14:10
	Что с уязвимостями ksmbd в бздящей? Нет ksmbd - нет уязвимостей? Ну вот и примерно со всем остальным так же.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	172. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (172), 29-Мрт-24, 02:36
	Точно. Главное, чтобы в Линуксе было хуже, чем в БСД. Остальное неважно.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

76. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
Сообщение от Аноним (76), 27-Мрт-24, 14:31
Проблема кроется в ахитектуре команд процессора. Изначально никто не думал о многопользовательской системе.
Ответить | Правка | Наверх | Cообщить модератору

	97. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (39), 27-Мрт-24, 16:29
	Всё подумали что это будет очень медленно и это так и есть.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–2 +/–
	Сообщение от Аноним (-), 27-Мрт-24, 16:31
	Надо на RISC-V переходить.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	114. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+4 +/–
	Сообщение от Аноним (44), 27-Мрт-24, 17:06
	слишком большой риск, практически пятикратный
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (151), 28-Мрт-24, 07:47
	В общем-то поможет, если код nftables вырезать из ядра и крутить в отдельной аппаратной виртуалке. Но... приходим к гибридной архитектуре ядра тогда, как минимум.
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

	154. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (151), 28-Мрт-24, 07:36
	В 80386 уже всё было для многопользованности. Проблема в том, что nftables тоже выполняется в кольце с максимальными привилегиями.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

81. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
Сообщение от аНОНИМ (?), 27-Мрт-24, 15:11
Привет всем агитаторам за переход на nftables
Ответить | Правка | Наверх | Cообщить модератору

	155. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (151), 28-Мрт-24, 07:38
	Чем он принципиально отличается от iptables в плане безопасности? Ничем. И то, и то исполняется в ядре.
	Ответить | Правка | Наверх | Cообщить модератору

84. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
Сообщение от Аноним (86), 27-Мрт-24, 16:01
Кто-нибудь вообще nftables начал использовать?
Ответить | Правка | Наверх | Cообщить модератору

	128. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от penetrator (?), 27-Мрт-24, 18:33
	выбора особо нет, шапка восьмая и девятая вроде имеют бекендом нфтейблс, т.е. надо от шапки отказываться, что бред
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (135), 27-Мрт-24, 19:23
	Да, полет хорош. Особенно радует возможность юзать iif в postrouting.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

106. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
Сообщение от Syndrome (ok), 27-Мрт-24, 16:43
Для эксплуатации уязвимости nftables нужен игрушечный root (user namespace). Думаю стоило указать это в новости.
Ответить | Правка | Наверх | Cообщить модератору

137. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	–2 +/–
Сообщение от Аноним (135), 27-Мрт-24, 19:28
Да, SMB и в винде себя хорошо показал на примере eternalblue, и того, что конфикер юзал.
Ответить | Правка | Наверх | Cообщить модератору

	149. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+2 +/–
	Сообщение от iPony129412 (?), 28-Мрт-24, 03:34
	Так Microsoft предупреждал, что древний и перегруженный SMBv1 надо бы отключать, но... всем же надо на древних технологиях сидеть. Это тебе не Linux с «Stable Api is nonsense»
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (151), 28-Мрт-24, 07:43
	Скажи, умник, как XP, которая в промышленной эксплуатации в составе программно-аппаратного комплекса, переключить на SMBv2?
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+1 +/–
	Сообщение от нах. (?), 28-Мрт-24, 11:42
	А зачем она ВООБЩЕ у тебя подключена к сети, да еще не изолированной, и почему в ней нахрен не отключен при этом SMB целиком, даже если предположить что предыдущие два пункта зачем-то ну ооооочень нужны?
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от Аноним (171), 28-Мрт-24, 15:33
	отключить smb от операционки совсем. собрать самбу под винду, с реализацией нужной версии протокола
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	186. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."	+/–
	Сообщение от iPony129412 (?), 01-Апр-24, 08:19
	> отключить smb от операционки совсем. собрать самбу под винду, с реализацией нужной > версии протокола Безопасность по системе Джо Но на практике бывает работает, если самого баги не задолбают Тем более сборка для Windows не поддерживается.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема